Резервное копирование редко ломается так, чтобы это было заметно сразу. Задания продолжают запускаться по расписанию, отчёты остаются зелёными, свободное место в хранилище пока есть — и создаётся ощущение, что всё под контролем. Именно это и делает бэкап коварным. Внешне всё выглядит нормально, но в реальности резервное копирование может деградировать постепенно, а проблема всплывает только в момент, когда восстановление действительно нужно.
Чтобы резервное копирование работало как предсказуемый инструмент восстановления, а не как формальная галочка, важно понимать базовые термины. Эти термины выглядят крайне простыми, но именно они определяют конечный результат. Причём не абстрактно, а напрямую отвечая на вопрос, сможем ли мы восстановиться и насколько болезненно это будет для бизнеса.
Глубина хранения
Глубина хранения — это срок, в течение которого резервные копии хранятся до удаления согласно регламенту. На практике глубина хранения определяет, насколько далеко назад мы можем откатиться. Если глубина составляет 30 дней, то восстановить систему можно в пределах этого месяца. Если проблема с данными возникла два месяца назад, корректной точки восстановления уже не будет, потому что старые копии были автоматически удалены.
При выборе глубины хранения обычно учитывают несколько факторов:
- Доступное место хранения. Чем дольше мы храним копии, тем больше дискового пространства они занимают, особенно если нет нормальной дедупликации и компрессии.
- Полезность хранимых резервных копий. Для некоторых систем, которые быстро меняются или регулярно очищаются, хранение большого количества исторических точек может давать мало практической ценности, но занимать много места и потреблять значительные ресурсы.
- Требования регуляторов. В ряде отраслей существуют правила и сроки хранения данных, которые необходимо соблюдать независимо от удобства и стоимости.
- Принятие рисков. По сути, это решение о том, какую потерю данных за период, выходящий за рамки выбранной глубины хранения, компания готова принять, если увеличить срок хранения не позволяют технические или бюджетные ограничения.
В рамках одной стратегии резервного копирования часто комбинируют разную глубину хранения. Например, ежедневные копии хранят две недели, а более редкие месячные срезы держат год. Такой подход помогает найти баланс между безопасностью и затратами на дисковое пространство.
Важно помнить, что чем больше срок хранения, тем больше ресурсов потребуется под резервные копии. Это означает, что в какой-то момент придётся либо докупать системы хранения, либо заранее резервировать место под рост бэкап-репозитория. Поэтому глубина хранения напрямую влияет на стоимость всей системы резервного копирования, и здесь почти всегда приходится искать компромисс между желанием хранить “всё и долго” и ценой такого хранения.
Окно резервного копирования
Резервное копирование потребляет ресурсы. В процессе бэкапа система резервного копирования читает данные с дисков, нагружает сеть, пишет в хранилище и иногда создаёт дополнительную нагрузку на прикладные сервисы. В виртуальной среде создание моментальных снимков может влиять на дисковую подсистему и снижать производительность виртуальных машин.
В случае баз данных появляются дополнительные требования к задержкам и стабильности I/O. В файловых хранилищах начинается конкуренция за ввод и вывод.
Именно на этом этапе часто возникает типичный конфликт. С одной стороны, бизнес хочет минимальную потерю данных и частые копии. С другой стороны, инфраструктура не всегда готова к тому, что бэкап будет регулярно “подъедать” ресурсы и влиять на сервисы.
Поэтому в компаниях определяют окно резервного копирования. Это период минимальной нагрузки на систему, когда выполнение бэкапа причиняет меньше всего ущерба. В классическом варианте окно резервного копирования выбирают ночью и в выходные, например, с 20:00 до 06:00. Конкретные значения зависят от нагрузки и от того, о какой системе идёт речь.
Отдельная история — это критически важные сервисы, которые работают 24/7. В таких случаях окно резервного копирования подобрать сложнее, и требования к аккуратности настроек становятся выше. Здесь часто применяются дополнительные технологии, такие как репликация, кластеризация, сегментация по нагрузке и другие подходы. К этим вопросам мы вернёмся в следующих статьях.
Точка восстановления
Точка восстановления — это конкретное состояние данных на определённое время. Именно её выбирают, когда происходит авария и нужно вернуть систему в рабочее состояние. В этот момент уже не так важно, какой продукт используется и как “красиво” выглядят политики резервного копирования. Важно другое: существует ли нужная точка восстановления в принципе, подходит ли она для отката и являются ли данные в ней консистентными.
Точка восстановления всегда является результатом решений, которые принимаются заранее. Если глубина хранения небольшая, нужной точки может просто не оказаться. Если частота резервного копирования низкая, откат получится грубым и болезненным. Если окно резервного копирования постоянно срывается, последние точки могут быть неполными или отсутствовать. Если хранилище перегружено, точка восстановления может существовать, но восстановление из неё займёт слишком много времени.
Поэтому зрелое резервное копирование — это не просто наличие большого количества точек восстановления. Это качество каждой точки и предсказуемость процесса восстановления. Хорошая система резервного копирования должна отвечать на практический вопрос: если выбрать любую точку в пределах глубины хранения, сможем ли мы восстановиться и уложиться в нужные сроки?
Хранилище резервных копий
Хранилище резервных копий — это место, где лежат данные, из которых будет выполняться восстановление. Если относиться к нему как к обычному ящику “куда складываются копии”, резервное копирование почти гарантированно начнёт деградировать при росте нагрузки.
Хранилища — дисковые, ленточные или облачные — определяют скорость выполнения резервного копирования и скорость восстановления. Оно влияет на то, можно ли держать достаточную глубину хранения, и оно же определяет устойчивость резервных копий к реальным инцидентам. В том числе к компрометации доступа и уничтожению данных.
На практике резервные копии часто теряются не потому, что бэкап не делался, а потому что хранилище резервных копий оказалось частью той же зоны отказа, что и продакшен. Если резервные копии находятся рядом с основной инфраструктурой, если доступ к ним осуществляется с тех же учётных записей, если они не изолированы и не защищены, то при серьёзной атаке можно потерять и рабочие данные, и резервные копии одновременно.
Хранилище резервных копий — это не просто место хранения. Это компонент безопасности и восстановления. В момент аварии оно становится ключевым источником данных, и от него зависит, будет ли восстановление управляемым процессом или хаотичной попыткой “хоть что-то вернуть”.
Заключение
Резервное копирование полезно ровно в той мере, в которой оно позволяет восстановиться. Именно поэтому его нельзя оценивать по количеству заданий, отчётам или формальному факту наличия копий.
Глубина хранения определяет, насколько далеко назад можно откатиться. Окно резервного копирования — насколько реально выполнять бэкап без разрушения сервиса. Частота копирования определяет возможную потерю данных. Точка восстановления — к какой версии данных можно вернуться на практике. Хранилище резервных копий — насколько быстро и надёжно получится выполнить восстановление.
При этом все эти понятия тесно связаны и частично пересекаются с такими важнейшими метриками, как RTO и RPO. О них мы поговорим в одной из следующих статей.