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

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

Актуально на август 2026 года. По опыту Honey Hunters Digital, сайты теряют данные не из-за экзотических аварий, а из-за трёх обычных вещей: неудачное обновление CMS или плагина, взлом с подменой файлов и ошибка человека, который «почистил лишнее» в админке. Во всех трёх случаях спасает не хостинг, а собственная копия, до которой владелец может дотянуться сам. Ниже - как выстроить эту систему: частота, состав копии, места хранения, срок жизни архивов и процедура проверки.

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

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

• Интернет-магазин, сайт с заказами и оплатами - база данных не реже раза в сутки, а лучше несколько раз в день; файлы - ежедневно. Потеря даже половины дня здесь означает потерянные заказы, которых нет ни в одной системе.
• Корпоративный сайт с блогом и формами - ежедневная копия базы и еженедельная копия файлов. Файлы меняются редко, база - каждый раз, когда приходит заявка или выходит статья.
• Сайт-визитка без обновлений - раз в неделю достаточно, плюс обязательная копия непосредственно перед любыми работами.
• Портал, сервис, личные кабинеты - непрерывное резервирование базы (бинарные логи, репликация) плюс суточные снимки. Здесь допустимая потеря измеряется минутами.

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

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

Полная копия сайта состоит из двух частей, и обе одинаково обязательны: файлы и база данных. Копия только файлов бесполезна для сайта на CMS - без базы вы получите набор скриптов без единой страницы, товара и заявки. Копия только базы бесполезна без файлов - тексты будут, а картинок, шаблонов и настроек нет.

1. Файлы сайта - весь каталог, включая ядро CMS, шаблоны, модули, загруженные изображения и документы.
2. База данных - полный дамп в формате SQL, снятый в той же кодировке, в которой работает сайт.
3. Конфигурационные файлы - настройки подключения к базе, .htaccess или конфиг nginx, файлы окружения. Их часто исключают из архива «как секретные» и потом долго собирают вручную.
4. Почта на домене, если она лежит на том же хостинге. Восстанавливать сайт и обнаружить пустые ящики с перепиской по заказам - отдельное удовольствие.
5. Задания cron и системные настройки - расписания обменов с 1С, выгрузок, автоматических рассылок. Сайт без них поднимется, но перестанет обмениваться данными с учётной системой.
6. SSL-сертификат и настройки DNS - хотя бы в виде текстовой памятки: какие записи куда ведут.

Полезная привычка - хранить рядом с архивом короткий текстовый файл с описанием: дата, версия CMS, версия PHP, какие модули стоят, где лежит конфиг. При восстановлении через полгода эта записка экономит несколько часов.

Куда хранить копии: правило 3-2-1

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

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

• Панель хостинга - удобно и быстро для отката на вчера. Годится как первая линия, но не как единственная.
• Облачное хранилище (Яндекс Диск, S3-совместимые хранилища, VK Cloud и аналоги) - основной внешний адрес для архивов. Стоит недорого: хранение десятков гигабайт на рынке начинается от нескольких сотен рублей в месяц.
• Отдельный сервер или NAS - вариант для тех, у кого несколько проектов, и хочется одно место со своими правилами.
• Локальный диск у владельца бизнеса - самая недооценённая копия. Одна ежемесячная выгрузка на внешний диск, который лежит не в офисе, закрывает сценарии, до которых облако не дотягивается.

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

Сколько хранить архивы и как настроить ротацию

Разумный минимум - месяц истории. Схема, которая закрывает почти все случаи: 7 ежедневных копий, 4 еженедельных и 6-12 ежемесячных. Ежедневные спасают от вчерашней ошибки, еженедельные - от проблемы, замеченной с задержкой, ежемесячные - от заражения или порчи данных, которые тихо жили в сайте несколько недель.

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

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

Как проверить, что резервная копия рабочая

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

Процедура тестового восстановления, которую стоит проводить раз в квартал:

1. Скачайте свежий архив из внешнего хранилища - именно скачайте, а не разворачивайте на месте, так вы заодно проверите, что файл целиком выгружается.
2. Разверните копию на тестовом домене или поддомене, закрытом от индексации паролем.
3. Импортируйте базу и проверьте, что импорт прошёл без ошибок и обрывов.
4. Откройте главную, каталог, карточку товара или услуги, страницу контактов - визуально сравните с боевым сайтом.
5. Проверьте динамику: работает ли поиск, отправляется ли форма, видны ли последние заказы и заявки в админке.
6. Сверьте количество записей в ключевых таблицах: товары, заказы, пользователи, статьи. Расхождение с боевой базой - повод разбираться.
7. Зафиксируйте время: сколько заняло восстановление от скачивания до рабочего сайта. Это ваш реальный срок простоя в случае аварии.
8. Запишите результат в журнал: дата проверки, что развернули, что не сработало. Через год этот журнал скажет о надёжности системы больше, чем любые настройки.

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

Пять ошибок, из-за которых бэкап не спасает

Большинство историй «у нас были копии, но они не помогли» сводится к одному из пяти сценариев. Все они лечатся заранее и почти без затрат.

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

Кто должен этим заниматься

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

Именно поэтому бэкапы почти всегда живут внутри договора на поддержку и сопровождение сайта, а не покупаются отдельной услугой. В нашем базовом тарифе (от 15 000 ₽ в месяц - 4 часа работ и «Красная кнопка» на срочные обращения) резервное копирование и контроль его работоспособности входят в эти часы: настройка занимает часть первого месяца, дальше уходит немного времени на проверки. Если сайт большой и восстановление нужно быстрое, схему считаем отдельно - объём хранилища и частота копий сильно зависят от размера базы.

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

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

Достаточно ли резервных копий, которые делает хостинг?
Как единственная защита - нет. Они хранятся обычно 7-14 дней, лежат на инфраструктуре того же хостера и пропадают вместе с доступом к аккаунту при блокировке или неоплате. Копии хостинга удобны для быстрого отката на вчера, но к ним нужна вторая, внешняя копия.

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

Сколько места занимает резервная копия сайта?
Сайт-визитка - от 100 до 500 мегабайт, корпоративный сайт с блогом - 1-5 гигабайт, интернет-магазин с фотографиями товаров - от 5 до 50 гигабайт и больше. Основной объём почти всегда дают загруженные изображения, а не код и не база.

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

Сколько хранить резервные копии сайта?
Минимум месяц истории. Рабочая схема - 7 ежедневных копий, 4 еженедельных и 6-12 ежемесячных. Ежемесячные архивы особенно важны при взломе: вредоносный код часто находят через несколько недель, когда все свежие копии уже заражены.