Резервное копирование — это процесс создания копий ваших данных (файлов сайта, баз данных, почтовых ящиков) с целью их восстановления в случае потери оригиналов.
Потеря может произойти по множеству причин:
Ошибка пользователя: вы случайно удалили папку /wp-content, перезаписали базу данных при обновлении.
Взлом: хакер удалил файлы или зашифровал их.
Сбой программного обеспечения: обновление CMS сломало сайт, и откат невозможен.
Проблемы на стороне хостинга: редко, но бывает — сбой RAID-массива, ошибка администратора, человеческий фактор.
Юридические действия: сайт заблокирован по решению суда, и данные удалены.
Во всех этих случаях только резервная копия спасает. Никакие «обещания поддержки» не вернут ваши данные, если их нет.
И здесь начинается главная путаница. Многие думают: «Я плачу за хостинг — значит, они обязаны делать бэкапы и хранить их вечно». Это ошибка.
На самом деле существует три уровня ответственности:
Хостинг-провайдер
Большинство хостингов действительно делают резервные копии — но с оговорками:
Не все тарифы включают бэкапы. На самых дешёвых тарифах («Старт», «Мини») функция может быть отключена.
Копии делаются не для вас, а для себя. То есть — для восстановления сервера после аварии, а не для восстановления вашего конкретного сайта по вашему запросу.
Хранение ограничено по времени: обычно от 3 до 14 дней. После этого копии удаляются.
Восстановление — платная услуга. Даже если копия есть, вам могут выставить счёт за «ручное восстановление».
Нет гарантии полноты. Иногда копируются только файлы, но не базы данных. Или наоборот.
Пример из практики: хостинг делает ежедневные снимки (snapshots) всей виртуальной машины. Но если ваш сайт был взломан 20 дней назад, а копии хранятся 7 дней — вы не сможете откатиться к «чистому» состоянию.
Вы — владелец сайта
Согласно условиям почти всех хостингов (читайте договор!), основная ответственность за сохранность данных лежит на вас. Хостинг предоставляет инструменты, но не гарантирует сохранность.
Это не жестокость. Это разделение рисков. Хостинг отвечает за сервер, вы — за контент.
Сторонние сервисы
Вы можете подключить внешние системы резервного копирования:
- Плагины для CMS (UpdraftPlus для WordPress),
- Облачные хранилища (Яндекс.Диск, Google Drive, Dropbox),
- Специализированные сервисы (BackupBuddy, BlogVault).
Это — ваша страховка. И только она даёт реальную защиту.
Как часто делать резервные копии зависит от хостинга и тарифа. Но типичные сценарии:
Ежедневное копирование
Самый распространённый вариант. Копия создаётся раз в сутки — обычно ночью, в часы минимальной нагрузки.
Плюс: если сайт сломался сегодня утром, вы можете откатиться на вчерашнее состояние.
Минус: всё, что было создано сегодня (новые заказы, комментарии, статьи), будет потеряно.
Ежечасное копирование
Встречается на дорогих тарифах или VPS. Но даже здесь — с ограничениями.
- Обычно копируются не все данные, а только выжные.
- Хранение — не более 24 часов.
Раз в неделю
На дешёвых тарифах или у мелких хостингов. Крайне рискованно. Потеря до 7 дней работы.
Важно: копирование ≠ архивирование
Хостинг может делать «снимки»диска, но это не то же самое, что архив с файлами и дамп базы данных. Снимок — это образ всей системы. Восстановить из него один сайт сложно и требует вмешательства администратора.
Не всё, что вы видите в панели управления, попадает в резервную копию.
Обычно входят:
- Файлы сайта (папка /public_html или аналог),
- Базы данных MySQL/PostgreSQL,
- Настройки почтовых ящиков (но не всегда письма),
- Конфигурационные файлы веб-сервера (для вашего аккаунта).
Не входят:
- Файлы вне корневой директории (например, /backup или /logs),
- Почтовые сообщения (если не используется отдельное почтовое хранилище),
- Cron-задачи (планировщик задач),
- SSL-сертификаты (хотя Let’s Encrypt можно перевыпустить),
- Данные сессий, кэш.
Если вы храните важные файлы в нестандартных папках — они не попадут в бэкап.
Где хранятся резервные копии? - Это один из самых важных, но редко задаваемых вопросов.
Варианты:
На том же сервере
— Самый плохой сценарий. Если сгорит диск — пропадут и данные, и копии.
— Встречается у дешёвых хостингов.
На отдельном сервере в том же дата-центре
— Лучше, но при пожаре, наводнении или массовом сбое — всё равно потеря.
В географически удалённом дата-центре
— Идеальный вариант. Но встречается редко на виртуальном хостинге. Чаще — на VPS или облачных решениях.
В облаке (Amazon S3, Google Cloud Storage)
— Надёжно, но увеличивает стоимость. Обычно доступно только на премиум-тарифах.
Проверьте у своего хостинга: где хранятся копии? Если ответа нет — считайте, что они на том же сервере.
Как восстановить сайт из резервной копии?
Процесс зависит от хостинга, но типичные сценарии:
Самостоятельное восстановление через панель управления
На хостингах с хорошей панелью (cPanel, ISPmanager) есть раздел «Резервные копии» или «Восстановление».
- Вы выбираете дату копии,
- Нажимаете «Восстановить»,
- Система перезаписывает текущие файлы и базу данных.
Важно: это полная замена. Всё, что было создано после даты копии, исчезнет.
Запрос в техническую поддержку
Если функции самостоятельного восстановления нет:
- Вы пишете в поддержку,
- Указываете дату и время,
- Ждёте (от нескольких часов до нескольких дней),
- Возможно, платите за услугу (от 300 до 2000 рублей).
Риски:
- Поддержка может отказать, если копия «повреждена»,
- Восстановление может затронуть другие сайты в аккаунте,
- Нет гарантии, что восстановят именно то, что нужно.
Восстановление из внешнего архива
Если вы делали копии вручную или через плагин:
- Скачиваете архив с облака,
- Загружаете файлы через FTP или файловый менеджер,
- Импортируете базу данных через phpMyAdmin,
- Проверяете работоспособность.
Это дольше, но полностью под вашим контролем.
Сколько хранятся резервные копии?
Типичные сроки:
- 3 дня — на самых дешёвых тарифах,
- 7 дней — стандарт для большинства хостингов,
- 14–30 дней — на премиум-тарифах или по запросу (иногда платно),
- Бессрочно — почти никогда не бывает на виртуальном хостинге.
Пример: вы обновили WordPress 1-го числа. Сайт сломался, но вы заметили только 10-го. Если хостинг хранит копии 7 дней — у вас нет «чистой» версии. Вы либо восстанавливаете сломанную, либо теряете всё.
Почему нельзя полагаться только на хостинг?
Позвольте привести реальные кейсы из практики:
Взлом + устаревшая копия
Сайт на WordPress был взломан. Хакер удалил все файлы и оставил сообщение. Хостинг предложил восстановить из копии за 7 дней. Но за эти 7 дней хакер уже внедрил бэкдоры. Восстановленный сайт снова начал рассылать спам.
Ошибка при переносе
Клиент переносил сайт на новый хостинг, случайно удалил базу данных на старом. Обратился к хостингу — копии хранились 3 дня, а прошло 5. Данные утеряны навсегда.
Платное восстановление
Хостинг сделал копию, но при запросе выставил счёт в 1500 рублей за «ручную работу». Клиент отказался — и потерял интернет-магазин с 200 заказами.
Эти случаи не исключения. Они — норма, когда вы полагаетесь только на хостинг.
Как организовать надёжное резервное копирование?
Если вы серьёзно относитесь к своему проекту — вы обязаны создать многоуровневую систему бэкапов.
Уровень 1. Автоматические копии через CMS
Для WordPress:
- Установите плагин UpdraftPlus (бесплатно).
- Настройте резервное копирование файлов и базы данных.
- Отправляйте копии в Яндекс.Диск, Google Drive или Dropbox.
- Выберите частоту: ежедневно для активных сайтов, раз в неделю — для блогов.
Для других CMS (Bitrix, OpenCart) — аналогичные решения существуют.
Уровень 2. Ручные копии
Раз в месяц делайте полную копию вручную:
- Через файловый менеджер или FTP — скачайте папку /public_html.
- Через phpMyAdmin — экспортируйте базу данных в SQL-файл.
- Архивируйте всё в ZIP с датой.
- Сохраните на внешний жёсткий диск и в облако.
Уровень 3. Мониторинг
- Включите уведомления о сбоях (например, через UptimeRobot).
- Раз в квартал проверяйте, можно ли восстановить сайт из архива.
Правило 3-2-1:
- 3 копии данных (оригинал + 2 резервных),
- 2 разных носителя (сервер + облако),
- 1 копия вне офиса (облако или внешний диск).
Это — золотой стандарт. И он доступен даже новичку.
Что делать, если сайт сломан?
Если вы читаете это после катастрофы — действуйте по плану:
Не паникуйте. Большинство ситуаций обратимы, если действовать спокойно.
Свяжитесь с хостингом — уточните, есть ли копии, за какой период, сколько стоит восстановление.
Проверьте свои архивы — возможно, у вас есть более свежая копия, чем у хостинга.
Если данных нет — обратитесь к специалисту по восстановлению. Иногда можно восстановить базу из логов или кэша.
После восстановления — смените все пароли, обновите CMS, установите защиту от взлома.
Но помните: лучшее восстановление — это то, которое не понадобилось.
Я не оправдываю хостинги, которые скрывают условия бэкапов мелким шрифтом. Но и вы несёте ответственность. Потому что:
- Вы не прочитали договор,
- Вы не проверили наличие функции бэкапа перед покупкой,
- Вы не сделали собственных копий.
Хостинг — это аренда сервера, а не «цифровая няня». Он даёт инструменты, но не гарантирует результат.
Резервное копирование как привычка пристёгивать ремень безопасности. Вы не думаете: «А вдруг сегодня ДТП?» Вы просто пристёгиваетесь.
Так и с сайтом. Не ждите катастрофы. Не верьте на слово. Не экономьте на том, что нельзя вернуть.
Сделайте резервную копию сегодня. Даже если «всё работает». Особенно если «всё работает».
Потому что завтра может быть поздно.
