Бэкапы сайта: стратегия 3-2-1, автоматизация, хранение в РФ

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

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

Отраслевой стандарт надёжного бэкапа формулируется тремя цифрами:

• 3 копии данных — оригинал плюс два бэкапа.
• 2 разных носителя — например, диск сервера и объектное хранилище, а не две папки на одной машине.
• 1 копия offsite — физически в другом месте: другой ЦОД, другое облако. Сгорит стойка с сервером — копия уцелеет.

Смысл правила — ни один единичный сбой (диск, сервер, ЦОД, шифровальщик) не должен уничтожать все копии сразу.

Что бэкапить

Сайт — это две сущности, и обе нужны:

• Файлы — код, загруженные пользователями медиа, конфиги. Медиа особенно: их не восстановить из репозитория.
• База данных — заказы, пользователи, контент. Снимаем дампом, а не копированием файлов БД «на живую».

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

Автоматизация: cron, mysqldump, rsync

Ручной бэкап забывают. Всё, что делается регулярно, вешаем на cron:

# дамп базы каждую ночь в 3:15
15 3 * * * mysqldump -u u -p'pass' --single-transaction db   | gzip > /backup/db-$(date +\%F).sql.gz

# синхронизация в offsite-хранилище
30 3 * * * rsync -az /backup/ user@storage:/backups/site/

mysqldump со флагом --single-transaction снимает согласованную копию без остановки сайта. rsync докидывает только изменения — быстро и дёшево по трафику.

Шифрование и хранение в РФ

Бэкап — это те же персональные данные, только в архиве. Если храните данные россиян, по 152-ФЗ первичная база (а значит, и её копии) должна находиться на серверах в РФ. Практика:

• Хранилище для offsite-копий — российское: облако или объектное хранилище в РФ.
• Архивы шифруем перед отправкой (gpg или встроенное шифрование хранилища) — украденный бэкап не должен читаться.
• Доступ к бэкапам — по отдельным ключам, а не под общим паролем от сервера.

Ретеншен: сколько копий держать

Хранить всё вечно дорого, одну последнюю копию — опасно: успеете перезаписать её испорченными данными. Разумная схема ротации:

• Ежедневные — за последние 7 дней.
• Еженедельные — за 4-5 недель.
• Ежемесячные — за 6-12 месяцев.

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

Главное — тест восстановления

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

• Раз в квартал разворачивайте бэкап на тестовом сервере — целиком.
• Замеряйте, сколько заняло восстановление: это ваш реальный RTO.
• Проверяйте, что данные на месте, а не только что «архив распаковался».

Правило простое: непроверенного бэкапа не существует.

Чеклист и вывод

• Три копии, два носителя, одна offsite.
• Файлы и дамп БД — обе сущности.
• Автоматизация через cron, без ручных запусков.
• Шифрование и хранение копий в РФ под 152-ФЗ.
• Ротация: день / неделя / месяц.
• Тест восстановления раз в квартал с замером времени.

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