Бэкап в стиле DevOps: 31 марта – World Backup Day

31 марта отмечают World Backup Day (Международный день резервного копирования). Удобный повод не для красивого статуса, а для проверки: есть ли свежая копия, открывается ли она, и не лежит ли единственный «бэкап» на том же диске, что и прод.

Бэкап в логике DevOps

В DevOps любят автоматизацию, наблюдаемость и спокойный on-call. Бэкап в том же духе: не разовый tar -czf «на всякий», а повторяемый процесс с расписанием, off-site, шифрованием, retention и регулярным restore-тестом. Копия, которую никто не восстанавливал, гипотеза, а не страховка.

Даже без апокалипсиса сценарии простые: ошибочный rm, кривой миграционный скрипт, ransomware, умерший SSD, «почистили» не тот бакет. 1 апреля рядом с 31 марта лишний мем, но реальные инциденты не ждут календаря.

Инструменты: от rsync до облака

1. rsync точечная синхронизация на другой диск или хост. Понятный контроль «что куда». С --progress видно ход, с snapshot-схемами (hardlink/ротация каталогов) можно собрать простую историю версий.
2. BorgBackup дедупликация, сжатие, шифрование, репозиторий с версиями. Хорош для серверов и homelab, когда важны инкременты без раздувания диска.
3. Restic похожий класс задач, удобные бэкенды (S3, B2 и др.), простой CLI. Часто выбирают, когда цель «set and monitor» в объектное хранилище.
4. Veeam / Acronis энтерпрайз-контур (ВМ, агенты, политики, отчёты). Имеет смысл там, где уже есть лицензии и требования compliance, а не «вместо cron на одном VPS».
5. cron / systemd timer то, без чего «инструмент» не становится процессом. Ночной прогон + алерт на ненулевой exit code важнее красивого GUI.

Минимальный каркас на rsync (идея, пути подставьте свои):

# пример: данные на второй диск / NAS
rsync -aHAX --delete --info=progress2 \
  /var/www/ /mnt/backup/www/

# лог + код возврата удобно слать в monitoring
echo "rsync exit: $?" >> /var/log/backup-rsync.log

Для Borg/Restic логика та же: init репозитория один раз, дальше create/backup по расписанию, prune по политике, restore на staging.

Практические правила

• Проверяйте восстановление. Раз в квартал (или чаще для критичных систем) полный restore на чистый стенд. «Зелёный» статус job ≠ читаемый архив.
• Храните копии в разных местах (3-2-1). Три копии, два типа носителей, одна off-site (другой сервер, S3, лента что уместно).
• Шифруйте off-site. Утечка бэкапа с дампами БД и .env хуже, чем отсутствие копии на флешке в ящике.
• Несколько версий (retention). Иначе «бэкап есть», но в нём уже та же битая миграция, что в проде.
• Политика хранения. Сколько дней/недель, кто имеет ключи, где runbook на restore, что делать при смене пароля репозитория.

Типичный фейл

Идеально настроенный пайплайн, Terraform-бакет, шифрование и пароль/ключ репозитория только в голове одного человека или в одном менеджере без эскроу. В день аварии выясняется, что «как расшифровать» знает только отпуск. Ключи и доступ к restore часть backup-системы, не «отдельная магия».

Если серьёзный стек ещё не собран, начните с малого: важный каталог + внешний диск или S3 + расписание + один успешный restore. Дальше дедуп, алерты, runbook.

Кратко

• World Backup Day повод прогнать restore, а не только сделать снимок;
• rsync / Borg / Restic (+ cron) закрывают большинство self-hosted сценариев;
• 3-2-1, шифрование off-site, retention, мониторинг job;
• ключи восстановления и runbook храните не в единственной голове.

Источники и ссылки