Бэкап сайта настройка - не разовая задача "поставил галочку у хостера и забыл". Это система из частоты, типов копий, хранения и проверки восстановления. По данным IBM Cost of a Data Breach 2024, средние потери компании от инцидента с данными - 4,88 млн долларов. Малый и средний бизнес теряет меньше в абсолютных цифрах, но 60% компаний без отлаженного бэкапа закрываются за 6 месяцев после катастрофической потери данных.
Гайд собран по опыту 550+ проектов веб-студии Сайты2.рф из Кронштадта (СПб). С 2008 года мы настраивали бэкапы для лендингов на Tilda, корпоративных сайтов на 1С-Битрикс, интернет-магазинов с базой 50+ ГБ и B2B-порталов на Laravel. Внутри: зачем нужны бэкапы, 3 типа резервного копирования, что обязательно бэкапить, правило 3-2-1, 5 способов настройки, частота для разных типов сайтов, проверка восстановления и чек-лист на 12 пунктов.
Зачем нужны бэкапы
Бэкап сайта настройка нужна для 6 базовых сценариев восстановления. Все 6 случаются регулярно у клиентов студии.
Хакерская атака. В 2024 году количество атак на сайты в РФ выросло на 47%. После взлома сайт зашифрован, заражён майнером, превращён в дорвей. Без бэкапа - месяцы восстановления.
Ошибка администратора. Удаление таблицы базы данных, очистка папки uploads, неудачное обновление CMS. Один клик в админ-панели стоит миллиона рублей выручки магазина. По нашей статистике, 38% обращений по восстановлению связаны не с атаками, а с человеческими ошибками.
Сбой хостинга. Серверы тоже падают: повреждение диска, ошибки RAID, сбои файловой системы. Большие провайдеры держат SLA 99,9%, но это 8,76 часа простоя в год. У небольших хостеров аптайм ниже.
Неудачное обновление CMS. Обновление Битрикса, WordPress или Laravel конфликтует с кастомными модулями. Без бэкапа откат невозможен. Подробнее про безопасные обновления - в статье об обновлении CMS без падения.
Конфликт с подрядчиком. Бывший разработчик "забывает" передать доступы, удаляет данные, шантажирует возвратом. С полным архивом проблема решается за час: разворачиваем копию у нового подрядчика.
Юридические претензии. Иногда нужно показать состояние сайта на конкретную дату (споры о публикациях, защита репутации). Архив бэкапов - доказательная база.
3 типа резервного копирования
Технически бэкапы делятся на 3 типа. Разница экономит место и ресурсы.
Полный бэкап (Full backup)
Копируются все данные сайта целиком: файлы, база, конфиги. Преимущество - простое и быстрое восстановление в один шаг. Недостаток - занимает много места и долго делается.
Пример: интернет-магазин на 8 ГБ файлов и 2 ГБ базы. Полный бэкап весит 10 ГБ, делается 12-18 минут на VPS Selectel.
Инкрементальный бэкап (Incremental backup)
После первого полного бэкапа копируются только файлы, изменённые с момента последней любой копии. Преимущество - быстро и экономно по месту. Недостаток - восстановление сложнее: нужен полный бэкап + все инкрементальные копии до нужной даты.
Пример: первый полный бэкап 10 ГБ, ежедневный инкрементальный 200-500 МБ. Цепочка из 30 копий весит 16-25 ГБ против 300 ГБ при ежедневном полном.
Дифференциальный бэкап (Differential backup)
После первого полного бэкапа копируются все файлы, изменённые с момента последнего полного. Преимущество - восстановление в 2 шага: полный + последний дифференциальный. Недостаток - размер копий растёт со временем.
Пример: первый полный 10 ГБ, дифференциальный в день 1 - 200 МБ, в день 7 - 1,4 ГБ, в день 30 - 6 ГБ. Удобный компромисс между полным и инкрементальным подходом.
Для большинства сайтов мы используем гибрид: один полный бэкап в неделю + ежедневный инкрементальный.
Что обязательно бэкапить
Многие хостеры предлагают "бэкап сайта" по умолчанию, но копируют только файлы. Полноценная копия включает 6 типов данных.
Файлы сайта. Корневая папка с CMS, шаблонами, медиафайлами в uploads, документами клиентов. Минимум - папки, куда пишут пользователи и где живут админские настройки.
База данных. SQL-дамп всей БД. Для MySQL/MariaDB - через mysqldump, для PostgreSQL - через pg_dump. На больших базах используется логическая выгрузка + бинарный лог транзакций.
Конфигурационные файлы. php.ini, my.cnf, nginx.conf, robots.txt, .htaccess, .env с переменными окружения. Без конфигов восстановленный сайт не запустится.
SSL-сертификаты и приватные ключи. Особенно для платных сертификатов и доменов с настроенным CAA. Подробнее про SSL - в гайде по SSL-сертификату для сайта.
Cron-задачи и системные сервисы. Список задач планировщика, конфиги supervisor для очередей, systemd-юниты. Без них сайт работает на вид нормально, но фоновые процессы (отправка email, синхронизация с 1С) не идут.
Конфигурация CDN и DNS. Записи DNS-зоны, настройки Cloudflare/CDN, правила кэширования. Если домен переходит на новый хостинг, эти настройки тоже надо восстанавливать.
Для проектов на 1С-Битрикс отдельный пункт - папка /bitrix/modules/ с лицензионным файлом. Без него Битрикс блокирует доступ в админ-панель после восстановления.
Правило 3-2-1
Правило для бэкапов формулируется так: 3 копии данных на 2 разных носителях, минимум 1 - вне основной площадки.
3 копии
Помимо боевого сайта - минимум 2 резервные копии. Одна копия = плохо, повредится - восстанавливать нечего. Две копии = адекватный минимум.
2 разных носителя
Не все 3 копии лежат на одном сервере или в одном дата-центре. Если ЦОД пострадал, единая копия пропадает целиком. Варианты разнесения:
- VPS + объектное хранилище S3
- Сервер хостинга + локальный диск в офисе клиента
- Облако Selectel + Yandex Object Storage в другом регионе
1 копия вне площадки
Минимум 1 копия физически вне основного хостинга. Идеально - в другом городе или регионе. Защита от катастроф уровня "горит дата-центр" или "хостер обанкротился и заблокировал доступ".
Правило 3-2-1 разработано NIST (Национальный институт стандартов США) и считается базой защиты от потери данных. Современные обновления добавляют "3-2-1-1-0": плюс одна копия в режиме immutable (запрет на изменение) и ноль ошибок при проверке восстановления.
5 способов настройки бэкапа
В студии за 12 лет использовали все 5 подходов. Выбор зависит от типа сайта, бюджета и доступа к серверу.
Способ 1. Встроенный бэкап хостинга
Бесплатно для shared, опция для VPS. Beget, Timeweb, REG.RU, Selectel, Yandex Cloud делают ежедневный бэкап сайта и БД с хранением 7-30 дней. Подходит для лендингов, визиток, небольших корпоративных сайтов.
Минус - бэкапы лежат у того же провайдера. При проблемах хостинга пропадают вместе с боевым сайтом. Базовый уровень, но недостаточный для коммерческих проектов.
Способ 2. Скрипт на сервере (bash, cron)
Для VPS пишется bash-скрипт с rsync + mysqldump + загрузкой на удалённое хранилище. Запускается по cron в нужное время. Гибкий, прозрачный, бесплатный (кроме стоимости хранилища).
Пример настройки занимает 30-60 минут для опытного админа. Требует знаний Linux, умения работать с rsync, тестирования. Подходит для технически подкованных команд.
Способ 3. Плагины и модули CMS
Готовые решения для популярных CMS:
- WordPress: UpdraftPlus, BackWPup, Duplicator
- 1С-Битрикс: встроенный модуль "Резервная копия" + платный модуль "BackUp PRO"
- Tilda: автоматический бэкап от платформы (без настройки)
- Drupal: Backup and Migrate
Плюс - настраивается из админки без работы с сервером. UpdraftPlus пишет в S3, Dropbox, Google Drive из коробки. Минусы - меньше контроля, зависимость от стабильности плагина, не работает для нестандартных PHP-проектов.
Способ 4. Внешние сервисы бэкапа
Платные сервисы с веб-интерфейсом и поддержкой:
- CodeGuard - 5-30$ в месяц, бэкап + защита от потери данных
- VaultPress (Jetpack Backup) - 5-50$ в месяц, родной для WordPress
- Acronis Cyber Backup - корпоративный уровень, от 60$ в месяц
- iDrive Backup - облачные бэкапы, 4-100$ в месяц
Плюс - готовое решение с поддержкой, шифрованием, версионированием. Минус - стоимость в долларах и проблемы с оплатой из РФ в 2026 году. Из российских альтернатив - сервис от Yandex Cloud (Backup) и Selectel Backup.
Способ 5. Ручной бэкап
Раз в месяц админ скачивает архив сайта и SQL-дамп через FTP/панель управления, хранит на своём диске или в облаке. Подходит как дополнение к автоматизированному бэкапу, не как основное решение.
В студии используется как обязательная мера перед крупными обновлениями: вручную делается полный снимок состояния, чтобы откатить в любой момент.
Частота бэкапа для разных типов сайтов
Универсальной частоты нет - всё зависит от того, как часто меняются данные на сайте.
| Тип сайта | Полный бэкап | Инкрементальный | Хранение |
|---|---|---|---|
| Лендинг или визитка | 1 раз в неделю | Не нужен | 4 недели |
| Корпоративный сайт | 1 раз в неделю | Ежедневно | 8 недель |
| Корпоративный блог | 1 раз в неделю | Ежедневно | 12 недель |
| Интернет-магазин до 1000 SKU | 1 раз в 3 дня | Каждые 6 часов | 12 недель |
| Интернет-магазин 1000+ SKU | Ежедневно | Каждый час | 16 недель |
| B2B-портал с заказами | Ежедневно | Каждый час | 26 недель |
| Высоконагруженный проект | Ежедневно | Real-time репликация | 26+ недель |
Принцип: частота бэкапа определяется допустимой потерей данных (RPO, Recovery Point Objective). Если магазин теряет 100 заказов в час и не может позволить себе больше 1 часа потерь - нужен бэкап каждый час.
Подробнее про оптимизацию работы магазинов в гайде по SEO для интернет-магазина.
Где хранить бэкапы
Хранение бэкапов на том же сервере, где работает сайт - распространённая ошибка. Падает сервер - падает и бэкап. Правильные варианты хранения.
Объектное хранилище S3-совместимое
Российские провайдеры: Selectel Object Storage, Yandex Object Storage, VK Cloud Storage. Зарубежные: Amazon S3, Backblaze B2. Стоимость - 1-3 рубля за ГБ в месяц. Доступ через API из любого скрипта.
Плюс - географическая удалённость от основного сервера, шифрование на стороне провайдера, контроль версий. Минус - требует настройки доступа и ключей API.
Отдельный VPS под бэкап
Дешёвый VPS на 80-100 ГБ диска у другого хостера. Бэкап через rsync по SSH. Полный контроль, цена - от 200 рублей в месяц. Подходит для проектов средней сложности.
Подробнее про выбор хостинга - в гайде по российским хостингам и статье как выбрать хостинг.
Локальное хранилище
Бэкап скачивается на компьютер админа или сервер в офисе клиента. Подходит как дополнение к облачному. Защищает в ситуации "интернет лежит, надо поднимать сайт".
Чего не делать
- Хранить бэкапы на том же VPS, где работает сайт
- Полагаться только на бэкапы хостинга
- Не шифровать бэкапы с персональными данными (нарушение 152-ФЗ)
- Хранить только последнюю копию (если она повреждена - восстановления нет)
Подробнее про 152-ФЗ - в чек-листе соответствия 152-ФЗ.
Проверка восстановления
Бэкап без проверки восстановления - иллюзия защиты. По исследованию Veeam 2024, 38% компаний обнаруживают непригодность бэкапов только в момент аварии.
Что проверять
- Файлы развёртываются без ошибок
- База данных восстанавливается и не повреждена
- Сайт запускается на тестовом домене
- Авторизация работает, пользователи существуют
- Заказы и платежи доступны без потерь
Регламент проверки
Минимум раз в квартал для коммерческих проектов:
- Развернуть свежий полный бэкап на тестовом сервере
- Проверить структуру БД через стандартные запросы
- Пройти 5-10 пользовательских сценариев (вход, заказ, оплата, поиск)
- Зафиксировать время полного восстановления (для расчёта RTO)
- Записать инцидент в журнал
В студии для клиентов на абонентской поддержке проверка восстановления проходит ежемесячно по графику. Подробнее про условия - на странице технической поддержки.
Метрики восстановления
- RPO (Recovery Point Objective) - максимальная допустимая потеря данных в часах. Для магазина с заказами целевой RPO - 1 час, для блога - 24 часа.
- RTO (Recovery Time Objective) - максимальное время на восстановление. Целевой RTO для корпоративного сайта - 2-4 часа, для магазина - 1-2 часа, для B2B-портала - 30-60 минут.
Чек-лист на 12 пунктов
12 параметров проверяем перед сдачей системы бэкапа клиенту.
- [ ] Полный бэкап настроен с нужной частотой (от еженедельно до ежедневно)
- [ ] Инкрементальный или дифференциальный бэкап делается между полными
- [ ] Бэкап включает файлы, базу, конфиги, SSL-сертификаты, cron
- [ ] Минимум 2 копии хранятся вне основного сервера
- [ ] Одна копия в другом географическом регионе или в другом ЦОД
- [ ] Бэкапы шифруются (особенно с персональными данными)
- [ ] Срок хранения соответствует типу сайта (от 4 до 26 недель)
- [ ] Уведомления об успехе/ошибке бэкапа приходят на email или в Telegram
- [ ] Регламент проверки восстановления зафиксирован (минимум раз в квартал)
- [ ] Проведена тестовая проверка восстановления с фиксацией RTO
- [ ] Доступ к бэкапам ограничен (не все админы имеют права удаления)
- [ ] Документация по восстановлению описана и доступна резервному админу
Если все 12 пунктов закрыты, бэкап сайта настройка соответствует уровню коммерческой надёжности. Если возникают вопросы - студия Сайты2.рф из Кронштадта (СПб) берёт настройку и аудит системы бэкапа в рамках технической поддержки.
FAQ
Зачем делать бэкап, если хостер уже его делает?
Хостинговый бэкап - базовая защита, не полная. Бэкапы хранятся у того же провайдера, не подходят для строгих SLA, пропадают при проблемах с хостером. Для коммерческих проектов нужна отдельная схема: правило 3-2-1, минимум одна копия вне основного хостинга, регулярная проверка восстановления.
Сколько места нужно для хранения бэкапов сайта?
Зависит от размера сайта и частоты бэкапа. Лендинг до 500 МБ при еженедельном полном бэкапе за 12 недель - 6 ГБ. Корпоративный сайт 2 ГБ с ежедневным инкрементальным - 30-50 ГБ. Интернет-магазин 15 ГБ с ежедневным полным + инкрементальным - 200-400 ГБ. Расчёт делается под конкретный проект.
Сколько стоит настройка бэкапа сайта?
Базовая настройка для лендинга или корпоративного сайта - от 8 000 ₽, срок 1-2 дня. Настройка для интернет-магазина с правилом 3-2-1, шифрованием и регламентом проверки - от 25 000 ₽, срок 3-5 дней. Настройка под B2B-портал с RPO до 1 часа и RTO до 30 минут - от 60 000 ₽, срок 7-14 дней. В рамках абонентской поддержки контроль работы бэкапа включён в пакет.
Можно ли восстановить сайт без бэкапа после взлома?
Иногда да, но дорого и не всегда полно. Архив страниц частично восстанавливается через web.archive.org (Wayback Machine) и кэш Яндекса/Google. База данных без бэкапа - только если хостер делал свои копии. Стоимость аварийного восстановления без бэкапа - от 50 000 до 500 000 ₽ в зависимости от ущерба, результат не гарантирован.
Бэкапы и 152-ФЗ - что нужно учитывать?
Бэкапы с персональными данными граждан РФ хранятся на серверах в России. Требование статьи 18 152-ФЗ. Шифрование бэкапов обязательно при выгрузке на S3. Доступ к бэкапам логируется и контролируется. Подробнее - в чек-листе соответствия 152-ФЗ.
Что делать с бэкапами при переезде на новый хостинг?
Перед переездом делается полный свежий бэкап на текущем хостинге. После переезда копируется и проверяется на новой площадке. Старые бэкапы хранятся ещё минимум 90 дней на случай отката. Сама схема бэкапа настраивается заново под новый хостинг. Подробный план переезда - в гайде по миграции хостинга.
Что в итоге
Бэкап сайта настройка - система из 4 элементов: правильный тип копии (полный + инкрементальный), полнота охвата (файлы, БД, конфиги, SSL, cron), удалённое хранение по правилу 3-2-1 и регулярная проверка восстановления. Без любого из элементов схема даёт ложное чувство защищённости и не работает в момент аварии.
Если нужно настроить бэкап с нуля, провести аудит существующей схемы или перевести проект на надёжную систему резервного копирования - студия Сайты2.рф в Кронштадте (СПб) делает это под ключ. Звоните +7 (812) 942-47-44 или пишите в контакты. Рассчитаем стоимость за 1 рабочий день, базовая настройка занимает от 1 до 5 рабочих дней. С 2008 года настроили бэкапы более чем для 380 сайтов клиентов из Санкт-Петербурга, Кронштадта, Гатчины, Тосно и Выборга.
