Бэкап сервера: зачем проверять восстановление

Когда я беру сервер на обслуживание, первым делом спрашиваю: «Резервные копии есть?» Ответ почти всегда «да». На следующий вопрос — «Когда вы последний раз что-нибудь из них восстанавливали?» — обычно отвечают молчанием.

Именно здесь резервное копирование обычно и сломано. Не потому, что копии не делаются, а потому, что никто не знает, можно ли из них на самом деле что-то вернуть.

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

Почему «бэкапы есть» часто не соответствует действительности

Типичные ситуации:

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

Правило 3-2-1 простыми словами

• 3 копии данных (оригинал плюс две резервные),
• на 2 разных носителях или в разных системах,
• 1 копия в другом месте — в другом дата-центре или у другого провайдера.

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

Что копировать — и что нет

Копируйте:

• Базы данных (PostgreSQL, MySQL/MariaDB) — полноценным дампом или методом, который даёт согласованное состояние. Не слепой копией файлов работающей базы.
• Файлы приложения, которые создают пользователи: загрузки, документы, изображения.
• Настройки: конфигурацию веб-сервера (Nginx, Apache2), файлы настроек приложения, задания по расписанию, файлы Docker compose и переменные окружения.
• Сертификаты и ключи — в зашифрованном виде.

Не тратьте место на:

• файлы операционной системы, которые можно установить заново;
• кэши и временные файлы;
• образы Docker, которые можно снова скачать из реестра (копируйте тома с данными, а не контейнеры).

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

Сколько хранить копии

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

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

Тест восстановления: два вопроса, на которые нужен ответ

Ещё до того, как что-то случится, стоит договориться о двух цифрах:

• Сколько данных можно потерять? Если копия делается раз в сутки, в худшем случае вы потеряете целый день работы. Если это слишком много, нужно копировать чаще.
• Как долго система может не работать? Должно ли восстановление уложиться в час или может занять день?

Тест восстановления показывает, достижимы ли эти цифры на самом деле. Мой порядок простой:

1. Беру случайную резервную копию — не всегда самую свежую.
2. Восстанавливаю её в отдельную тестовую среду, а не на рабочий сервер.
3. Проверяю, что база запускается, приложение открывается и последние данные на месте.
4. Замеряю, сколько это заняло времени, и записываю всё, что пошло не так, как было в инструкции.

И одна автоматическая защита: для резервного копирования нужно оповещение, если копия не сделана или подозрительно мала. Тихая ошибка — самая дорогая ошибка в резервном копировании.

Резервное копирование и тесты восстановления входят в моё администрирование серверов — что ещё входит в договор обслуживания, я описал в статье Обслуживание Linux-сервера: что входит в договор. Если вы переезжаете на новый сервер, свежий тест восстановления — лучшая проверка перед тем, как обновлять старый сервер Ubuntu.

Часто задаваемые вопросы

Разве резервной копии хостинг-провайдера недостаточно?

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

Как часто проверять восстановление?

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

RAID — это резервная копия?

Нет. RAID защищает от выхода из строя одного диска, но удалённый файл или данные, зашифрованные вымогателем, удаляются или шифруются сразу на всех дисках.

Приложение в Docker копируется как-то иначе?

Принцип тот же: копируйте данные и настройки, а не контейнер. База данных в контейнере по-прежнему копируется полноценным дампом, а не сырой копией тома во время работы.

Ваши резервные копии действительно проверены?

Если вы не знаете точно, когда из резервной копии вашего сервера последний раз что-то восстанавливали, напишите мне. Я проверю, что копируется, куда и как долго хранится, и проведу первый тест восстановления вместе с вами. Подробнее о том, как я администрирую серверы, — на странице Администрирование Linux-серверов.