Как проверить, что бэкап действительно можно восстановить
Наличие резервной копии ещё не означает, что данные удастся вернуть в рабочее состояние. Между утверждениями "бэкап создан" и "бэкап успешно восстановлен" есть принципиальная разница. Поэтому проверка восстановления бэкапа должна быть регулярной процедурой, а не экстренной мерой после сбоя.
Показательны два известных случая. В 1998 году на студии Pixar из-за ошибочной команды `rm -rf` было удалено около 90% материалов "Истории игрушек 2". Резервные копии существовали, однако система копирования давно работала некорректно: переполненный диск скрывал ошибки, а восстановленная версия оказалась частично повреждённой. Фильм спасла домашняя копия технического директора Галин Сусман, но и её пришлось объединять с более старым архивом, файлами на компьютерах сотрудников и результатами тестовых рендеров. Из примерно 100 тысяч файлов около 30 тысяч проверяли вручную, а часть данных восстановить так и не удалось.
Похожая ситуация произошла в GitLab 31 января 2017 года. Инженер, устраняя проблему с репликой PostgreSQL, случайно удалил каталог данных на основном сервере. Команду остановили почти сразу, но из 300 ГБ осталось всего 4,5 ГБ. Резервные дампы создавались с использованием несовместимых версий PostgreSQL, свежих копий в S3 не оказалось, а уведомления об ошибках не доходили из-за проблем с DMARC. Компанию выручил LVM-снимок, сделанный за несколько часов до аварии. Тем не менее были потеряны проекты, комментарии и учётные записи, созданные за этот период.
Обе истории объединяет один вывод: резервные копии формально были, но полноценного восстановления никто заранее не проверял. Именно поэтому тестирование резервного копирования должно включать не только контроль факта создания архива, но и практическую загрузку данных в отдельной среде.
Правило 3-2-1 и его современная версия
Классическая схема 3-2-1 предполагает наличие трёх экземпляров данных: основной версии и двух резервных копий. Они должны храниться как минимум на двух разных типах носителей, а одна копия - находиться удалённо. Такой подход снижает риск одновременной потери информации из-за поломки оборудования, ошибки сотрудника или аварии в дата-центре.
Сегодня часто используют расширенную модель 3-2-1-1-0. Дополнительная единица означает наличие копии, которую нельзя изменить или удалить: например, объектное хранилище с Object Lock либо физически отключённый накопитель. Ноль - это отсутствие ошибок при автоматической проверке восстановления. Иными словами, недостаточно просто иметь несколько копий: необходимо регулярно убеждаться, что из них действительно можно получить рабочие данные.
Первый уровень контроля - проверка целостности архива. Для обычного tar-архива можно выполнить:
```bash
tar -tf backup.tar
```
Если список файлов выводится без ошибок, архив, скорее всего, читается. Однако это лишь базовая диагностика. Целостный архив может оказаться неполным: например, содержать только часть базы или старую версию конфигурации.
В системах restic применяются команды `restic check` и `restic check --read-data-subset=10%`. Первая анализирует структуру репозитория, вторая дополнительно считывает часть содержимого и сверяет контрольные суммы. У Borg для глубокой проверки используется `borg check --verify-data`. Такая операция читает весь репозиторий, поэтому её обычно планируют на период низкой нагрузки.
Если резервные копии создаются собственными скриптами через tar и cron, полезно формировать манифест контрольных сумм:
```bash
find backup/ -type f -print0 | sort -z | xargs -0 sha256sum > backup.sha256
sha256sum -c backup.sha256
```
Это помогает обнаружить повреждённые или изменённые файлы, но не отвечает на главный вопрос: можно ли использовать их после восстановления.
Практическая учебная тревога
Второй уровень - регулярное пробное восстановление. Для файлового сервера достаточно выбрать несколько объектов разных типов и размеров: документ, архив, изображение, большой файл и каталог с большим количеством вложений. Их следует восстановить в изолированную директорию или тестовую виртуальную машину, после чего проверить права доступа, даты изменения, содержимое и возможность открытия.
Для баз данных процедура сложнее. Нужно развернуть временный экземпляр, загрузить туда резервную копию и выполнить контрольные запросы. Важно проверить не только наличие таблиц, но и количество строк, индексы, внешние ключи, права пользователей, хранимые процедуры и актуальность последних транзакций. Если база используется приложением, стоит запустить и само приложение: успешная загрузка дампа ещё не гарантирует его работоспособность.
Подробный разбор уровней контроля, типичных ошибок и организации процедуры восстановления представлен в материале о [проверке резервных копий и восстановлении данных](https://habr.com/ru/companies/ruvds/articles/1076952/?utm_campaign=1076952&utm_source=habrahabr&utm_medium=rss). На практике особенно полезно заранее описать пошаговый сценарий: где развернуть временную инфраструктуру, какие учётные данные использовать, в каком порядке запускать сервисы и кто принимает решение о результате.
Мониторинг самой системы резервного копирования
Третий уровень касается не архива, а процесса его создания. Система резервного копирования и восстановления должна контролировать успешность заданий, объём полученных данных, длительность операций, свободное место и срок хранения копий. Резкое уменьшение размера архива часто указывает на то, что часть каталогов перестала включаться в задание.
Уведомления необходимо отправлять в независимый канал - например, в отдельную систему мониторинга, мессенджер или на другой почтовый домен. Если сообщения об ошибках доставляются на тот же сервер, который пострадал вместе с основной инфраструктурой, их ценность невелика. Для критичных систем полезно вводить понятные метрики: возраст последней успешной копии, время восстановления и долю проверенных архивов.
Отдельного внимания требуют базы данных. Копирование файлов работающего экземпляра не всегда даёт согласованную картину: часть транзакций может находиться в памяти, а таблицы - изменяться в момент чтения. Нужно использовать штатные механизмы СУБД, журналы транзакций, снимки или режимы, гарантирующие согласованность. Также следует периодически тестировать восстановление на другой версии сервера, если планируется обновление программного обеспечения.
Секреты и конфигурации - часть бэкапа
Даже полностью восстановленная база не поможет, если потеряны конфигурационные файлы, сертификаты, ключи шифрования, переменные окружения, правила firewall и описания инфраструктуры. Поэтому в резервное копирование необходимо включать не только пользовательские данные, но и всё, что требуется для запуска сервисов.
При этом секреты нельзя хранить в открытом виде в обычном архиве. Для них используют менеджеры секретов, шифрование и отдельные политики доступа. Проверка восстановления должна подтверждать, что после возврата данных приложение может подключиться к базе, прочитать необходимые ключи и корректно обработать зашифрованные поля.
Хорошая практика - составить план восстановления после аварии с указанием приоритетов. Сначала возвращаются DNS, сеть, система идентификации и хранилище секретов, затем базы данных, очереди, файловые сервисы и прикладные компоненты. Для каждого шага фиксируются ответственные, команды и ожидаемый результат.
Наконец, процедуру стоит проводить не только силами администратора, который её разрабатывал. Другой сотрудник должен суметь выполнить её по документации без устных пояснений. Если план восстановления нельзя повторить, он остаётся теорией. Поэтому лучший ответ на вопрос, как проверить резервную копию, - не открыть архив, а регулярно восстановить из него данные в независимой среде, проверить их полноту и убедиться, что бизнес-сервис действительно продолжает работу.
