Бэкап сайта: 10 проверок своей резервной копии

Копия, которую никто не восстанавливал, — это не копия, а предположение. Проверяется оно за вечер и в двух местах: в списке исключений вашего хостинга и на тестовом поддомене. У Рег.ру в резервную копию не попадают файлы больше 300 Мб, cron-задания и настройки панели. У Sprinthost — любые архивы .zip, .rar и .tar.gz, включая тот, который вы сами положили на сервер «на всякий случай». У SpaceWeb копирование переводится на раз в неделю, если на аккаунте больше 20 000 файлов на каждый гигабайт тарифа. Ниже — десять проверок, каждая из которых делается из панели хостинга и ничего не стоит.

01Что стоит в выдаче по запросу «бэкап сайта» и чего там нет

Позиции я не снял: Яндекс отдаёт SmartCaptcha на автоматический запрос, Google — JS-заглушку с перебросом на enablejs, Bing по русскому запросу не показал ни одной органической ссылки. Поэтому вместо порядка выдачи я собрал пул из 18 страниц, которые по этому запросу и его вариантам встречаются чаще всего, и разобрал 17 из них — восемнадцатая, справка RU-CENTER, отдаёт антибот-заглушку в 13 602 байта вместо текста. Порядок в моём списке — не порядок топа, и я это специально оговариваю.

В пуле семь справок самих хостингов (Timeweb, Beget, Рег.ру ×2, SpaceWeb ×2, Sprinthost), четыре редакционные статьи хостеров и каталогов, два деловых медиа, Хабр 2012 года, блог SEO-сервиса от 22 января 2019 года и лендинг вендора программы для бэкапов. Вот что в них нашлось, и это главная таблица статьи.

Ноль в третьей строке — это и есть главная дыра. Весь пул учит делать копию и откатываться из неё, и ни одна страница не учит убедиться, что копия годная, до того как она понадобилась. Проверка там есть только задним числом, когда рабочий сайт уже перезаписан: Timeweb советует «проверьте работоспособность сайта» после восстановления, Serpstat — сохранить старую папку «на случай, если файлы резервной копии не сработают». Единственная страница, которая называет проверку обязательным пунктом процесса, — материал Biz360 с разделом «Как проверяем целостность копирования и состояние бэкапов», и метода за этим заголовком нет.

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

02Проверка 1. Два числа у своего хостинга: как часто и сколько хранится

Это пять минут и две цифры, которые надо знать наизусть. Я свёл их по справкам шести провайдеров на 29 октября 2026 года.

Что в этой таблице важно увидеть. Во-первых, разброс по глубине — не в проценты, а в разы: у Timeweb и Рег.ру месяц, у SpaceWeb неделя. Во-вторых, Beget считает не днями, а слотами: «на один аккаунт мы выделяем 8–12 свободных слотов. То есть если автоматические бэкапы создаются каждые 4 дня, то самая старая версия будет храниться 36–48 дней». В-третьих, у Рег.ру копия появляется не сразу: «бэкапы создаются с 00.00 (МСК) и доступны для скачивания после 14.00 следующего дня», — значит на утро аварии свежей копии за эту ночь у вас ещё нет. И последнее: у Hostiman частоты и глубины в базе знаний я не нашёл вовсе, там есть только срок после неоплаты — копия аккаунта хранится ещё 14 дней после начала просрочки. Отсутствие числа в справке — это тоже ответ, и он означает, что планировать по нему нельзя.

03Проверка 2. Список исключений — там, где копия перестаёт быть копией

Самая дорогая строчка в справке хостинга — не срок хранения, а перечень того, что он не копирует. Привожу дословно.

Самая обидная ловушка — у Sprinthost: собственный архив .tar.gz, который владелец оставил на хостинге, в копию хостинга не попадёт, и каталог ~/backups исключён отдельной строкой. Человек уверен, что у него две копии, а у него ноль. Вторая по значимости — лимит 300 Мб у Рег.ру: в типовом интернет-магазине это ровно тот один файл с каталогом или видео, которого потом и не хватит. Третья тоньше: Рег.ру отдельно оговаривает, что «система резервного копирования баз данных не гарантирует корректность кодировки бэкапа в случае, если данные были помещены в базу в некорректной кодировке». То есть сам хостинг признаёт, что дамп может оказаться негодным, и не предлагает способа это заранее увидеть.

