Резервное копирование сайта: что должно попадать в бэкап, как часто его делать и как проверить, что сайт правда можно восстановить

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

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

Что такое бэкап и чем он отличается от репозитория и снимка хостинга?

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

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

Часть сайта	Где обычно лежит	Чем копировать	Если её нет в копии
Код и шаблоны	Репозиторий и папка сайта на сервере	Репозиторий плюс архив папки сайта	Сайт придётся собирать заново из того, что найдётся у разработчика
База данных	Сервер базы: MySQL, PostgreSQL, SQLite	Дамп штатной утилитой базы, а не копия её файлов	Пропадают заказы, клиенты, статьи, настройки, пользователи
Загрузки	Папка uploads или объектное хранилище	Отдельная синхронизация, часто по изменённым файлам	Страницы открываются, но без фото товаров, договоров, вложений
Настройки сервера	Конфиги веб-сервера, переменные окружения, задания по расписанию	Архив конфигов или описание сервера в репозитории	Восстановление растягивается на дни: всё вспоминают руками
Секреты и доступы	Файл окружения, панели сервисов	Отдельное зашифрованное хранилище у владельца	Перестают работать оплата, почта, обмен с CRM и 1С
Домен, DNS, почта	У регистратора и почтового сервиса	Выгрузка DNS-записей, у почты — своя схема	Новый сервер есть, но адрес на него не ведёт, письма теряются

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

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

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

Если сайт обрабатывает персональные данные клиентов, копия — такой же носитель этих данных, как рабочая база. В ч. 2 ст. 19 152-ФЗ среди мер безопасности прямо названы учёт машинных носителей (п. 5) и восстановление данных, изменённых или уничтоженных из-за несанкционированного доступа (п. 7). Где физически можно держать такие копии, разобрано в статье о хранении данных по 152-ФЗ.

Тип сайта	База данных	Файлы и загрузки	Сколько хранить
Визитка, лендинг без кабинета	Раз в сутки или после правок	Раз в сутки или неделю	Пара недель ежедневных и несколько ежемесячных
Корпоративный сайт с блогом и заявками	Раз в сутки	Раз в сутки по изменённым	2–4 недели ежедневных, 3–6 ежемесячных
Интернет-магазин	Несколько раз в сутки или непрерывно	Раз в сутки по изменённым	Ежедневные за месяц, ежемесячные за полгода и дольше
Кабинет, CRM, сервис с оплатами	Непрерывно или каждый час	По мере загрузки	По требованиям бизнеса и закона, решается с юристом

Как часто делать копии и сколько их хранить?

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

Удобно мыслить двумя числами. Первое — допустимая потеря данных: если копия делается в 3:00, а сервер умер в 18:00, пропадает всё за 15 часов, включая заказы и заявки. Второе — допустимое время простоя: за сколько часов сайт должен снова работать. Оба числа записывают письменно, в нефункциональных требованиях к проекту, потому что от них зависят и схема, и цена поддержки.

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

Где хранить копии, чтобы они пережили сбой?

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

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

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

Почему копия базы данных может оказаться битой?

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

У популярных баз есть штатные инструменты, которые снимают согласованную копию на ходу. Документация PostgreSQL прямо пишет, что pg_dump делает согласованную выгрузку, даже если базой в это время пользуются, и не блокирует других пользователей. У MySQL такой режим даёт mysqldump с параметром --single-transaction, но только для таблиц InnoDB: таблицы MyISAM и MEMORY во время выгрузки всё равно могут меняться. На старых сайтах с таблицами MyISAM это стоит проверить отдельно.

Вторая типичная ловушка — рассинхрон файлов и базы. Дамп сняли в 3:00, а папку загрузок скопировали в 5:00: в базе нет товаров, фото которых уже лежат в архиве, или наоборот. Для небольших сайтов это мелочь, для кабинета с документами клиентов — потерянные вложения. Решение — делать обе части в одном задании и помечать их одной датой.

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

Как проверить, что из бэкапа правда можно восстановить сайт?

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

1. Берут не вчерашнюю копию, а случайную из цепочки, например двухнедельной давности: так проверяется и глубина хранения.
2. Поднимают чистый сервер или контейнер, не трогая рабочий сайт. Тестовый адрес закрывают паролем и от индексации.
3. Восстанавливают код, базу, загрузки и настройки строго по письменной инструкции. Если по ходу пришлось что-то вспоминать — это пробел, его вносят в инструкцию.
4. Проходят сценарии: открываются ли главные страницы и карточки с фото, работает ли вход в кабинет, видны ли последние заказы и заявки, приходит ли письмо с формы. Оплату на тесте проверяют только в тестовом режиме платёжной системы.
5. Записывают дату, номер копии, время восстановления и найденные проблемы. Если вышло дольше допустимого простоя, схему меняют.
6. Тестовый экземпляр удаляют: в нём настоящие данные клиентов.

