К содержимому

Четырнадцать бэкапов на той же машине, что и данные

Бэкапы есть, расписание работает, копии лежат в каталоге рядом с данными.

linuxcron

Разбирал собственный сервис и наткнулся на конфигурацию, которая выглядит образцово: backup.sh по cron в три ночи, четырнадцать копий с ротацией, восстановление однажды проверено вручную.

Всё правильно. Кроме одного: каталог с копиями лежит на той же виртуальной машине, что и сами данные.

Почему это не бэкап

Бэкап защищает не от повреждения файла. Он защищает от потери носителя.

Сценарии, в которых четырнадцать копий исчезают ровно так же, как оригинал:

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

Во всех четырёх случаях количество копий не имеет значения. Четырнадцать копий на одном носителе защищают ровно от одного класса проблем — «испортил файл, хочу вчерашнюю версию». Это полезно, но это версионирование, а не бэкап.

Правило, которое стоит держать в голове

Копия, которая умирает вместе с оригиналом, копией не считается.

Формализовано это в правиле 3-2-1: три копии, два разных типа носителя, одна — вне площадки. Можно спорить о деталях, но пункт «одна вне площадки» неоспорим, и именно его чаще всего и пропускают.

Что делать

Минимально достаточное — отправлять копию на отдельное хранилище:

# после снятия дампа — увезти его с машины
rsync -a --remove-source-files backups/ backup-host:/mnt/backup/<сервис>/

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

И проверка восстановления с датой. Бэкап, из которого ни разу не восстанавливались, — это гипотеза, а не бэкап. Дата последней успешной проверки должна лежать в runbook рядом с самой процедурой.

Почему так получается у всех

Потому что скрипт пишется в момент, когда решается задача «снять дамп». Задача решена, файл появился, галочка поставлена. Вопрос «а где он лежит относительно данных» не задаётся, потому что в этот момент он кажется второстепенным.

Проверить свои сервисы — дело пяти минут. Достаточно одного вопроса: если сейчас исчезнет эта машина целиком, что останется?

Дальше

Новые разборы выходят в Telegram раньше, чем попадают сюда. Без анонсов курсов — только материалы.

Читать в Telegram →