Резервная копия, которую ни разу не восстанавливали, – это не резервная копия, а предположение. Слишком многие организации узнают об этом в худший момент: когда сгорел RAID-массив, шифровальщик прошёл по сети или сотрудник удалил таблицу в боевой базе. Лента крутится по расписанию, отчёты зелёные, а данных нет. Готовность к сбоям проверяется не наличием бэкапа, а скоростью и полнотой восстановления.

Считайте в RTO и RPO, а не в гигабайтах

Два параметра определяют, насколько больно вам будет при отказе. RPO (Recovery Point Objective) – сколько данных вы готовы потерять, измеряется глубиной между копиями. Если бэкап снимается раз в сутки в три часа ночи, а база рухнула в восемь вечера, вы потеряли семнадцать часов работы. RTO (Recovery Time Objective) – за какое время вы обязаны вернуть сервис в строй.

Эти цифры назначает не ИТ-отдел, а бизнес. Для биллинга оператора связи допустимый простой измеряется минутами, для внутреннего файлового архива – сутками. Когда параметры согласованы с руководством, спор о бюджете на инфраструктуру превращается из «нам нужно больше дисков» в «час простоя биллинга стоит столько-то, защита стоит дешевле». Дальше схема резервирования вытекает из этих чисел сама: ежедневный полный бэкап плюс инкременты, репликация на второй площадку, горячий резерв сервера.

Храните копии по правилу 3-2-1

Проверенная практика: три копии данных, на двух разных типах носителей, одна – за пределами площадки. Локальный массив отвечает за быстрое восстановление файла, удалённая копия – за катастрофу, когда серверная недоступна целиком: пожар, затопление, изъятие оборудования.

Вынос копии за периметр – отдельная задача. Лента в банковской ячейке работает, но восстановление с неё займёт часы дороги и загрузки. Онлайн-репликация в удалённый дата-центр быстрее, и здесь стоит присмотреться к арендуемым ресурсам. Блочные облачные тома вроде Amazon EBS дают площадку для отложенной копии без капитальных затрат на второй ЦОД – снимок тома переносится за пределы вашей серверной автоматически. Для госсектора и данных под регуляторными требованиями выбор площадки сложнее: учитывайте, где физически лежат носители и кто имеет к ним доступ.

Тестируйте восстановление по графику

Бэкап без регулярного тестового восстановления – фикция. Заведите регламент: раз в квартал поднимайте копию на изолированном стенде, разворачивайте базу, проверяйте целостность приложения и сверяйте контрольные суммы. Так вы ловите типовые провалы заранее – обрыв задания на середине, несовместимость версий СУБД, забытый внешний файл конфигурации, истёкший ключ шифрования архива.

Отдельно опишите процедуру в документе, который поймёт дежурный инженер в три часа ночи: где лежат копии, в каком порядке поднимать сервисы, кого вызывать, какие пароли нужны. План непрерывности бизнеса – это не сертификат на стене, а отрепетированный сценарий.

Если своей экспертизы или рук на регулярное тестирование не хватает, разумно вынести задачу подрядчику – по любой из моделей сотрудничества, от разовой настройки до постоянного сопровождения. Тогда расчёт RTO и RPO под конкретные процессы, схема резервирования и регулярные учения по восстановлению ложатся на отказоустойчивую инфраструктуру, которую строят и обслуживают с прицелом именно на эти показатели.

Вывод

Непрерывность бизнеса измеряется не объёмом архивов, а проверенной способностью вернуть сервис в срок. Назначьте RTO и RPO вместе с руководством, разнесите копии по правилу 3-2-1 и тестируйте восстановление по графику. Сбой случится – вопрос лишь в том, окажется он инцидентом на час или катастрофой на неделю.