Резервное копирование сайта: как не потерять бизнес за одну ночь

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

Из чего вообще состоит сайт

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

Файлы. Всё, что лежит на сервере: движок CMS, шаблоны оформления, стили, скрипты, загруженные изображения и документы, настроечные файлы. Это то, что определяет, как сайт выглядит и работает.

База данных. Тексты страниц, каталог товаров, заказы, пользователи, настройки, статьи блога, заявки. Это содержимое.

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

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

Что реально ломается: сценарии из практики

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

Неудачное обновление. Обновили модуль или саму систему управления, что-то не сошлось по версиям, сайт перестал открываться. Самый частый сценарий вообще. Откат из копии решает вопрос за десять минут, отсутствие копии превращает это в многочасовые раскопки.

Ошибка при правке. Сотрудник или подрядчик редактировал шаблон, случайно удалил нужный кусок кода или не тот раздел каталога. Правки в CMS часто необратимы.

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

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

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

Уход подрядчика. Разработчик пропал, доступы у него, что-то сломалось. Если у вас есть свежая копия, сайт можно поднять у другого специалиста за день. Если нет — начинается неприятная история.

Массовое редактирование через выгрузку. Загрузили обновлённый прайс с ошибкой в структуре — и каталог из трёх тысяч позиций превратился в кашу. Очень частая история в интернет-магазинах.

Обратите внимание: большинство сценариев не связаны со злым умыслом. Это обычные рабочие ситуации, и именно поэтому копии нужны всем, а не только тем, кто чего-то опасается.

Правило трёх копий

В профессиональной среде принято ориентироваться на простое правило, которое хорошо работает и для сайтов.

Три копии данных. Рабочая версия плюс минимум две резервные.

Два разных типа хранения. Не всё в одном месте: например, копия на сервере хостинга и копия в облачном хранилище.

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

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

Как часто копировать

Частота определяется одним вопросом: сколько данных вы готовы потерять?

Если сайт — визитка, которая меняется два раза в год, ежемесячной копии достаточно. Потеря месяца изменений означает, что нужно заново внести пару правок.

Если это корпоративный сайт с блогом и заявками, копия раз в сутки — разумный минимум. Заявки за день, потерянные из-за сбоя, — это упущенные клиенты.

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

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

Сколько хранить

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

Разумная схема глубины хранения:

Ежедневные копии за последнюю неделю или две. Позволяют откатиться к любому дню недавнего прошлого.

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

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

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

Где хранить копии

Средства хостинга. Большинство российских хостинг-провайдеров делают резервные копии автоматически и позволяют восстановиться из панели управления в пару кликов. Это удобно и должно быть первым уровнем защиты.

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

Вывод: пользоваться нужно, полагаться только на это — нельзя.

Облачные хранилища. Копии автоматически выгружаются в облако. Из российских решений подходят Яндекс 360 и Яндекс Диск, облачные хранилища Selectel, VK Cloud, Timeweb Cloud, Рег.ру. Плюс очевиден: данные лежат физически отдельно от сайта, объём легко наращивается, доступ есть из любой точки.

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

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

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

Как настроить автоматическое копирование

Есть три подхода, и выбор зависит от того, есть ли у вас технический специалист.

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

Через средства CMS. У многих систем управления есть встроенные механизмы или модули резервного копирования. Удобно тем, что копия делается «изнутри» и корректно охватывает и файлы, и базу. Ограничение: если сайт лежит из-за проблем на сервере, модуль тоже не работает — поэтому этот способ не должен быть единственным.

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

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

Копия, которую не проверяли, копией не является

Это главный тезис всей темы, и его игнорируют чаще всего.

Ситуации, с которыми регулярно сталкиваются при попытке восстановления:

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

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

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

Архив повреждён и не распаковывается.

Копия делалась, но задание перестало выполняться после смены пароля или переноса сайта, и никто этого не заметил.

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

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

Как выглядит восстановление

Полезно заранее понимать последовательность действий, чтобы в критический момент не терять время.

Сначала — определить, что именно произошло и когда. От этого зависит, какую копию брать. Если сайт заражён, нужна копия до заражения, а не вчерашняя.

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

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

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

И в завершение — понять причину. Если сайт восстановили, но не устранили дыру, через которую его сломали, всё повторится через неделю.

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

Что ещё стоит сохранить помимо самого сайта

Сайт — это не только файлы и база. Восстановление часто буксует на смежных вещах.

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

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

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

Описание конфигурации. Версии программного обеспечения, установленные модули, особенности настройки сервера. Короткий документ, который экономит специалисту часы при восстановлении на новой площадке.

Частые заблуждения

«Хостинг всё копирует, мне не нужно». Копирует, но недолго и без гарантий. И вместе с аккаунтом теряется.

«У нас маленький сайт, восстановим за день». Восстановить с нуля сайт даже на десять страниц — это заново собрать структуру, вёрстку, тексты, изображения и настройки. День — это очень оптимистично, обычно выходит неделя и оплата работы разработчика.

«У нас всё в облаке, значит, надёжно». Облако защищает от отказа оборудования, но не от ошибочного удаления и не от заражения. Ошибку оператора облако послушно продублирует во всех репликах.

«Копия делается, я видел настройку». Настройка была включена. Работает ли она сегодня — другой вопрос. Проверяйте.

«Мы делаем копию раз в год». Это ритуал, а не защита.

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

Простой план для тех, у кого сейчас ничего нет

Если резервного копирования нет вообще, начните с малого — этого хватит, чтобы закрыть основные риски.

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

Включите автоматическое копирование в панели хостинга и посмотрите, какая глубина хранения доступна.

Настройте выгрузку копий во внешнее хранилище — либо средствами хостинга, либо силами специалиста.

Заведите правило: копия перед любым обновлением или массовой правкой.

Раз в квартал проверяйте восстановление на тестовой площадке.

Запишите все доступы в одно место и убедитесь, что они есть не у одного человека.

Это займёт несколько часов один раз и снимет большинство сценариев, в которых бизнес теряет сайт.

Итог

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

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

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