ПРАКТИЧЕСКИЕ ЗАМЕТКИ / РЕЗЕРВНЫЕ КОПИИ

Сохранить — и суметь восстановить

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

Начните с того, что придётся восстанавливать

Состав копии зависит от приложения. Одних пользовательских файлов может быть недостаточно: конфигурация, версии компонентов, права доступа и ключи тоже могут понадобиться для восстановления.

  • Данные, которые нельзя получить заново.
  • Конфигурации и сведения о нужных версиях.
  • Права, владельцы и важные атрибуты файлов.
  • Ключи и сертификаты, если их сохранение необходимо.
  • Инструкция запуска и проверки результата.

Не включайте секреты в обычный публичный архив проекта. Если они нужны в резервной копии, ограничьте доступ к ней и предусмотрите защищённое хранение.

Работающее приложение требует согласованной копии

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

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

ВАЖНО ДЛЯ ПРАКТИКИ

Снимок диска и резервная копия приложения решают разные задачи. Уточните гарантии согласованности конкретного инструмента.

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

rsync -a --dry-run --itemize-changes /srv/data/ /mnt/backup/data/

Пути условные. Завершающий слеш влияет на смысл копирования в rsync. Сначала проверьте источник, назначение и список изменений; особенно внимательно относитесь к параметрам удаления.

Копия на том же диске — только один уровень защиты

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

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

Шифрование защищает копию только при правильном обращении с ключом. Хранить единственный ключ исключительно внутри той же зашифрованной копии — значит лишиться возможности её открыть.

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

Проверка восстановления важнее отметки «успешно»

Проверяйте копию в отдельном каталоге или изолированном окружении. Не распаковывайте её поверх работающих данных только ради теста.

  1. Убедитесь, что архив или набор файлов читается.
  2. Проверьте целостность средствами используемого формата или приложения.
  3. Восстановите данные отдельно от исходной системы.
  4. Проверьте права, запуск и несколько основных операций.
  5. Запишите необходимое время и обнаруженные зависимости.

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

Перед изменением оставьте короткий план отката

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

Хорошая инструкция отвечает на три вопроса: что вернуть, в каком порядке это сделать и как понять, что система снова работает. Проверять её удобнее до изменения, когда ещё нет необходимости торопиться.

Подробнее: механизм резервного копирования SQLite и руководство rsync.