Резервное копирование сайтов, баз данных и документов с проверкой восстановления

Самая опасная фраза про бэкапы звучит так: «вроде делаются». Обычно за ней стоит вот что. Когда-то кто-то что-то настроил, а скрипт молча умер полгода назад. Копии при этом складываются на тот же диск, где живёт сам сайт.

Выясняется всё это в худший момент: после падения диска, взлома или «я случайно удалил папку». Восстанавливать оказывается не из чего. Мы настраиваем резервное копирование так, чтобы на вопрос «а бэкапы есть?» был проверяемый ответ.

Правило 3-2-1 и почему его одного мало

За основу берём классическую схему 3-2-1. Три копии данных минимум, на двух разных типах носителей. Одна копия лежит вне основной площадки.

Копия рядом с сервером спасает от «ой, удалил», но от пожара, взлома или блокировки хостинга она уже не спасёт. Поэтому одна копия всегда уезжает в независимое хранилище: обычно это S3-совместимое облако российского провайдера.

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

Что входит в работу

• Аудит того, что есть сейчас: что копируется, куда, как давно и восстанавливалось ли хоть раз.
• Считаем RPO и RTO простыми словами: сколько часов данных вам не жалко потерять и за какое время нужно подняться. От этих двух цифр зависит вся схема и её цена.
• Настраиваем резервное копирование сайтов, баз данных, файловых архивов и рабочих документов по расписанию.
• Уводим копии в независимое хранилище, за пределы основного хостинга. Для критичных данных добавляем защиту от изменения и удаления (immutable-копии): вымогатель не зашифрует их вместе с основными данными.
• Настраиваем мониторинг: алерт приходит тогда, когда копия не создалась. Тишина в обе стороны отчётом не считается.
• Проводим тестовые восстановления по календарю и после каждого пишем короткий отчёт: что развернули, сколько заняло, что заметили.
• Пишем инструкцию по восстановлению. Задача такая: по ней должен поднять сайт человек, который её не писал.

Что вы получите

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

Что находим на аудите чаще всего

Бэкап базы «на горячую». Файлы копируются без выгрузки. Восстановиться из такой копии нельзя, и выясняется это только при попытке развернуть.

Копии без ротации. Они годами копятся и съедают всё хранилище. Потом бэкапы отключают «временно». Это временно длится вечно.

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

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

Опишите задачу в форме ниже. Что нужно защитить (сайт, базы, документы), где это живёт сейчас и делались ли бэкапы раньше. Проведём аудит и предложим схему с понятными точками восстановления.