Как выбрать резервную копию сайта и проверить восстановление

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

Что считать полной копией сайта

У CMS две части: файлы и база данных. В WordPress это, например, ядро, темы, плагины, загруженные изображения и отдельная база с публикациями, настройками и пользователями. Скопировать каталог сайта недостаточно: база обычно хранится в отдельной СУБД. Экспорт базы без файлов тоже не вернёт тему, расширения и медиа. Для восстановления эти части должны быть сохранены как один комплект и относиться примерно к одному моменту времени.

Я начинаю не с выбора инструмента, а с инвентаризации. Где лежат файлы? Где база? Есть ли отдельный каталог загрузок, объектное хранилище, внешняя папка с конфигурацией? Какие данные создают плагины? Ответы зависят от конкретной установки. Например, файлы, вынесенные в облачное хранилище, могут не попасть в обычный архив сайта автоматически: в документации 1С-Битрикс для этого предусмотрен отдельный выбор облачных хранилищ при архивации. Проверяйте состав архива, а не его красивое имя.

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

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

• Файлы ядра, тем и плагинов
• Загрузки и пользовательские файлы
• Экспорт базы данных
• Внешние хранилища и конфигурация

Полная и инкрементальная схемы: в чём разница

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

Повреждение одного элемента цепочки может помешать восстановить зависимые от него более поздние состояния. Это реальный риск, но не повод объявлять любой инкрементальный бэкап рулеткой. Хорошее ПО проверяет репозиторий, хранит метаданные и может переживать некоторые прерывания. Нельзя заранее обещать ни «потеряется всё», ни «всё само починится». Нужно читать документацию выбранного инструмента, следить за завершением заданий и периодически проверять копии.

У инкрементальной схемы есть важное условие: понятно, от какой базовой копии строятся изменения и какие файлы нужны для выбранной точки восстановления. Ротация должна сохранять эти зависимости. Если оператор удаляет старые архивы вручную, не понимая правил программы, он может разрушить нужный набор. Удаление по сроку хранения настраивают штатными средствами, а перед очисткой проверяют, какие точки останутся доступными. Экономия диска полезна только пока не съедает возможность вернуть нужное состояние.

Я не выбираю метод по объёму сайта в гигабайтах. Порог «50 ГБ» сам по себе ничего не решает: важны скорость изменения данных, окно резервирования, пропускная способность, стоимость хранилища, требования к сроку восстановления и потере последних изменений. Для небольшой CMS регулярная полная копия может оказаться самым простым решением. Для растущего проекта подходит инкрементальная или комбинированная схема — если её умеют обслуживать и тестировать. Универсального календаря для всех сайтов нет; отдельно разбираю мифы о бэкапе сайта.

• Полная копия: проще отдельное восстановление
• Инкремент: меньше данных в очередном задании
• Цепочку и правила хранения проверяют в документации

Скрытые файлы, исключения и безопасное хранение

Опция «копировать только public_html» может пропустить нужные данные, если конкретный сайт хранит их в другом месте. Но включить все скрытые каталоги подряд — не решение. В .htaccess могут быть правила веб-сервера, .env иногда содержит настройки и секреты, а .git — историю разработки. У разных CMS и хостингов состав отличается. Сначала выясните роль каждого пути, затем включите необходимые файлы в задание и защитите копии от доступа из интернета.

Миф про универсальный шаблон .* особенно коварен. У разных программ собственный синтаксис включений и исключений; одна маска может означать не то, что ожидает администратор, или конфликтовать с правилами исключения. Я не советую вставлять её в неизвестный скрипт как заклинание. Проверьте документацию конкретного средства, сделайте пробный запуск и посмотрите список реально добавленных файлов. Скрытый файл, который «должен был попасть», и файл, который действительно находится в архиве, — две разные вещи.

Копия не должна лежать по публичному адресу сайта. Если архив доступен через браузер, он может раскрыть базу, конфигурацию или пользовательские данные. По возможности храните резервный набор отдельно от веб-каталога и самого сервера; выдавайте к хранилищу только необходимые права. Иначе ошибка или взлом основной системы может задеть и резерв. Даже корректная копия на том же диске не спасает от отказа этого диска. Это не сложная стратегия, это базовая география данных.

Полезно разделить доступ к производственному сайту и хранилищу копий, а также следить за шифрованием и сроком хранения. Секреты для восстановления держите отдельно и ограничивайте круг тех, кто может удалять архивы. Если используете облачную или объектную площадку, проверьте, что туда реально отправляются все нужные части, что копия завершила загрузку и что её можно прочитать. Строка «успех» в панели — сигнал для проверки, но не замена проверке содержимого.

• Сверить список путей с устройством CMS
• Проверить правила include и exclude
• Хранить копии вне публичного каталога
• Ограничить доступ и проверить загрузку

Как проверить восстановление, а не только отчёт

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

Затем восстанавливаю копию в отдельную тестовую среду. Проверяю, что файлы и база присутствуют, сайт запускается, открываются ключевые страницы, работают вход в панель и формы, отображаются последние загрузки. Для магазина или кабинета добавляются собственные критичные сценарии. Тест не должен менять рабочий сайт. После проверки среду изолируют или удаляют, а результат записывают: дата копии, длительность восстановления, найденные пропуски и необходимые действия.

Минимально полезная проверка — не просто увидеть файл архива, а прочитать данные и выполнить восстановление. Документация Restic, например, описывает проверку репозитория и восстановление выбранного снимка в целевой каталог. У других средств будут свои команды и ограничения; не переносите ключи одной программы в другую. Если полного восстановления пока нет в регламенте, начните с тестовой копии и постепенно доведите сценарий до запуска приложения.

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

• Выбрать дату и точку восстановления
• Развернуть копию отдельно от production
• Проверить файлы, базу и функции сайта
• Записать результат и устранить пропуски

Как выбрать расписание и удержание копий

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

Затем оцените, как часто меняются файлы и база. У контентного сайта загрузки могут появляться нерегулярно, а база обновляться при каждом комментарии или заказе. Если файлы и база копируются с большим разрывом, после восстановления они могут описывать разные состояния. Поэтому связанный набор нужно делать согласованно — возможностями CMS, базы или программы резервирования. Для WordPress официальное руководство отдельно рекомендует копировать базу и файлы и делать копию перед обновлением.

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

Моя короткая памятка такова: включить файлы и базу, выяснить исключения, отправлять копию отдельно от сайта, следить за результатами задания и проверять восстановление. Это звучит буднично. Так и должно быть: резервирование — рабочая процедура, а не магический амулет в панели управления. Если программа или площадка меняется, процедуру нужно перепроверить. Если меняется сайт, повторно сверить состав. Тогда у администратора есть конкретный план, а не надежда на удачу. Для WordPress отдельно описал порядок отката после взлома.

• Расписание — по допустимой потере данных
• Проверка — по цене простоя и риску
• Хранение — с учётом срока обнаружения ошибки
• Повторная проверка после изменений

Частые вопросы