Проверка резервной копии ХостСМС: как убедиться, что сайт реально восстановится

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

Из чего состоит резервная копия сайта

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

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

Копия бывает полной и частичной. Полная включает всё и весит больше. Частичная (только изменения с прошлой копии) занимает меньше места, но для восстановления нужна цепочка. Знайте, какой вид копий у вас используется, и понимайте, что потребуется при восстановлении.

Кто делает копии и где они хранятся

Первый источник — хостинг. Многие хостинг-провайдеры создают копии автоматически, хранят их ограниченное время (от нескольких дней до месяца) и позволяют восстановить из панели управления. Второй источник — средства самой системы ХостСМС, которые умеют сохранять копию файлов и базы данных в архив. Третий — ручные копии, которые делает подрядчик перед обновлениями. Четвёртый — собственные копии на ваших носителях или в облачном хранилище.

Главное правило надёжности: копии должны храниться отдельно от самого сайта. Если архив лежит на том же сервере и сервер вышел из строя, вместе с сайтом вы потеряете и копии. Хорошая схема — минимум две копии в разных местах: на хостинге и во внешнем хранилище.

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

Что проверять: пять вопросов о резервных копиях

Первый вопрос — свежесть. Когда была создана последняя копия? Если копии делаются раз в неделю, при поломке вы потеряете до недели работы: новые заявки, правки, статьи. Для сайтов с постоянным потоком обращений копия базы данных должна создаваться чаще, лучше ежедневно.

Второй — полнота. Включены ли файлы и база данных? Загруженные изображения? Скрытые настройки? Откройте архив (или список его содержимого) и проверьте основные папки, размер базы данных и наличие ключевых файлов. Подозрительно маленький размер архива — тревожный сигнал.

Третий — читаемость. Открывается ли архив? Не повреждён ли? Распаковывается ли без ошибок? Иногда копии создаются, но битые. Проверяйте целостность на нескольких последних копиях.

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

Пятый — время восстановления. Сколько часов потребуется, чтобы вернуть сайт? Это зависит от размера и способа. Узнайте у исполнителя или проверьте сами на тестовой площадке.

Тестовое восстановление: единственная настоящая проверка

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

Что проверять после восстановления. Открывается ли главная страница и внутренние. Загружаются ли изображения. Работает ли вход в систему администрирования. Видны ли свежие статьи и последние изменения. Отправляются ли формы и приходят ли письма (на тестовой площадке лучше направить их на специальный адрес, чтобы не путать с реальными заявками). Работают ли подключённые модули и интеграции с оговоркой, что на тестовой площадке внешние сервисы лучше отключить.

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

Типичные проблемы, которые выявляет проверка

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

Каждая из этих проблем легко исправляется в спокойное время и катастрофична в аварийное. Именно поэтому проверка нужна заранее.

Как организовать надёжное резервное копирование

Минимальная разумная схема для сайта услуг: ежедневная копия базы данных, еженедельная полная копия файлов, хранение не менее тридцати дней, две точки хранения (хостинг и внешнее хранилище), автоматическое уведомление об успехе или ошибке, ежеквартальная тестовая проверка восстановления, письменная инструкция по восстановлению.

Перед любыми серьёзными изменениями (обновление системы, смена шаблона, перенос) делайте отдельную ручную копию и подписывайте её понятно: дата, причина. Не удаляйте её сразу после изменения: оставьте минимум на две недели, пока вы не убедитесь, что всё работает.

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

Как резервные копии связаны с заявками

Потеря сайта — это потеря обращений. Если ваш сайт приносит двадцать заявок в неделю, а его восстановление занимает четыре дня, вы теряете десяток обращений, а с ними часть выручки. Если вместе с сайтом пропали заявки, лежавшие в базе, вы теряете и контакты клиентов, которым ещё не позвонили. Поэтому важно, чтобы заявки сохранялись и вне сайта: отправлялись на почту и в систему учёта заявок (амоСРМ или Битрикс24). Тогда даже при проблеме с базой данных сайта история обращений у вас останется.

Отдельно позаботьтесь о настройках Яндекс.Метрики и Вебмастера, карточках в Яндекс Бизнесе и 2ГИС: данные для входа, коды счётчиков, привязка к домену. Это не часть резервной копии сайта, но без них восстановление не будет полным: после возврата сайта нужно убедиться, что счётчик на месте, цели работают, а адреса в карточках ведут правильно.

Как это связано с продвижением «3 в 1»

Подход «3 в 1» строится на трёх опорах: сайт (поиск и нейропоиск), карточка в Яндекс Бизнесе и карточка в 2ГИС. Если сайт недоступен несколько дней, страдают все три: поисковые системы замечают недоступность, карточки ведут на пустую страницу или ошибку, нейропоиск перестаёт использовать ваш сайт как источник. Восстановление после длительного простоя занимает недели. Поэтому надёжность сайта — часть продвижения, а не отдельная техническая задача.

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

Ежеквартальный чек-лист проверки

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

Типичные ошибки

Считать, что хостинг «обязательно всё сохраняет». Хранить копии только на одном сервере. Не проверять, что архивы читаются. Копировать только файлы или только базу. Короткий срок хранения. Отсутствие инструкции. Единственный ответственный. Нет страховки на время простоя. Забытые настройки Метрики и карточек. Проверка восстановления откладывается годами.

Сценарии аварий и что делать в каждом

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

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

Сколько копий хранить и как долго

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

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

Кому поручить проверку и как отчитываться

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

Вывод

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

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