Отдельно проверяют, что сами копии продолжают делаться. Задание по расписанию может тихо перестать работать после обновления сервера или заполнения диска. Уведомление «копия не создана» или «копия подозрительно маленькая» — часть мониторинга; что ещё стоит отслеживать, есть в статье о мониторинге сайта после запуска.

Что спросить у подрядчика или хостинга?

Попросите ответить письменно на восемь вопросов. Если на половину из них ответ «ну, хостинг что-то делает», резервного копирования у сайта, скорее всего, нет, есть только надежда на чужие снимки.

1. Что именно попадает в копию: код, база, загрузки, конфиги, DNS? Чего в ней нет?
2. Как часто копируется база и как часто файлы? Сколько данных мы потеряем в худшем случае?
3. Сколько копий хранится и за какой период: ежедневные, еженедельные, ежемесячные?
4. Где лежат копии, на кого оформлено хранилище, может ли сервер сайта их удалить?
5. Шифруются ли копии и у кого ключ?
6. Когда последний раз восстанавливали сайт из копии и сколько это заняло?
7. Кто узнаёт, если ночная копия не создалась, и как быстро?
8. Есть ли письменная инструкция восстановления, по которой справится другой разработчик?

Кто отвечает за копии по договору поддержки?

Тот, кто прямо назван в договоре или приложении к нему. Гарантия на разработку закрывает ошибки в работе исполнителя, но не сбои хостинга и сторонних сервисов, поэтому резервное копирование нужно прописывать отдельно — в договоре поддержки.

В типовом договоре студии гарантия — 30 календарных дней с даты подписания акта: исполнитель бесплатно исправляет ошибки, возникшие по его вине. На изменения, внесённые заказчиком или третьими лицами, и на сбои сторонних сервисов она не распространяется. Данные, накопленные при эксплуатации продукта заказчика, остаются за заказчиком. Сразу после запуска действует бесплатная поддержка на мелкие правки: 7 дней для лендинга и бота, 14 дней для магазина и веб-приложения, 1 месяц для корпоративного сайта. Дальше — поддержка по абонентке от 7 900 ₽ в месяц, и именно в её состав имеет смысл записать бэкапы: что копируется, как часто, где хранится, сколько живёт и как часто проверяется восстановление. Как сформулировать такие пункты, разобрано в статье о договоре на поддержку сайта.

Как это устроено в наших проектах?

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

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

Когда сложная схема не нужна и какие ошибки встречаются?

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

Ошибки, которые мы чаще всего видим у сайтов, приходящих на поддержку:

• Копии лежат на том же диске. Папка backup рядом с сайтом исчезает вместе с сервером и легко шифруется вместе с ним.
• Копируется только база. После восстановления сайт без фото и документов, а загрузки вернуть неоткуда.
• Хранится одна последняя копия. Каждую ночь она перезаписывается, и если вчера в базу попал мусор, сегодня мусор уже в копии.
• Хранилище оформлено на бывшего разработчика. Копии формально есть, но доступа к ним нет. Это решается так же, как с доменом и хостингом: всё оформляют на компанию.
• Восстановление ни разу не проверяли. Выясняется, что архив повреждён, пароль от него утерян или не хватает версии базы, чтобы его открыть.
• Тестовую копию забыли удалить. Старый экземпляр с данными клиентов висит на открытом адресе и попадает в поиск.

Чек-лист резервного копирования сайта

Пройдите его вместе с тем, кто поддерживает сайт. Каждый пункт должен иметь ответ «да» и место, где это записано.

• Копируются код, база, загрузки, конфигурация сервера; есть перечень секретов и DNS-записей.
• Дамп базы делается штатной утилитой, файлы и база — в одном задании с одной датой.
• Частота согласована с допустимой потерей данных, а время восстановления — с допустимым простоем.
• Хранятся ежедневные, еженедельные и ежемесячные копии, а не одна последняя.
• Минимум одна копия у другого поставщика, хранилище оформлено на компанию, сервер сайта не может удалять копии.
• Копии зашифрованы, ключ хранится отдельно от сервера.
• Есть уведомление, если копия не создалась или её размер резко изменился.
• Раз в квартал — пробное восстановление на отдельном сервере с записью времени и проблем.
• Есть письменная инструкция восстановления, понятная другому разработчику.
• В договоре поддержки названо, кто за всё это отвечает.

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

Хостинг уже делает бэкапы — нужно ли что-то ещё?

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

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

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

Достаточно ли копировать только базу данных?

Нет. Без папки с загрузками сайт поднимется без фото, документов и вложений, а без настроек сервера и списка секретов восстановление затянется на дни. Копия должна включать код, базу, загрузки, конфигурацию и перечень доступов.

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

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

Кому принадлежат данные из резервных копий?

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

Услуги и кейсы по теме: заказная разработка · кейс «Довод» · цены и сроки