Резервная копия сайта нужна не только после взлома. Ошибка обновления, случайное удаление файла, сбой диска или неудачный перенос могут остановить работу проекта. Но наличие архива само по себе ещё не гарантирует восстановление: в нём может не оказаться базы данных, важных загрузок или настроек.
Разберём, что именно сохранять, как выбрать частоту копирования и как убедиться, что из резервной копии действительно можно вернуть рабочий сайт.
1. Определите, что составляет ваш сайт
Для статического сайта достаточно файлов страниц, изображений, стилей, скриптов и конфигурации размещения. У сайта на CMS обычно есть как минимум две независимые части: файлы приложения и база данных. Копирование только папки с WordPress, Joomla или другой CMS не сохраняет записи, настройки и содержимое базы.
Составьте перечень компонентов: исходный код, загруженные пользователями изображения и документы, база данных, конфигурация веб-сервера, расписания фоновых задач, настройки интеграций и сертификатов. Секреты и ключи храните отдельно с ограниченным доступом. Если используются внешние сервисы, запишите, какие данные находятся у них, а какие - на вашем сервере.
2. Разделяйте резервную копию и обычную синхронизацию
Синхронизация переносит изменения между устройствами или серверами. Если файл удалён или повреждён, ошибка может быстро распространиться и на вторую копию. Резервное копирование должно позволять вернуться к состоянию на конкретную дату.
Поэтому полезны версии: несколько последних ежедневных копий, несколько недельных и более старые контрольные точки. Хранение одной постоянно перезаписываемой папки не даёт возможности выбрать состояние до ошибки.
3. Используйте принцип нескольких независимых копий
Практический ориентир - правило 3-2-1: три экземпляра данных, два разных типа или независимых места хранения и один экземпляр вне основного сервера. Это не магическая формула, а способ снизить риск единой точки отказа.
Например, рабочий сайт находится на VDS, ежедневные архивы сохраняются в отдельном хранилище, а дополнительная копия периодически переносится в другую учётную запись или на отключаемый носитель. Важно, чтобы сбой, удаление или компрометация основного сервера не уничтожили все экземпляры одновременно.
4. Выберите частоту по допустимой потере данных
Сначала ответьте на вопрос: сколько новых данных допустимо потерять? Для редко обновляемого сайта-визитки может быть достаточно ежедневной копии. Для интернет-магазина с заказами, оплатами и изменением остатков даже сутки потери могут оказаться критичными.
Это называют целевым временем потери данных (RPO). Если допустимая потеря - не более часа, ежедневного копирования базы недостаточно. Отдельно определяют RTO - сколько времени допустимо потратить на восстановление работы. Оба показателя следует выбирать исходя из реальной стоимости простоя и доступных ресурсов.
5. Сохраняйте базу данных согласованно
Не стоит рассчитывать, что копирование файлов работающей базы даст корректный результат. Для базы используют штатные средства создания дампа, резервного снимка или другую поддерживаемую технологию, учитывающую её тип и режим работы.
Если сайт постоянно принимает заказы, комментарии или заявки, важно согласовать момент копирования файлов и базы. Иначе после восстановления записи в базе могут ссылаться на ещё не сохранённые изображения, а файлы - на отсутствующие записи. Для активных проектов применяют согласованные снимки или подходящую процедуру резервирования с учётом транзакций.
6. Не храните единственный архив рядом с сайтом
Архив в соседней папке того же сервера помогает при случайном удалении, но не защищает от отказа диска, потери доступа к серверу или массового удаления данных. Ещё одна проблема - доступность архива через веб-сервер: если резервные файлы лежат в публичной директории, они могут раскрыть конфигурацию и персональные данные.
Храните архивы вне публичного каталога сайта, ограничивайте права доступа, используйте шифрование при необходимости. Проверяйте, что резервное хранилище не доступно из обычного аккаунта приложения с правом удаления всех копий.
7. Автоматизируйте создание копий и проверку ошибок
Ручное резервирование почти всегда выполняют реже, чем планировали. Настройте расписание и отдельное уведомление о результате. Но сообщение «задача завершена» недостаточно: полезно проверять, что файл существует, его размер не равен нулю, архив читается, а список ожидаемых компонентов присутствует.
Отдельно контролируйте свободное место в хранилище и срок хранения. Если место закончилось, новая копия может не создаться, хотя старые архивы останутся на диске. Настройте уведомление об отсутствии свежей успешной копии, а не только об ошибке отдельного запуска.
8. Проведите пробное восстановление
Это главный тест. Создайте изолированную тестовую среду, восстановите туда файлы и базу, настройте временное окружение и проверьте ключевые страницы. Нельзя считать систему резервирования проверенной, пока хотя бы один раз не пройден весь путь от архива до работающего сайта.
Что проверить: открывается ли главная и внутренние страницы, отображаются ли изображения, работает ли вход в административную панель, сохранились ли записи и товары, корректно ли работают формы и фоновые задачи. Для магазина проверьте тестовый заказ без реального списания денег и отсутствие отправки уведомлений настоящим покупателям.
Запишите длительность восстановления и список действий. Если процесс занимает шесть часов, а допустимый простой - один час, значит, план восстановления нужно менять, даже если все файлы удалось вернуть.
9. Проверьте безопасность тестовой среды
При восстановлении копии реального сайта в тестовом окружении можно случайно отправить письма клиентам, запустить повторные интеграции или открыть персональные данные. Перед проверкой отключите отправку внешних уведомлений, платёжные операции и автоматические обмены. Ограничьте доступ к тестовой среде.
Если для теста не нужны реальные персональные данные, используйте обезличенную базу. После завершения проверки удалите временные копии и убедитесь, что тестовый сайт не доступен поисковым роботам и посторонним посетителям.
10. Составьте короткий план действий на случай сбоя
Даже хорошая копия мало поможет, если никто не знает, где она лежит и кто имеет доступ. Зафиксируйте адрес хранилища в защищённой документации, способ получения ключей, порядок остановки сайта, восстановления базы и файлов, проверки работоспособности и возвращения трафика.
План должен быть понятен не только автору настройки. Полезно указать ответственного, резервный контакт и критерии успешного восстановления. Пароли и секреты не вставляйте в открытые инструкции - храните их в предназначенном для этого защищённом месте.
Практический чек-лист для владельца сайта
- Понятно, какие файлы, базы и настройки входят в резервную копию.
- Есть несколько версий, включая состояние до последних обновлений.
- Хотя бы одна копия хранится независимо от основного сервера.
- Копирование выполняется автоматически с контролем результата.
- Срок хранения соответствует задачам бизнеса и требованиям к данным.
- Есть инструкция по восстановлению и доступ к необходимым ключам.
- Пробное восстановление выполнено, результат и время записаны.
- Тестовая среда не отправляет реальные письма и не обрабатывает платежи.
Как часто проверять восстановление
Проверяйте восстановление после серьёзных изменений архитектуры, переноса хостинга или обновления системы резервирования. Для небольшого сайта можно назначить регулярную проверку раз в несколько месяцев; для критичного проекта - чаще, в соответствии с требованиями к простою и потерям данных.
Главный вывод: надёжная резервная копия - это не архив с сегодняшней датой, а подтверждённая возможность вернуть сайт в работу за приемлемое время. Начните с одной полной пробной процедуры восстановления и устраните всё, что в ней не получилось с первого раза.