И отдельная строка про cron-задания и настройки панели у Рег.ру — это значит, что после отката придётся заново завести расписание задач и всё, что настраивалось кнопками, а не файлами. Это та часть восстановления, которую никто не планирует.

04Проверка 3. Файлы без базы не восстанавливаются

Если сайт на WordPress, Битриксе или другой системе с базой данных, копия — это всегда две части. Документация WordPress формулирует это без запаса: «There are two parts to backing up your WordPress site: Database and Files. You need both to be able to fully restore a typical WordPress site» — нужны обе, чтобы полностью восстановить типовой сайт. И там же снята самая частая иллюзия: скачивание каталога сайта базу не копирует, потому что база живёт вне этого каталога, в MySQL или MariaDB.

Что именно сохранять, документация называет прямо: все файлы каталога WordPress вместе с подкаталогами и файл .htaccess, причём особое внимание — каталогу wp-content с вашими темами, плагинами и загрузками и файлу wp-config.php, в котором лежат реквизиты подключения. Файлы ядра копировать обычно не нужно: их можно заменить свежей загрузкой архива с wordpress.org. В инструкции по переносу сайта требование про .htaccess сформулировано ещё жёстче: «This is not a recommendation but a requirement» — это не рекомендация, а требование.

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

05Проверка 4. Скачайте последнюю копию и откройте её

Это пять минут раз в квартал и единственная проверка, которую нельзя заменить рассуждением. Зайдите в раздел резервных копий, скачайте самую свежую, распакуйте на своём компьютере и ответьте на три вопроса: есть ли внутри каталог сайта с реальными файлами, есть ли дамп базы, и той ли это базы, которую использует ваш сайт. Имя базы написано в wp-config.php; у Рег.ру отдельно оговорено, что система не восстановит базу, которой нет на хостинге, — то есть перед откатом пустую базу с тем же именем нужно создать руками.

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

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

06Проверка 5. Восстановление проверяется рядом с сайтом, а не на сайте

Проверка, которой нет ни на одной странице топа, и именно её требуют стандарты. AWS в своём фреймворке надёжности выносит отдельный пункт REL09-BP04 — периодически восстанавливать данные, чтобы проверить целостность копий и сам процесс, — и перечисляет анти-паттерны: восстановить копию и не сделать ни одного запроса к данным, чтобы убедиться, что восстановленное пригодно; предполагать, что копия существует; предполагать, что копия системы полностью работоспособна и из неё можно восстановить данные. NIST в руководстве по планированию непрерывности (SP 800-34 Rev. 1) ставит это требованием контроля CP-9: тестировать резервную информацию, чтобы проверить надёжность носителя и целостность данных, и использовать образец копии для восстановления отдельных функций системы.

На небольшом сайте это выглядит так. Создаётся технический поддомен вида test.вашдомен.ru, рядом — пустая база, и копия разворачивается туда. Проверяется не то, что главная открылась, а то, что внутри есть данные: последние заявки, последние заказы, свежие записи. На WordPress порядок тот же, что в документации: файлы, затем импорт дампа, затем правка wp-config.php под новые реквизиты базы.

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

07Проверка 6. Копия заражённого сайта заражена тоже

Вирусы в выдаче названы причиной бэкапа почти везде, и нигде не сказано главное: свежая копия взломанного сайта содержит тот же бэкдор. Timeweb Community честно описывает тупик: «Хостеры редко хранят копии больше, чем за две недели. Если ваш портал атаковали 30 дней назад, а БД удалились только сейчас, копия от провайдера вам ничем не поможет». Выход из тупика там не описан.

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

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

08Проверка 7. Расписание: что умеют плагины бесплатно

Если копию делает плагин, проверьте две вещи — есть ли расписание и куда уходит архив. По каталогу плагинов WordPress на 29 октября 2026 года картина такая.

