Резервное копирование и проверка восстановления

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

1. Определите, что защищаете

• Системные конфигурации: /etc/, собственные unit и профили сети.
• Учётные данные и ключи: требуют отдельного защищённого хранилища, не открытого публичного архива.
• Пользовательские данные и каталоги приложений.
• Данные контейнеров и volumes, включая метаданные Docker.
• Базы данных: желательно native backup приложения, а не простое копирование открытых файлов.
• План восстановления загрузчика, загрузочного раздела и списка пакетов.

2. Опись перед копированием

cat /etc/os-release
uname -r
findmnt -o TARGET,SOURCE,FSTYPE,OPTIONS
lsblk -f
rpm -qa --qf '%{NAME} %{VERSION}-%{RELEASE}\n' | sort
systemctl list-unit-files --state=enabled --no-pager

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

3. Пример файлового резервирования rsync

rsync присутствует в SPEC, но в минимальном образе может не быть установлен. Ниже пример без --delete для подготовленного и смонтированного отдельного backup-хранилища:

# Проверить, что backup-том действительно смонтирован
findmnt /mnt/backup || exit 1

# Вручную убедитесь, что /mnt/backup - отдельный носитель,
# не вложенный каталог на том же диске.
rsync -aHAX --numeric-ids --stats \
  /etc/ /mnt/backup/niceos-config-etc/

Для целых систем нужны политики исключений (/proc, /sys, /dev, /run, временные mountpoints), согласованность приложений, права, SELinux-метки и методы восстановления. Не интерпретируйте приведённую команду как полный образ хоста.

4. Проверка целостности

sha256sum /mnt/backup/niceos-config-etc/etc/hostname 2>/dev/null || true
findmnt /mnt/backup

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

5. Цели восстановления

Определите RPO (допустимая потеря данных) и RTO (допустимое время восстановления). Ежедневная копия подходит не всякой базе; возможно, нужны журналируемые инкрементальные резервные копии и проверенные средства бэкапа СУБД.

6. Тест восстановления

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

Источники: наличие rsync — Core/rsync/SPECS/rsync.spec; общий подход к резервированию/восстановлению; см. диски, fstab.