Хостинг обещает резервные копии. Как проверить, что они есть
О том, что резервная копия не работает, обычно узнают в день, когда она понадобилась. Пять вопросов хостингу, проверка на пятнадцать минут и результаты такой же проверки у нас самих.
- Как резервное копирование ломается молча
- Пять вопросов хостингу
- Проверка на пятнадцать минут
- Держите одну копию не у хостинга
- Что делаем мы и что показала проверка
- Что делать с результатом
«Ежедневные резервные копии» есть почти в любом тарифе любого хостинга, и в наших тоже. При этом проверяют их в последнюю очередь: смотреть там не на что, пока ничего не случилось. А потом обновление плагина роняет магазин, кто-то удаляет не ту папку или у вас крадут пароль. В этот день и выясняется, что на самом деле значили слова «ежедневные резервные копии».
Лучше выяснить это в спокойный вторник. Проверка, описанная ниже, занимает минут пятнадцать. Дальше мы рассказываем, что она показала на нашей собственной платформе, в том числе об одном результате, который выглядел как ошибка.
Как резервное копирование ломается молча#
Сломанное резервное копирование редко выдаёт сообщение об ошибке и может оставаться сломанным месяцами, пока кто-нибудь не заглянет внутрь.
Задание отработало, а в копии пусто. Программа сообщает, что задание завершилось. О том, попал ли в копию ваш сайт, она не сообщает. Задание может завершиться без единой ошибки, хотя не нашло ни одного аккаунта, пропустило базу данных, которую не смогло прочитать, или остановилось на первом файле, который не открылся. В журнале всё равно будет написано «выполнено».
Копия лежит рядом с оригиналом. Плагин, который складывает архив в папку того же хостинг-аккаунта, спасает от неудачного обновления и почти ни от чего больше. Если аккаунт взломают, откажет диск или аккаунт закроют, сайт пропадёт вместе с копией. То же самое относится к хостингу, который хранит копии на том же сервере, с которого их снимает.
История слишком короткая. Большинство проблем замечают не в тот день, когда они начались. Вредоносный код, который подбросили три недели назад и который проснулся только вчера, есть в каждой из семи последних ежедневных копий. Поэтому глубина истории важна не меньше, чем частота копирования.
В копии только половина сайта. Сайт на WordPress состоит из папки с файлами и базы данных, и одно без другого не работает. Копия, в которой есть только файлы или нет почтовых ящиков, в списке дат выглядит точно так же, как полная.
Самое трудное — восстановить. Одни хостинги делают копии на случай собственной аварии: они могут поднять сервер целиком, а один ваш файл доставать не станут. Другие восстанавливают по заявке, за деньги и через день-два. Третьи умеют вернуть только весь аккаунт сразу, а это стирает все заказы и письма, которые пришли после создания копии.
Ничего из этого не видно, пока вы не попробуете что-нибудь вернуть. Поэтому единственная настоящая проверка — попробовать.
Пять вопросов хостингу#
Они помещаются в одно письмо. Наши ответы ниже.
- Как часто делаются копии и как долго они хранятся? Нужны обе цифры, причём для вашего тарифа, а не для самого дорогого.
- Где лежат копии? На том же сервере, в том же здании или у другой компании? Если вы работаете с данными клиентов, спросите ещё, в какой стране. Зачем это нужно, мы разбирали в статье о том, как проверить хостинг на соответствие GDPR.
- Что в них входит? Файлы, базы данных, почтовые ящики и настройки аккаунта или только часть этого списка?
- Могу ли я сам восстановить один файл или одну базу данных и сколько это стоит?
- Когда вы в последний раз восстанавливали копию для проверки?
Пятый вопрос самый показательный. Компания, которая проверяет восстановление, назовёт дату.
Проверка на пятнадцать минут#
Разрешения на неё ни у кого спрашивать не нужно, и на работающем сайте ничего не изменится. Задача — скачать из копии один файл и одну базу данных и заглянуть внутрь.
1. Найдите инструмент для работы с копиями. На хостинге с cPanel он находится в самой cPanel, обычно в разделе «Файлы» (Files) или в отдельном разделе. У многих провайдеров, как и у нас, это JetBackup, у других — встроенные в cPanel инструменты Backup и File and Directory Restoration. Если у хостинга другая панель управления, ищите пункт меню с названием вроде «Резервные копии» или «Восстановление». Не нашли за пять минут — переходите к письму в поддержку, о нём ниже.
2. Сначала изучите список дат. Самая свежая копия сделана прошлой ночью? Самая старая сделана столько дней назад, сколько обещает тариф? Нет ли пропусков? Если список обрывается месяц назад, ответ вы уже получили.
3. Скачайте один файл из самой старой копии. Выберите то, что узнаете с первого взгляда: картинку из давней записи в блоге или файл стилей вашей темы. Берите самую старую копию в списке: так вы заодно проверите глубину истории. Нажимайте «скачать» (Download), а не «восстановить» (Restore), чтобы файл на сайте остался как есть. Обычно инструмент готовит файл в фоне и отдаёт его сжатым архивом, чаще всего с расширением .tar.gz. В Windows 11 и macOS такой архив распаковывается двойным щелчком, в более старых версиях Windows поможет бесплатная программа 7-Zip. Откройте файл из архива и убедитесь, что это тот самый.
4. Скачайте базу данных из самой свежей копии. Копия базы данных — это текстовый файл, обычно сжатый. Убедитесь, что его размер не равен нулю, распакуйте его и откройте в простом текстовом редакторе, например в «Блокноте» или TextEdit. Потом найдите в нём что-нибудь недавнее и состоящее из слов: заголовок последней записи или адрес почты из последнего заказа. Номер заказа не подойдёт: одни цифры встречаются в файле слишком часто. Судите о файле по содержимому, а не по дате в его конце. У нас эта дата оказалась на одиннадцать дней старше самой копии, а файл был правильным. Об этом ниже.
5. Запишите, сколько времени это заняло и где находятся нужные кнопки. В следующий раз вы будете делать всё это в спешке.
Если у хостинга нет инструмента, которым вы можете пользоваться сами, напишите в поддержку одну строку: «Положите, пожалуйста, вчерашние копии файла index.php и базы данных в отдельную папку в моём аккаунте». И засеките, через сколько придёт ответ.
Для нашей платформы пошаговые инструкции есть в Центре поддержки: как восстановить файл или папку (там же описано, как скачать копию файла, не восстанавливая его) и как восстановить базу данных.
Держите одну копию не у хостинга#
Даже если проверка прошла хорошо, держите собственную копию. Копии хостинга защищают от ваших ошибок и от отказа оборудования. Они не защитят, если у вас возник спор с хостингом, если срок действия карты истёк, пока вы были в отпуске, или если ошибся сам хостинг. Мы прямо пишем об этом в наших Условиях обслуживания: эти резервные копии не заменяют ваши собственные, и мы не гарантируем, что какая-либо конкретная копия будет существовать, окажется полной и пригодной для восстановления.
Небольшому сайту хватит простого правила: раз в месяц и перед каждым крупным изменением. Создайте в cPanel полную резервную копию, скачайте её и храните за пределами хостинг-аккаунта. Ноутбука и облачного диска достаточно. Для нашей платформы шаги описаны в статье «Как скачать резервную копию вашего сайта». Архив с сервера после этого удалите: пока он там лежит, он занимает место на диске, отведённое вашим тарифом.
Что делаем мы и что показала проверка#
Сначала наши ответы на те же пять вопросов.
Как часто и как долго. Резервная копия каждого хостинг-аккаунта создаётся автоматически: ежедневно на всех тарифах, кроме Self-Managed Lite, где она еженедельная. На Lite хранится только последняя еженедельная копия. Если потерять изменения за неделю для вас болезненно, на Lite делайте собственные копии или выберите другой тариф. На Self-Managed Plus история хранится 7 дней, на Self-Managed Pro — 14 дней, на всех тарифах Managed — 30 дней. В примере с вредоносным кодом трёхнедельной давности выручили бы только 30 дней. На Plus и Pro этот разрыв закрывает ваша собственная ежемесячная копия. Полная таблица есть в статье «Срок хранения резервных копий по тарифам».
Где. Не на сервере. Копии уходят в хранилище в Амстердаме. Им управляет Backblaze, и это не та компания, в дата-центре которой стоят наши серверы. В хранилище копии шифрует сам провайдер (AES-256). Backblaze зарегистрирована в США, у неё есть европейский регион, и она названа в нашем списке субобработчиков.
Что входит. Файлы сайта, базы данных, почтовые ящики из вашего тарифа вместе с письмами и настройки аккаунта, например задания по расписанию (cron), SSL-сертификаты и FTP-аккаунты. Не входят две вещи, потому что они находятся не на сервере хостинга: ящики Microsoft 365 и Google Workspace, которые хранят сами эти провайдеры, и DNS-записи, которые хранятся отдельно, в личном кабинете.
Можно ли восстановить самому и сколько это стоит. Да, через JetBackup в cPanel, и доплачивать за это не нужно: файл, папку, базу данных, почтовый ящик или весь аккаунт. Можно восстановить на прежнее место, а можно скачать. На тарифах Managed восстановление входит в услугу, так что мы сделаем это за вас, если вам так удобнее. Напишите в поддержку, что нужно вернуть и за какой день.
Когда мы в последний раз восстанавливали копию для проверки. 29 сентября 2026 года, для этой статьи. Мы забрали копию из хранилища, распаковали её и сверили с работающим сайтом.
Проверка#
Мы взяли один из собственных сайтов. Это блог, он работает в обычном аккаунте на тарифе Managed, на том же сервере, что и сайты клиентов. Из хранилища в Амстердаме мы запросили копию, сделанную прошлой ночью.
| Шаг | Результат |
|---|---|
| Копия создана | 29 сентября, 00:00 UTC |
| Запрошена | 29 сентября, 17:43 UTC |
| Готова к открытию | через 40 секунд |
| Размер архива | 25 МБ |
| Внутри | 15 643 файла, база данных, SSL-сертификат, задания cron |
Потом мы сравнили каждый файл из копии с работающим сайтом по контрольным суммам. Контрольная сумма — это отпечаток файла: он меняется, если в файле изменился хотя бы один символ.
- 15 342 файла совпали полностью.
- 30 файлов отличались. Все они были изменены на сайте уже после создания копии, так что в копии лежала версия прошлой ночи, как и должно быть.
- 271 файл остался только в копии, а 145 файлов были только на сайте. Первые оказались файлами кэша и сессий, которые сайт с тех пор удалил. Вторые все до одного появились после создания копии.
- 6 файлов были старше копии, но в неё не попали. Все шесть — служебные: платформа хостинга ведёт их для себя, например счётчик почтовой квоты и файлы выбора версии PHP. Содержимого сайта ни в одном из них нет.
Результат, который выглядел как ошибка#
Копия базы данных внутри этого архива (на жаргоне — «дамп») была датирована 18 сентября. Ей было одиннадцать дней, хотя саму резервную копию сделали прошлой ночью. Это та самая «половина сайта» из начала статьи — или что-то очень на неё похожее.
В журнале резервного копирования нашлось объяснение: с 18-го числа база не менялась, поэтому программа оставила прежний дамп и не стала записывать точно такой же. Но журнал, в котором написано, что всё в порядке, — это ровно то, на что мы только что советовали не полагаться. Поэтому мы сравнили дамп с рабочей базой, таблица за таблицей. Все четырнадцать таблиц совпали строка в строку: в пяти лежат записи блога, рубрики и его единственный пользователь, остальные девять пусты и там и там. С 18 сентября в блоге просто ничего не публиковали. А у другого сайта на том же сервере база успела измениться, и в ту же ночь для неё был записан свежий дамп.
Копия оказалась правильной, а дата вводила в заблуждение. И то и другое мы знаем только потому, что открыли копию.
Чего эта проверка не доказывает#
Это был один аккаунт и одна ночь, и копию мы распаковали в отдельную папку, а не восстановили поверх работающего сайта. Сайт к тому же небольшой: магазин с несколькими гигабайтами картинок будет возвращаться дольше 40 секунд. Это выборочная проверка, и она не гарантирует, что с каждым аккаунтом каждую ночь всё так же. Поэтому совет из раздела «Держите одну копию не у хостинга» относится к нашим клиентам так же, как к клиентам любого другого хостинга.
Что делать с результатом#
Если список дат короткий, скачанный файл не открывается или поддержка не может сказать, когда в последний раз проверяла восстановление, начните с того, что ни от кого не зависит: скачайте собственную копию сегодня. Потом напишите в поддержку, что именно вы обнаружили и за какие даты, и спросите, что они изменят.
Если всё в порядке, поставьте в календарь напоминание повторить проверку через три месяца, а также после смены тарифа или хостинга.
Если проще переехать, мы переносим сайты бесплатно, сравнить тарифы можно на странице тарифов, а вопросы о вашей конфигурации можно прислать через контактную форму.