Резервное копирование: как не потерять данные проекта

Резервное копирование защищает от потери данных из-за сбоя сервера, ошибки разработчика, взлома или удаления по неосторожности. Надёжная схема — автоматические копии базы данных и файлов по правилу 3-2-1, хранение вне основного провайдера, шифрование и регулярная проверка восстановления. Бэкап, который ни разу не восстанавливали, нельзя считать бэкапом.

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

Что нужно резервировать?

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

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

Как устроить хранение файлов, мы разбирали в статье загрузка и хранение файлов.

Что такое RPO и RTO?

RPO и RTO — два показателя, с которых начинается любая схема резервирования. RPO отвечает на вопрос «сколько данных мы готовы потерять», RTO — «как быстро мы должны восстановиться». От них зависят частота копий, способ хранения и стоимость.

Показатель	Вопрос	Пример для интернет-магазина
RPO (Recovery Point Objective)	За какой период можно потерять данные	Не более 15 минут заказов
RTO (Recovery Time Objective)	Сколько может длиться восстановление	Не более 2 часов

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

Фото: Unsplash

Что такое правило 3-2-1?

Правило 3-2-1 гласит: держите три копии данных, на двух разных типах носителей, и одну — в другом месте. Для веб-проекта это рабочая база, копия у того же провайдера для быстрого восстановления и копия в хранилище другого провайдера на случай аварии или блокировки аккаунта.

Дополнительные правила:

1. Копии шифруются, а ключи хранятся отдельно от них.
2. У сервера приложения нет прав удалять старые копии — это защищает от шифровальщиков и ошибок.
3. Срок хранения многоуровневый: ежедневные, еженедельные и ежемесячные копии.
4. Об ошибках резервного копирования приходит оповещение, а не запись в лог, которую никто не читает.

Как часто делать копии базы данных?

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

# Ежедневный дамп PostgreSQL со сжатием и отправкой во внешнее хранилище
pg_dump --format=custom --compress=9 "$DATABASE_URL" \
  > "/backups/db-$(date +%F).dump"

aws s3 cp "/backups/db-$(date +%F).dump" \
  "s3://project-backups/db/" --storage-class STANDARD_IA

Управляемые базы данных в облаке обычно делают это сами, но стоит проверить, где хранятся копии, сколько дней и можно ли их выгрузить к себе. Про выбор между своим сервером и облаком — в статье VPS, облако или managed-сервисы.

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

Проверить бэкап можно только восстановлением: регулярно разворачивайте копию на отдельном сервере и убеждайтесь, что приложение с ней запускается, а данные свежие. Многие команды узнают, что копии были пустыми или битыми, именно в день аварии.

Чек-лист проверки:

• раз в месяц восстанавливайте базу из копии на тестовом сервере;
• замеряйте время восстановления и сравнивайте с RTO;
• проверяйте дату последней записи в восстановленной базе;
• храните пошаговую инструкцию восстановления, понятную не только автору;
• раз в полгода проводите учение: «сервер потерян, восстанавливаемся с нуля».

О том, как узнавать о сбоях вовремя, — в статье мониторинг и логирование, а о защите данных — в материале OWASP Top 10 простыми словами.

Коротко

• Резервируйте базу, файлы, конфигурацию и секреты — всё, что нельзя быстро получить заново.
• Начните с RPO и RTO: сколько данных можно потерять и как быстро восстановиться.
• Следуйте правилу 3-2-1 и храните одну копию у другого провайдера.
• Шифруйте копии и запретите серверу приложения их удалять.
• Регулярно восстанавливайте данные из копии — только так бэкап становится настоящим.