Бэкап сайта: как не потерять всё за один вечер

Бэкап хостинга - ещё не бэкап

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

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

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

Копия хостинга не всегда полная. Часто в неё входят файлы и база, но не входят настройки почты, DNS-записи, конфиги веб-сервера, SSL-сертификаты, cron-задания. Восстановив «сайт», вы получите страницы без писем с формы, без нужных редиректов и с отвалившимся HTTPS. Формально бэкап сработал, фактически бизнес всё равно стоит.

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

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

Сайт для копирования - это не «папка с сайтом». Это минимум три разные сущности, и потерять любую из них достаточно, чтобы восстановление превратилось в пересборку.

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

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

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

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

Как часто и сколько хранить

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

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

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

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

Где хранить: три схемы

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

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

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

Проверка восстановлением

Это самый пропускаемый пункт и самый важный. Копия, которую ни разу не разворачивали, не является копией - это архив с неизвестным содержимым. Пока вы его не распаковали и не подняли сайт, вы не знаете ровным счётом ничего.

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

Лечится это одним действием: раз в квартал развернуть копию на тестовой площадке и посмотреть глазами. Открывается ли главная, на месте ли картинки, видны ли последние заказы и заявки, работает ли админка. Это полчаса работы, и это единственный способ узнать правду про свои бэкапы заранее, а не постфактум. Заодно вы измеряете время восстановления: одно дело знать, что копия есть, другое - знать, что сайт поднимается за час, а не за два дня поисков.

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

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

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

Хватит ли автоматических бэкапов хостинга?

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

Как часто делать резервные копии сайта?

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

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

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

Что входит в полный бэкап сайта?

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

Как проверить, что бэкап рабочий?

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

Сколько стоит нормально настроить бэкапы?

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

Короткий вывод

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

Проверим ваши бэкапы

APST делает сайты в Воронеже с 2005 года и ведёт эксплуатацию проектов клиентов - в том числе резервное копирование с выгрузкой наружу и контрольным восстановлением. Напишите, на чём стоит ваш сайт, и мы честно скажем, что у вас с копиями сейчас и что тут стоит поправить в первую очередь.

Обсудить проект