Резервное копирование сайта: стратегия, которая работает

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

Начните с правила 3-2-1: три копии данных, на двух разных типах хранилищ, одна из них — вне площадки. Для сайта первой копией считается сам рабочий сайт, второй — резервные копии хостера, третьей — архив, который вы скачиваете в хранилище под своим контролем. Затем составьте список всего, что нужно для полного восстановления. Файлы сайта, загрузки и базы данных очевидны. Менее очевидны почтовые ящики, задания cron, настройки PHP, правила .htaccess или nginx, API-ключи и файлы окружения, а также экспорт DNS-зоны: восстанавливать сорок записей по памяти во время сбоя долго и чревато ошибками.

Частота копирования следует из двух вопросов. Сколько работы вы можете позволить себе потерять? Это целевая точка восстановления, RPO. Как долго сайт может не работать, пока вы его восстанавливаете? Это целевое время восстановления, RTO. Сайту-визитке, который меняется раз в месяц, хватит ежедневной копии. Магазину, который принимает заказы весь день, — нет: каждый час между копиями означает час заказов, которые придётся вносить вручную. Срок хранения важен не меньше частоты: проблемы часто замечают через несколько дней, поэтому держите несколько ежедневных копий, пару еженедельных и хотя бы один ежемесячный снимок.

Резервные копии хостера необходимы, но недостаточны. На виртуальном хостинге WebHostFlow каждый сайт и каждая база данных каждую ночь копируются на отдельную инфраструктуру, хранятся 14 дней и восстанавливаются из панели управления — это покрывает большинство случайностей за пару кликов. Но эти копии находятся у того же провайдера и в том же аккаунте. Если проблема в споре по оплате, украденном пароле или ошибке в самом аккаунте, нужна копия, до которой никто другой не дотянется. Регулярно скачивайте полный архив и храните его отдельно — например, в зашифрованном облачном хранилище или на диске в офисе.

Базы данных требуют особого внимания. Копирование «сырых» файлов работающего сервера MySQL или PostgreSQL может дать копию, которая выглядит полной, но не запускается, потому что данные менялись прямо во время копирования. Используйте нормальный дамп: mysqldump с параметром --single-transaction для таблиц InnoDB или pg_dump для PostgreSQL — оба дают согласованный снимок без блокировки сайта. Сожмите дамп, добавьте в имя дату и время и проверьте, что файл не подозрительно мал. Дамп нулевого размера, который полгода каждую ночь «успешно» создавался, — на удивление частая находка.

Взлом сайта или вирус-шифровальщик меняют сам смысл восстановления. Злоумышленники часто неделями сидят тихо, прежде чем что-то станет заметно, поэтому самая свежая копия может уже содержать бэкдор. Определите по журналам доступа и датам изменения файлов, когда началась компрометация, восстановите сайт из копии, сделанной до этого момента, смените все пароли и ключи и обновите ПО, через которое проникли атакующие. Здесь окупаются долгое хранение и частые точки восстановления: премиум-хостинг хранит ежечасные копии 30 дней, так что можно уйти дальше в прошлое и потерять меньше. И регулярно проверяйте восстановление: разверните копию на тестовом сайте и пройдитесь по нему.

Простой ежемесячный чек-лист держит всё это под контролем. Убедитесь, что последние автоматические копии завершились и имеют правдоподобный размер. Скачайте свежую внешнюю копию файлов, баз данных и почты. Экспортируйте DNS-зону и запишите изменения в конфигурации. Восстановите одну копию в тестовое место и проверьте, что страницы, вход и формы работают. Удалите внешние копии старше вашего срока хранения. Это занимает меньше часа и превращает резервное копирование из надежды в процедуру. В WebHostFlow половину работы на стороне хостинга — на виртуальном и премиум-хостинге — берём на себя мы, а на вас остаются внешняя копия и проверка.