Почему бэкапы сложнее, чем кажется

17.09.2026 · 5 мин

Каждый, кто хоть раз терял важные файлы, знает это чувство — немного паники, немного стыда и мысль: «Ну почему я не сделал копию?»

У меня есть знакомый, который хранил все семейные фотографии на одном внешнем диске. Решение вроде разумное: вынес важное на отдельный носитель, освободил место на компьютере. Проблемы начались, когда его отец решил использовать этот диск для ТВ-приставки. Приставка вежливо предложила отформатировать диск. Отец нажал «ОК». Все фотографии пропали.

Звучит как история про невнимательность. Но автор статьи Backups Aren’t Simple — Александар Филиповски — указывает на другое. Это цепочка системных ошибок, а не одна человеческая оплошность.

Давайте разберёмся, почему бэкапы на самом деле сложнее, чем кажется.

Заблуждение: бэкап — это просто копия

Первое, что приходит в голову: бэкап — это когда ты копируешь файл в другое место. Закрыл тему.

Не тут-то было.

Филиповски описывает уровни сложности, которые нарастают как снежный ком. И начинается всё с простого вопроса: а что вообще может пойти не так?

Носители данных умирают. Жёсткие диски содержат магнитные частицы, которые могут самопроизвольно менять полярность — это называется bit rot, постепенная порча данных при хранении. Твердотельные накопители страдают от утечки заряда в NAND-транзисторах. Диск можно уронить, его могут украсть, квартира может пострадать от потопа.

Вывод: нам нужно как минимум две копии в разных местах.

Но и это не всё. Обычное зеркалирование (RAID 1, когда данные дублируются на два диска одновременно) не защищает от программных ошибок. Случайно удалил файл — он пропал с обоих дисков. Сработал ransomware — всё зашифровано на обоих дисках. Нам нужна возможность вернуться к состоянию на вчера, на прошлую неделю.

Вывод: нам нужны снимки (снапшоты) с разными временными метками.

Ротация: как часто делать снимки и сколько хранить

Допустим, мы решили делать резервную копию раз в день. Отлично. Но сколько дней хранить?

Если мы храним все снимки, через год у нас 365 версий. Это и дорого, и бессмысленно — данные за первое января вряд ли понадобятся через год. Но и удалять все старые снимки сразу глупо.

Филиповски приводит элегантное наблюдение: файлы меняются по закону с «толстым хвостом» (fat-tailed distribution). Большинство файлов не меняются вообще, а некоторые меняются постоянно. Это значит, что нам не нужны одинаковые интервалы между снимками.

РОТАЦИЯ СНИМКОВ
────────────────
Текущий день    ────▶  ЕЖЕДНЕВНО (14 дней)
Прошлая неделя  ────▶  ЕЖЕНЕДЕЛЬНО (7 недель)
Прошлый месяц  ────▶  ЕЖЕМЕСЯЧНО (12 месяцев)

Глубина ────────────────────────────────────▶
Частота ▼ частые   ▼▼ редкие
Схема GFS-ротации: чем дальше в прошлое, тем реже снимки

Это называется GFS-ротация (Grandfather-Father-Son — дед-отец-сын). Мы храним 14 ежедневных снимков, поверх них 7 еженедельных, и 12 ежемесячных. Потери при аварии — максимум один день. Исторические архивы сохраняются без раздувания хранилища.

Дедупликация: умное хранение

Вернёмся к математике. Если мы храним 14 ежедневных снимков папки с фотографиями, значит ли это, что каждый снимок занимает полный объём?

Нет. Большинство фотографий не меняются днями и неделями. Здесь на помощь приходит дедупликация — хранение уникальных файлов только один раз.

Филиповски описывает подход, который использует rsnapshot: мы создаём жёсткие ссылки. Жёсткая ссылка — это когда один файл на диске имеет несколько «имён» в разных директориях. Физически файл занимает место один раз, но мы можем видеть его в каждом снимке.

Когда приходит время ротации, мы просто удаляем «старое имя», но сам файл остаётся, пока на него ссылается хотя бы один снимок.

ДЕДУПЛИКАЦИЯ ЖЁСТКИМИ ССЫЛКАМИ
───────────────────────────────
Диск (физически):
┌─────────────────────────────────┐
│  photo_vacation.jpg (1 копия)   │ ◀── ссылка с snapshot_1
│                                 │ ◀── ссылка с snapshot_2
│  photo_birthday.jpg (1 копия)   │ ◀── ссылка с snapshot_2
│  new_photo.jpg (1 копия)        │ ◀── ссылка с snapshot_2
└─────────────────────────────────┘

Логически:
snapshot_1:  photo_vacation.jpg
snapshot_2:  photo_vacation.jpg, photo_birthday.jpg, new_photo.jpg
Жёсткие ссылки: один файл на диске, много «имён» в снимках

Экономия места колоссальная. А ещё это экономит bandwidth при передаче в облако.

Подводные камни: базы данных, права доступа, облако

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

Базы данных. Многие приложения хранят данные в памяти и сбрасывают их на диск порциями для производительности. Если мы скопируем файлы базы данных в момент, когда они в противоречивом состоянии, восстановление не удастся. Нужно делать дамп базы — экспортировать данные в согласованном формате, и только потом бэкапить.

Права доступа. Docker-контейнеры любят создавать файлы от имени root. Если ваш скрипт резервного копирования работает от обычного пользователя, он не сможет прочитать эти файлы. А если работает от root, появляется риск утечки прав при компрометации.

Облачное хранение. Если вы решите хранить бэкапы в S3-совместимом хранилище, вас ждут сюрпризы. S3 не сохраняет метаданные файлов (права, владельца). А стоимость зависит от количества операций — миллион маленьких файлов обойдётся в круглую сумму. Решение: упаковывать файлы в tar-архивы. Но как тогда делать инкрементальные бэкапы? Это уже задача уровня «написать свою систему».

Правило 3-2-1

Филиповски упоминает принцип, который знает каждый сисадмин:

Почему это важно? Если у вас два диска одной модели, они могут умереть одновременно — у дисков бывают массовые отзывы из-за брака. Если бэкап лежит в том же здании, пожар уничтожит всё.

Главное: тестируйте восстановление

Самая горькая ирония резервного копирования: все усилия ничего не стоят, если вы не проверяете, работает ли восстановление.

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

Знакомая ситуация: бэкап делается исправно, админ гордится, все спокойны. А потом случается инцидент, данные пытаются восстановить — а архив битый или восстановление занимает вдвое дольше ожидания. И все понимают, что регулярных проверок не было.

Практический вывод

Системы резервного копирования — это не «записать файл на флешку». Это инфраструктура, которая требует проектирования, поддержки и тестирования.

Автор статьи резюмирует это с горькой иронией: если вы дочитали до конца и поняли всё, что описано, вы уже мысленно находитесь в точке, где собственная реализация бэкапов кажется адом. Поэтому правильный ответ — использовать проверенные инструменты вроде Borg или Restic. Они уже решают все описанные проблемы: дедупликацию, ротацию, работу с облаком, шифрование.

Мой вывод: если вы откладываете настройку бэкапов «на потом», вспомните историю про фотографии. Не потому что случится катастрофа — случится она может. А потому что цена катастрофы всегда выше, чем цена подготовки. Причём эта цена не только в данных, но и в времени и нервах, которые вы потратите на восстановление из «бэкапа», который не открывается.

Ссылки

Дмитрий Полухин — продуктовый дизайнер. Пишу про разработку, AI и дизайн интерфейсов. Обо мне, контакты и профили.

Что почитать дальше