Резервная копия сайта — это полный набор файлов и базы данных, из которого сайт можно поднять заново. Интернет-магазину и сайту с заявками нужен ежедневный автоматический бэкап базы, остальным — хотя бы еженедельный, плюс копия перед каждым обновлением. Хранить копии нужно минимум в двух местах, одно — вне хостинга.
Почему бэкап нужен даже «маленькому» сайту
Чаще всего сайты ломаются не из-за хакеров, а из-за обычных вещей: неудачное обновление плагина, случайно удалённая страница, ошибка подрядчика, закончившаяся оплата хостинга, сбой на сервере. В каждом из этих случаев разница между «потеряли полчаса» и «потеряли сайт» — наличие свежей и проверенной копии.
Посчитайте, во что обойдётся восстановление с нуля: дизайн, вёрстка, наполнение, настройка SEO, накопленные отзывы и заказы. Даже для небольшого сайта это недели работы и заметные деньги — напомним, что разработка лендинга у нас начинается от 180 000 ₽. Бэкап стоит несоизмеримо дешевле.
Что именно нужно копировать
Частая ошибка — сохранять только файлы или только базу. Сайт на CMS состоит из нескольких частей, и нужна каждая из них.
- База данных — тексты страниц, товары, заказы, пользователи, настройки. На WordPress и 1С-Битрикс это MySQL или MariaDB. Меняется чаще всего.
- Загруженные файлы — изображения, документы, прайсы (в WordPress — папка wp-content/uploads, в Битриксе — upload).
- Код — ядро CMS, тема, плагины и модули, особенно если в них есть доработки.
- Конфигурация — wp-config.php, .htaccess, настройки nginx, crontab, файлы dbconn.php и .settings.php в Битриксе.
- Внешнее — DNS-записи домена, настройки почты, доступы. Это не копируется автоматически, поэтому держите актуальную выписку в защищённом менеджере паролей.
А если сайт на конструкторе?
На Tilda и подобных платформах сервер и резервирование — забота платформы, но от ваших собственных ошибок это не спасает. Периодически делайте экспорт сайта (в Tilda он доступен на платных тарифах), выгружайте заявки и список товаров. Если экспорта нет, как минимум сохраняйте тексты и изображения отдельно.
Как часто делать резервные копии
Правильная частота — не «раз в неделю, потому что так принято», а ответ на вопрос: сколько данных вы готовы потерять? Если заказы приходят каждый час, потеря суток — это потеря суток заказов.
| Тип сайта | База данных | Файлы | Хранить копий |
|---|---|---|---|
| Лендинг, сайт-визитка, редко меняется | Раз в неделю | Раз в неделю | 4–8 недельных |
| Корпоративный сайт с блогом и формами | Ежедневно | Раз в неделю | 14 ежедневных + 4 недельных |
| Интернет-магазин, личные кабинеты | Ежедневно, при большом потоке заказов — несколько раз в день | Ежедневно (инкрементно) | 30 ежедневных + несколько месячных |
Плюс к расписанию — внеплановая копия перед каждым обновлением CMS, установкой плагина, сменой темы, импортом товаров и любой работой подрядчика. Это правило спасает чаще, чем все остальные вместе.
Почему нужно хранить старые копии
Некоторые проблемы обнаруживаются не сразу: вредоносный код может сидеть на сайте неделями, а удалённый раздел заметят через месяц. Если вы храните только последнюю копию, она уже будет «испорченной». Поэтому нужна глубина — несколько ежедневных, недельных и месячных версий.
Где хранить: правило 3-2-1
Классический принцип надёжного хранения звучит так:
- 3 копии данных (рабочий сайт и две резервные);
- 2 разных носителя или сервиса;
- 1 копия — физически в другом месте, не на том же сервере и не у того же провайдера.
Бэкап, который лежит в папке на том же хостинге, защищает от ошибок в CMS, но не от проблем с сервером, блокировки аккаунта или взлома: злоумышленник, получивший доступ к сайту, может удалить и копии. Хорошая схема для малого бизнеса выглядит так: автоматические копии хостинга плюс ежедневная выгрузка во внешнее облачное хранилище (S3-совместимое хранилище российского провайдера, Яндекс Облако или аналог).
Учитывайте персональные данные
В базе сайта обычно лежат имена, телефоны и почты клиентов. Это персональные данные, и копии нужно защищать так же, как сам сайт: шифровать архивы, ограничивать доступ, хранить у провайдера в России. Не отправляйте дампы базы по почте и не храните их в личных облаках сотрудников.
Как настроить автоматическое копирование
Средства хостинга
Большинство российских хостингов (Timeweb, Beget, REG.RU, Sprinthost и другие) делают ежедневные копии аккаунта и хранят их ограниченное время. Уточните в панели или у поддержки: как долго хранятся копии, входит ли в них база, можно ли восстановить отдельный файл. Это хорошая первая линия защиты, но не единственная.
WordPress
Популярные плагины — UpdraftPlus, BackWPup, Duplicator, All-in-One WP Migration. Для резервирования удобнее первые два: они умеют работать по расписанию и отправлять архивы во внешнее хранилище. Минимальная настройка:
- Расписание: база — ежедневно, файлы — еженедельно.
- Хранилище: внешнее (S3, FTP на другом сервере, облако).
- Глубина хранения: не меньше 14 копий базы.
- Уведомления на почту об успешном и неудачном копировании.
На крупных сайтах плагины могут не справляться с объёмом и таймаутами — тогда копирование переносят на уровень сервера.
1С-Битрикс
В административной панели есть раздел «Резервное копирование» с поддержкой расписания. Облачное хранилище 1С-Битрикс входит в лицензию с ограничением по объёму, также можно указать своё хранилище. Проверьте, что в копию включаются ядро и загруженные файлы, а не только база.
Свой сервер (VPS)
Здесь всё настраивается вручную: дамп базы через mysqldump по cron, архивация файлов, отправка во внешнее хранилище утилитами вроде rclone или restic. Restic и аналоги умеют делать инкрементные копии и шифровать их — это экономит место и время. Обязательно настройте оповещение, если задание не выполнилось.
Главное: проверка восстановления
Бэкап, который ни разу не восстанавливали, — это надежда, а не резервная копия. Архив может оказаться битым, неполным или зашифрованным ключом, который никто не сохранил.
Раз в квартал проводите «учения»:
- Возьмите случайную копию недельной давности.
- Разверните её на тестовом поддомене или локально.
- Проверьте: открываются ли страницы, есть ли свежие товары и записи, работает ли админка, на месте ли картинки.
- Засеките время. Если восстановление заняло полдня — пропишите инструкцию, чтобы в реальной аварии не терять время.
- Удалите тестовую копию и закройте её от индексации, чтобы не создать дубль сайта в поиске.
Мини-регламент для владельца сайта
- Знаете, где лежат копии и кто имеет к ним доступ.
- Получаете уведомления о выполнении или сбое копирования.
- Есть минимум одна копия вне основного хостинга.
- Копия делается перед любыми обновлениями и работами.
- Раз в квартал проводится тестовое восстановление.
- Доступы к хостингу, домену и хранилищу записаны и защищены двухфакторной аутентификацией.
- Есть короткая письменная инструкция по восстановлению, понятная не только текущему подрядчику.
Последний пункт часто недооценивают. Подрядчики меняются, сотрудники уходят, и в момент аварии выясняется, что единственный человек, знавший пароль от хранилища, недоступен. Инструкция на одну страницу с перечнем мест хранения и порядком действий снимает эту зависимость.
Частые вопросы
Хостинг и так делает бэкапы — этого недостаточно?
Это хорошая база, но у неё есть ограничения: копии хранятся на стороне того же провайдера, обычно недолго, и при блокировке аккаунта или споре с хостингом вы можете потерять к ним доступ. Одна независимая внешняя копия закрывает этот риск.
Сколько места занимают резервные копии?
Зависит в первую очередь от объёма изображений и документов. База обычно весит немного, а вот медиафайлы могут занимать гигабайты. Инкрементные копии, при которых сохраняются только изменения, заметно экономят место. Место в облачном хранилище стоит недорого, но зависит от провайдера.
Можно ли делать бэкап вручную?
Можно, но это ненадёжно: о ручной копии забывают как раз тогда, когда она нужнее всего. Ручные копии хороши как дополнение — перед крупными изменениями. Основа должна быть автоматической и с уведомлениями о сбоях.
Что делать, если копии нет, а сайт сломался?
Проверьте, нет ли копий у хостинга — многие хранят их даже без явной настройки. Частично восстановить тексты можно из кэша поисковиков и веб-архива. Разработчик, делавший сайт, тоже может сохранить исходники. После восстановления сразу настройте автоматическое копирование.
Настройка и контроль резервного копирования входят в поддержку сайтов Pear Advert: базовый тариф стоит 5 000–15 000 ₽ в месяц. Мы настроим внешние копии, проверим восстановление и будем следить за уведомлениями. Если сайт живёт на слабом хостинге без нормальных бэкапов, поможем с переездом в рамках аренды сервера и хостинга. Задать вопросы можно через контакты.
