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

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

Что должно получиться

У вас есть комплект, из которого можно собрать рабочий сайт на отдельной площадке. Вы знаете, к какому состоянию он относится, что в него входит и кто сможет им воспользоваться. Файл с названием «backup» без проверки состава ещё не даёт такой уверенности: внутри может оказаться только база данных или часть каталога загрузок.

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

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

Из чего это складывается

Различие файлов и базы подробно показано в руководстве WordPress по резервным копиям. Это полезный пример устройства CMS: скачивание папки сайта обычно не заменяет отдельное сохранение базы. Для своего проекта уточните, какие хранилища он использует, прежде чем выбирать способ копирования.

Как это сделать по шагам

1. Опишите состав проекта. Укажите основной сайт, поддомены, базу данных, загрузки, внешние хранилища и службы. Отметьте, где находятся настройки. Так вы сможете сверить фактический архив со списком, а не полагаться на название операции в панели.
2. Определите допустимую потерю изменений. Решите, какие новые материалы, обращения или заказы пришлось бы восстанавливать вручную. На этой основе выберите расписание и сохранение предыдущих состояний. Универсальный интервал для всех сайтов здесь не подходит.
3. Выберите штатный способ создания комплекта. Это может быть средство хостинга, CMS или отдельно настроенная процедура. Уточните, что именно она сохраняет и каким способом результат разворачивается обратно. Копирование и восстановление должны быть совместимы.
4. Согласуйте момент фиксации данных. Для активно меняющегося сайта важно получить согласованные файлы и базу. Если механизм не обеспечивает это сам, договоритесь со специалистом о безопасном порядке работ и учёте новых изменений на время копирования.
5. Создайте копию и дождитесь завершения. Проверьте итог операции, наличие всех частей и читаемость архива. Сохраните сведения об ошибках, если они есть. Не объявляйте копию готовой по одному появившемуся имени файла.
6. Поместите комплект в независимое хранилище. Ограничьте доступ и сохраните сведения, необходимые для расшифровки и восстановления. Не оставляйте единственный экземпляр там же, где может быть потерян рабочий сайт.
7. Проведите пробное восстановление. Разверните копию отдельно, исключив отправку настоящих писем и другие внешние действия. Проверьте содержимое и функции, затем зафиксируйте результат. Неудачная проба — повод исправить процедуру до следующего обновления сайта.

Автоматическая копия и ручной комплект

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

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

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

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

Что написать в паспорте копии

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

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

Доступы храните в защищённом месте, а в паспорте укажите, кто имеет право ими воспользоваться. Конфигурация может содержать пароли и другие чувствительные сведения. Например, документация InstantCMS по безопасности отдельно обращает внимание на конфигурационные файлы. Архив с такими данными нельзя публиковать как обычное вложение.

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

Где хранить и как не потерять предыдущие состояния

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

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

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

Частые ошибки

• Сохраняют только файлы, забывая базу данных, или только базу без загрузок и собственного шаблона.
• Выгружают не ту базу, потому что в кабинете размещено несколько проектов. Назначение подключения нужно сверять с настройками сайта.
• Пропускают скрытые файлы и конфигурацию вне основной папки. Отдельно проверьте такие части в ведомости проекта.
• Считают синхронизацию полноценной историей. Она может повторить случайное удаление, если не предусмотрено сохранение предыдущих состояний.
• Хранят архив по открытой ссылке или передают комплект с паролями вместе с обычными материалами для подрядчиков.
• Никогда не проверяют восстановление. Наличие архива и успешное разворачивание приложения — разные проверки.

Как проверить

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

Если нужна настройка процедуры, опишите состав сайта и требования к восстановлению в разделе «Разработка» на бирже ITSNEW. Перед работой полезно разобраться в администрировании сервера и связи домена с хостингом через DNS.

Вопросы и ответы

Копия у хостера заменяет собственный архив?

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

Почему папки сайта недостаточно для CMS?

База данных обычно работает отдельно от каталога файлов. В ней могут храниться записи, связи, пользователи и настройки. Если вы просто скачали папку приложения, убедитесь, что выгрузка нужной базы тоже сохранена.

Как часто нужно делать резервную копию?

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

Можно ли проверить архив без восстановления?

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

Что делать, если архив создаётся с ошибкой?

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

Нужны ли копии, если исходники хранятся в системе версий?

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