Резервная копия сайта должна содержать данные, необходимые для его восстановления, храниться в доступном и защищённом месте и проходить проверку. Сообщение «копирование завершено» подтверждает выполнение задания, но само по себе не доказывает, что из полученного архива можно запустить работающий проект.
Для сайта на CMS обычно нужны файлы и база данных. Дополнительно могут потребоваться настройки окружения, внешние хранилища и сведения об интеграциях. Точный состав зависит от архитектуры. В документации WordPress файлы и база прямо рассматриваются как две отдельные части резервного копирования. Руководство WordPress по бэкапам.
Сначала определите, что предстоит восстанавливать
Представьте, что основной сервер недоступен. У вас сохранился только бэкап и доступ к новому хостингу. Получится ли восстановить страницы, изображения, пользователей, заказы и работу форм?
Такой вопрос помогает обнаружить пробелы до аварии. Например, изображения могут храниться отдельно от сайта, заявки — передаваться в CRM, а часть настроек — находиться только в панели прежнего подрядчика.
Составьте небольшой перечень компонентов:
| Компонент | Что проверить |
|---|---|
| Файлы сайта | Код, шаблоны, расширения и пользовательские загрузки |
| База данных | Какая база относится к проекту и все ли нужные таблицы включены |
| Конфигурация | Какие параметры потребуются для запуска на другом окружении |
| Внешние файлы | Где находятся документы и изображения вне основного сервера |
| Интеграции | Как восстановить подключение к почте, CRM и другим сервисам |
| Порядок запуска | Кто выполнит восстановление и где находится инструкция |
Данные внешнего сервиса не становятся частью бэкапа сайта автоматически. Если информация хранится в CRM, для неё нужен отдельный предусмотренный сервисом процесс.
Для WordPress особенно важно учитывать пользовательские загрузки, темы, плагины и настройки. Простое скачивание папки сайта обычно не включает базу данных: она находится в отдельной системе хранения. Документация WordPress о копировании файлов.
Выберите допустимую потерю данных
Расписание удобнее определять через последствия сбоя. Сколько новых данных проект может позволить себе потерять: изменения за неделю, за день или только за короткий промежуток?
Для редко обновляемой страницы компании требования одни. Для магазина, который принимает заказы весь день, другие. Если копия создаётся ночью, при вечернем сбое между ней и текущим состоянием окажутся дневные заказы и изменения.
Рассмотрим условный пример. Магазин сделал бэкап в 02:00, а сбой произошёл в 17:00. Восстановление ночной версии само по себе не вернёт сведения, появившиеся за следующие пятнадцать часов. Их придётся получать из других подтверждённых источников, если такие источники есть.
Кроме объёма возможной потери, определите допустимое время простоя. Один проект может ждать специалиста несколько часов, другой требует заранее подготовленной процедуры быстрого запуска.
Эти параметры стоит обсудить с владельцем бизнеса до выбора инструмента. Иначе можно получить формально регулярное копирование, которое не соответствует реальной работе сайта.
Как выбрать способ резервного копирования
Инструменты хостинга
Панель хостинга может создавать копии файлов и баз данных по расписанию или по запросу. Это удобно, когда обслуживание проекта не требует отдельной инфраструктуры.
До подключения проверьте конкретные условия:
- что именно входит в копию;
- с какой периодичностью она создаётся;
- сколько версий хранится;
- можно ли скачать архив;
- доступны ли копии при проблемах с основным аккаунтом;
- как запускается восстановление;
- кто получает сообщение об ошибке.
Не переносите условия одного тарифа на другой. При выборе хостинга резервное копирование следует оценивать как отдельную функцию с понятными ограничениями.
Средства CMS
Плагин или встроенный модуль CMS может управлять расписанием и выгружать копии в отдельное хранилище. Перед использованием нужно проверить состав архива, совместимость с проектом и процедуру восстановления.
Не выбирайте инструмент только по наличию кнопки «Создать копию». Важнее понять, что произойдёт, если административная панель сайта перестанет открываться. Должен существовать рабочий способ получить архив и восстановить проект в таком состоянии.
Для WordPress резервную копию также рекомендуют создавать перед обновлениями, установкой компонентов и переносом сайта. Учебный материал WordPress.
Отдельный процесс администратора
Для сложного проекта копирование может выполнять отдельная система. Это позволяет учитывать несколько баз, внешние файловые хранилища и особенности приложения.
Такой вариант требует ответственного за настройку и контроль. Сам по себе отдельный сервер не гарантирует надёжность: ошибки расписания, доступа и состава данных остаются возможными.
Если инфраструктура растёт, полезно сначала определить требования к восстановлению, а затем выбирать сервер для задач бизнеса.
Где хранить копии
Архив в соседней папке основного сайта удобен для некоторых локальных операций, но не покрывает потерю всего сервера или доступа к аккаунту. Нужна копия, доступность которой не зависит целиком от того же места хранения и того же сценария отказа.
При выборе хранилища проверьте не только объём, но и порядок доступа. Кто сможет получить архив, если основной администратор недоступен? Где находятся средства расшифровки, если копии зашифрованы? Не заблокирует ли потеря одного аккаунта одновременно сайт и все его версии?
Не размещайте архивы в публично доступной папке сайта. Они могут содержать пользовательские данные и настройки подключения. Доступ к хранилищу нужно выдавать тем, кто действительно участвует в обслуживании.
Сохраняйте несколько версий. Проблему иногда обнаруживают спустя время, когда последняя копия уже содержит нежелательные изменения. Сам принцип хранения истории описан и в руководстве Timeweb, однако конкретную глубину хранения следует выбирать под свой проект. Материал Timeweb о резервных копиях.
Как проверить первый бэкап
Первую проверку проведите сразу после настройки, пока исправить процесс проще всего. Не ограничивайтесь просмотром размера файла.
- Проверьте завершение задания. В журнале не должно быть необъяснённых ошибок и пропущенных компонентов.
- Найдите все части копии. Убедитесь, что доступны файлы, база и необходимые дополнительные данные.
- Проверьте дату и принадлежность. Архив должен относиться к нужному сайту и согласованному состоянию.
- Подготовьте отдельное окружение. Пробное восстановление не должно перезаписывать рабочий сайт.
- Ограничьте доступ к тестовой версии. Одного запрета индексации недостаточно для защиты закрытых данных.
- Отключите реальные отправки и операции. Тестовая копия не должна рассылать письма клиентам, создавать заказы в CRM или выполнять рабочие платежи.
- Восстановите сайт и проверьте ключевые действия.
Работу с базой выполняют предусмотренным для неё способом. Наличие экспортированного файла ещё не означает, что база восстановлена: его нужно корректно импортировать в соответствующее окружение. Документация WordPress о копировании базы данных.
Для приёмки выберите несколько страниц и действий. Например, откройте главную, категорию, старую статью и материал с недавно загруженным изображением. Проверьте вход в административную панель, поиск и форму в безопасном тестовом режиме.
Запишите фактическое время восстановления и возникшие трудности. Это даст больше полезной информации, чем обещание «всё поднимем быстро».
Как избежать потери новых данных при откате
Восстановление старой копии может вернуть работоспособность, но одновременно убрать изменения, появившиеся после её создания. Поэтому перед откатом нужно определить, какие данные нельзя потерять.
Для интернет-магазина это могут быть новые заказы и статусы оплаты. Для редакционного сайта — публикации и комментарии. Для сервиса — пользовательские действия.
Перед восстановлением специалист должен оценить текущее состояние и, когда это возможно, сохранить нужные данные отдельно. Затем определить порядок их переноса. Простое объединение двух баз без понимания связей может создать новые ошибки.
Если причиной сбоя было подозрение на взлом, восстановление копии не заменяет поиск причины и устранение уязвимости. Иначе проблема может повториться.
Не используйте пробный откат на рабочем сайте как способ проверить, исправен ли архив. Для этого и нужно отдельное окружение.
Что контролировать после настройки
Назначьте человека, который будет реагировать на ошибки. Уведомление, отправляемое в почтовый ящик, который никто не читает, практически бесполезно.
Периодически проверяйте:
- дату последней успешной копии;
- наличие всех ожидаемых компонентов;
- ошибки выгрузки в хранилище;
- доступность старых версий;
- свободное место и правила удаления;
- результаты пробного восстановления.
Необычно маленький архив — повод разобраться, но и привычный размер не доказывает полноту. Проверка должна учитывать содержимое и возможность запуска сайта.
После смены хостинга, структуры хранения, CMS или ответственного специалиста пересмотрите инструкцию. В рабочем описании достаточно указать расположение копий, владельца процесса, расписание, способ получения доступа и порядок проверки. Пароли и ключи в такой документ включать не нужно.
Резервное копирование становится рабочей защитой, когда команда может найти нужную версию, восстановить её и подтвердить, что сайт выполняет свои основные задачи.