Резервные копии есть. А восстановиться получится?

Как проверить резервное копирование: охват данных, изоляция копий, уведомления, RPO, RTO и регулярные тестовые восстановления.

Содержание

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

Проверять нужно не факт копирования, а способность восстановить конкретный бизнес-процесс за приемлемое время.

Составьте перечень данных

Начните не с программы резервного копирования, а со списка критичных систем:

  • базы 1С;
  • общие файлы;
  • документы сотрудников;
  • CRM и базы клиентов;
  • почта;
  • виртуальные машины;
  • настройки сетевого оборудования;
  • сайты и базы сайтов;
  • телефония;
  • конфигурации приложений;
  • ключи и сертификаты;
  • данные облачных сервисов.

Для каждой системы ответьте: что будет потеряно, если восстановить её из копии недельной давности? Ответ помогает определить частоту копирования.

RPO: сколько данных допустимо потерять

RPO — допустимая глубина потери данных во времени. Если база копируется раз в сутки, в худшем случае компания потеряет изменения за весь рабочий день. Для одной системы это приемлемо, для другой — нет.

Не обязательно копировать всё каждую минуту. Важно согласовать частоту с владельцем процесса, а не выбирать её только по удобству администратора.

RTO: сколько можно восстанавливаться

RTO — ориентир по времени возврата системы в рабочее состояние. В него входят:

  • обнаружение проблемы;
  • принятие решения о восстановлении;
  • подготовка оборудования или облачной среды;
  • загрузка данных;
  • проверка целостности;
  • подключение пользователей.

Если резервная копия хранится на медленном носителе или требуется заказывать новый сервер, восстановление может занять значительно больше времени, чем ожидало руководство.

Где хранятся копии

Копия на втором диске того же сервера помогает при случайном удалении файла, но не защищает от поломки оборудования, кражи, пожара или шифровальщика с административными правами.

Практичная схема обычно включает несколько уровней:

  • оперативную локальную копию для быстрого восстановления;
  • отдельное хранилище;
  • копию вне основной площадки;
  • изолированную или неизменяемую версию, недоступную обычным администраторам и вредоносному ПО.

Изоляция важнее количества одинаковых копий в одной системе.

Кто видит ошибки

Резервное копирование может прекратиться из-за заполненного диска, изменения пароля, недоступности сети, ошибки лицензии или повреждения источника. Уведомление должно приходить ответственному человеку и регистрироваться как задача.

Полезно контролировать не только статус «успешно», но и:

  • объём копии;
  • длительность задания;
  • отклонение от обычного размера;
  • возраст последней успешной точки;
  • доступность хранилища;
  • результаты проверки целостности.

Резкое уменьшение объёма иногда означает, что часть данных перестала попадать в копию.

Почему отчёт программы недостаточен

Задание может завершиться успешно, но восстановление не запускается из-за повреждённого архива, отсутствующего ключа или несовместимости версии приложения. Единственная надёжная проверка — восстановить данные в отдельную среду.

Как проводить тестовое восстановление

Выберите один реалистичный сценарий:

  • восстановить отдельный файл;
  • развернуть копию виртуальной машины в изолированной сети;
  • восстановить базу 1С и выполнить тестовый вход;
  • вернуть конфигурацию сетевого устройства;
  • восстановить почтовый ящик или сайт.

Зафиксируйте:

  1. Какую точку восстановления выбрали.
  2. Кто выполнял процедуру.
  3. Сколько времени занял каждый этап.
  4. Какие пароли и ключи потребовались.
  5. Что не сработало с первого раза.
  6. Как проверили результат.
  7. Какие изменения нужно внести в инструкцию.

Тест не должен влиять на рабочую систему. Используйте отдельный сервер, временную виртуальную машину или изолированный контур.

Как часто тестировать

Частота зависит от критичности и изменений. Для ключевых систем тест полезно проводить регулярно и после существенных изменений: обновления платформы, переноса сервера, смены хранилища, изменения схемы шифрования или учётных записей.

Не обязательно каждый раз восстанавливать всю инфраструктуру. Можно чередовать сценарии и периодически проводить комплексную тренировку.

Облачные сервисы тоже требуют стратегии

Использование облачной почты или CRM не всегда означает, что поставщик сможет вернуть данные в нужном виде после массового удаления, ошибки синхронизации или действий пользователя. Нужно изучить встроенные возможности хранения версий, корзины, экспорт и доступные средства резервного копирования.

Пароли и ключи

Зашифрованная копия бесполезна без ключа. Данные для восстановления должны храниться отдельно и быть доступны как минимум двум уполномоченным сотрудникам. Нельзя привязывать весь процесс к личному телефону одного администратора.

Минимальный ежемесячный контроль

  • Все критичные системы присутствуют в перечне.
  • Последние задания завершились успешно.
  • Нет копий старше установленного порога.
  • Хранилища не переполнены.
  • Изолированная копия обновляется.
  • Уведомления реально приходят.
  • Есть актуальная инструкция восстановления.
  • Последний тест зафиксирован и разобран.

Итог

Резервное копирование — это не задача «сохранить данные», а процесс возврата бизнеса к работе. Хорошая система отвечает на четыре вопроса: что восстанавливаем, из какой точки, за какое время и кто умеет это сделать. Если хотя бы на один вопрос нет ответа, резервирование требует доработки.

← Все статьи блога