Здесь есть число, которое стоит отдельного абзаца, потому что его переписывают друг у друга годами. «Лимит бесплатной версии All-in-One WP Migration — 512 Мб» на официальной странице плагина больше не подтверждается: там сказано, что бесплатный плагин экспортирует сайт любого размера, а предел загрузки задаёт хостинг, и «the Import screen shows that number» — экран импорта показывает это число, и разработчик на него не влияет. Цифра 512 Мб живёт в справке Рег.ру, то есть это ограничение конкретного окружения, а не плагина. Своё число вы увидите на экране импорта своего сайта, и только оно имеет значение.

Разберём именно
ваш сайт бесплатно

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

Что входит в разбор

• 1
  Где теряются заявкипуть от объявления до формы
• 2
  Что поправить на сайтепервый экран, оффер, формы
• 3
  Что поменять в рекламезапросы, объявления, бюджет

Михаил Лапошинразберу ваш проект лично

Ваше имяТелефонСайт

TelegramWhatsAppЗвонок

Согласен на обработку данных и политику конфиденциальностиПолучить бесплатный разбор

✓ Заявка принята — отвечу в течение часа

09Проверка 8. Тильда: копия есть, но восстанавливаете её не вы

На конструкторе проверка другая, потому что доступа к файлам нет. Резервные копии у Тильды есть, но порядок описан так: запросить восстановление можно только через поддержку, написав в чат или на почту, и «это может занять до суток».

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

Своя выгрузка на Тильде тоже есть, но она тарифная: экспорт кода доступен «только на линейке тарифов Business, от 5 сайтов и больше», это 1000 ₽ в месяц при оплате за год и 1250 ₽ при месячной. И у него свой список ограничений: сертификат HTTPS, добавленный на стороне Тильды, работать не будет, пароль на страницу не экспортируется, ресурсы Tilda CRM и Личного кабинета не экспортируются вовсе. Что из конструктора выгружается, а что остаётся внутри, видно по разбору сроков и потерь при уходе с Тильды, и для бэкапа оттуда важен один вывод: архив экспорта — это копия внешнего вида страниц, а не копия сайта вместе с заявками и настройками приёма данных.

10Проверка 9. Сколько вернут деньгами, если копии не окажется

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

У Beget есть и процедурные условия: компенсация выплачивается не деньгами, а продлением услуги и бонусами, и запросить её нужно в течение 30 дней после инцидента. У Timeweb отдельным пунктом записано право вносить изменения в файлы при обнаружении вредоносного кода, и в этом случае «утрата файлов Лицензиата или их неработоспособность, а также возможные убытки Лицензиата не подлежат денежной компенсации».

Сравните это с ценой простоя. Месяц виртуального хостинга — это сотни рублей, а неделя лежащего магазина — недельная выручка плюс позиции в поиске. Яндекс описывает механику без запаса: страница, ставшая недоступной для робота, исключается из поиска, а при ошибке сервера «сайт может полностью пропасть из поиска»; после того как ответ станет снова 200 OK, страница может появиться в поиске в течение двух недель. То есть счёт за потерянную копию складывается не из возмещения, а из выручки и из срока обратного возвращения в индекс.

11Проверка 10. Где лежит вторая копия

Правило, на которое ссылаются все и которое почти никто не цитирует по источнику. Оно из документа US-CERT «Data Backup Options» 2012 года, опубликованного на домене CISA, и сформулировано там так: держите три копии любого важного файла — одну рабочую и две резервные; держите файлы на двух разных типах носителей, чтобы защититься от разных типов угроз; храните одну копию вне площадки. Тот же документ объясняет, зачем: повреждение или вредоносный код из основных файлов незаметно переносится в резервные, а при выходе из строя или краже носителя теряются и рабочие файлы, и копии сразу.

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

То, что панельных копий недостаточно, пишет и сам хостинг. Документация Timeweb Cloud: копии, создаваемые в панели управления, защищают не от всех возможных проблем, при программном или аппаратном сбое на сервере либо удалении сервера восстановить данные будет невозможно, и рекомендуется дополнительно создавать удалённые копии. Это 3-2-1 словами провайдера.

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

12Что из этого делать на этой неделе

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

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

Михаил ЛапошинМаркетолог, руководитель Laposhin Agency

«Делаем сайты и запускаем Яндекс Директ так, чтобы
сайт приносил заявки, а не просто был»

Есть вопрос по статье?Задать вопрос в Telegram