Бэкапы сайта: стратегия 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-ФЗ.
• Ротация: день / неделя / месяц.
• Тест восстановления раз в квартал с замером времени.

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