Бэкапы, которые восстанавливаются: правило 3-2-1 на практике

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

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

Что нужно сохранять

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

• База данных. Заказы, клиенты, содержимое сайта. Самое ценное и самое изменчивое.
• Загруженные файлы. Изображения товаров, документы, вложения — всё, чего нет в репозитории.
• Код. Если он лежит в системе контроля версий, это уже копия. Если правки вносились прямо на сервере — нет.
• Конфигурация и секреты. Настройки веб-сервера, PHP и базы, файлы окружения с паролями и ключами, задания cron. В репозиторий они обычно не попадают, а без них проект не запустится.
• То, что вокруг. Почтовые ящики, если почта живёт на том же сервере, и выгрузка DNS-зоны. О них вспоминают в последнюю очередь.

RPO и RTO простыми словами

У этих сокращений понятный житейский смысл.

• RPO — сколько данных вы готовы потерять. Если копия делается раз в сутки ночью, а авария случилась вечером, пропадёт рабочий день: заказы, оплаты, заявки. Для сайта-визитки это пустяк, для интернет-магазина — нет.
• RTO — сколько времени вы готовы не работать. В него входит всё: заметить проблему, принять решение, получить новый сервер, скачать копию, развернуть её, проверить и переключить адрес.

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

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

Формула короткая: три копии данных, на двух разных хранилищах, одна из них — на другой площадке. Для обычного проекта это выглядит так:

1. Рабочие данные на сервере.
2. Локальная копия для быстрого восстановления — на отдельном диске или соседней машине. Спасает от ошибочного удаления и неудачного обновления.
3. Копия во внешнем хранилище — у другого провайдера или хотя бы в другом дата-центре. Спасает, когда недоступен сам сервер или вся площадка.

Стоит договориться и о том, что бэкапом не является. Зеркалирование дисков защищает от поломки диска, но послушно повторит удаление таблицы на обоих. Репликация базы переносит ошибку на реплику за доли секунды. Снимок виртуальной машины у того же провайдера лежит в том же аккаунте и пропадёт вместе с ним. Всё это полезные вещи, но они про доступность, а не про сохранность.

Внешнее хранение и шифрование

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

• Раздельные доступы. Сервер должен уметь записать копию в хранилище, но не должен уметь удалить старые. Иначе тот, кто получил доступ к серверу, получил доступ и к бэкапам.
• Глубина хранения. Ошибку замечают не сразу. Если копии хранятся неделю, а испорченные данные обнаружили через десять дней, испорчены уже все версии. Обычно сочетают ежедневные копии за последние недели с более редкими за месяцы.
• Шифрование до отправки. В архиве лежат персональные данные клиентов и пароли, поэтому в чужое хранилище он должен попадать зашифрованным.
• Ключ отдельно. Ключ шифрования, который хранится только на резервируемом сервере, пропадёт вместе с ним — и копии станут набором байтов. Держите его в надёжном месте, известном более чем одному человеку.

Если в базе есть персональные данные граждан России, требования к месту хранения распространяются и на копии. О них — в статье «152-ФЗ простыми словами».

Проверка восстановлением

Резервная копия, которую ни разу не разворачивали, — это предположение, а не копия.

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

Минимальная проверка для базы MariaDB или MySQL выглядит так:

# дамп без блокировки таблиц InnoDB; доступы берутся из ~/.my.cnf
# в MySQL те же команды называются mysqldump и mysql
mariadb-dump --single-transaction --routines --events shop | gzip > shop-$(date +%F).sql.gz

# архив не повреждён
gzip -t shop-2026-08-13.sql.gz

# пробное восстановление в отдельную базу
mariadb -e "CREATE DATABASE shop_restore"
gunzip -c shop-2026-08-13.sql.gz | mariadb shop_restore

Дальше — сравнить число строк в ключевых таблицах и дату последней записи. Такую проверку стоит автоматизировать и получать уведомление в двух случаях: когда копия не создалась и когда она подозрительно мала.

Типичные провалы и короткий чек-лист

Истории о потерянных данных похожи друг на друга:

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

Чтобы не оказаться в этом списке, достаточно честно ответить на несколько вопросов.

1. Перечислено ли всё, что нужно для запуска проекта на пустом сервере?
2. Сколько данных и сколько времени мы готовы потерять — и соответствует ли этому расписание копий?
3. Есть ли копия за пределами сервера и площадки, с отдельным доступом?
4. Зашифрованы ли копии и где лежит ключ?
5. Когда последний раз проводилось восстановление и сколько оно заняло?
6. Кто узнает, если ночная копия не создалась?
7. Есть ли письменная инструкция по восстановлению, понятная второму человеку?

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