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

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

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

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

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

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

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

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

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

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

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

Кнопка «резервная копия» в панели хостинга закрывает первый случай и проваливает два остальных. Она копирует сайт рядом с сайтом, и при потере аккаунта вы теряете и копии.

Сколько данных вы готовы потерять

Это и есть RPO, а RTO значит, за сколько вы обязаны подняться. Два вопроса, с которых начинается схема. Вот как это выглядит на живых примерах.

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

Схему подбираем под ценность данных, а не «максимальную на всякий случай». Частые копии стоят денег, и платить их за сайт, который меняется раз в квартал, незачем.

Настройка резервного копирования: что входит в работу

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

Где лежат копии и кто за них платит

Отдельное хранилище арендуем у российских провайдеров: Object Storage в Яндекс Облаке, VK Cloud, Selectel, Timeweb. Выбираем по цене за гигабайт и по тому, где уже живёт ваша инфраструктура.

Счёт за хранилище приходит вам напрямую от провайдера, и аккаунт тоже ваш. Так копии остаются у вас, даже если мы разойдёмся. Для сайта с базой это обычно 300-900 рублей в месяц, для файлового архива на пару терабайт счёт вырастает до нескольких тысяч.

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

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

Базовый режим: раз в квартал разворачиваем копию на чистой площадке и проверяем, что сайт открывается, а база целая. Для критичных систем делаем это раз в месяц.

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

Сколько это стоит и сколько занимает

Точную смету считаем после аудита, но порядок цифр называем сразу.

• Аудит текущих бэкапов. От 15 тысяч рублей, три-пять рабочих дней. На выходе отчёт: что копируется, что нет, из чего вы реально поднимаетесь.
• Настройка схемы для сайта с базой. От 30 тысяч рублей, неделя. Расписание, внешнее хранилище, мониторинг, первое тестовое восстановление и инструкция.
• Схема для парка серверов и учётных систем. От 90 тысяч рублей, две-три недели. Несколько источников, разная глубина хранения, защита копий от удаления.
• Сопровождение. От 8 тысяч рублей в месяц: следим за алертами, чиним сломавшиеся задания, раз в квартал проводим тест и присылаем отчёт.

Аренда самого хранилища сюда не входит, вы платите за неё провайдеру напрямую.

Что нужно от вас

Проект короткий, и вашего времени он съест немного.

• Доступы. Сервер, хостинг, панель, учётная система. Час-два работы вашего админа.
• Ответ на два вопроса. Сколько данных не жалко потерять и за какое время нужно подняться. Полчаса разговора, и схема определена.
• Окно для теста. Тестовое восстановление идёт на отдельной площадке и боевую не трогает, но разово может понадобиться выгрузка базы. Такое ставим на ночь.

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

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

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

Что происходит дальше

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

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

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

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