Сайт — это актив, который нередко стоит дороже офиса и оборудования вместе взятых: в нём база клиентов, заказы, контент, интеграции с CRM и 1С. При этом о существовании бэкапов многие владельцы бизнеса вспоминают только после того, как сайт исчез — из-за взлома, сбоя диска на хостинге или ошибки разработчика при обновлении. Восстановить данные без резервных копий либо невозможно, либо стоит в десятки раз дороже, чем их регулярное создание. В этой статье разбираем, как настроить бэкапы сайта и базы данных так, чтобы любой сбой превращался в часовую неприятность, а не в катастрофу.
Что именно копировать: не только файлы
Самая частая ошибка — бэкапить только файлы сайта. На деле полный резерв включает несколько частей:- Файлы сайта — код, шаблоны, плагины, загруженные изображения и документы;
- Базу данных — товары, заказы, статьи, учётные записи клиентов. В WordPress, 1С-Битрикс, OpenCart и большинстве других CMS весь контент и заказы живут именно в базе, а не в файлах;
- Конфигурации — cron-задачи, настройки веб-сервера, ключи интеграций с CRM, платёжными системами и 1С;
- SSL-сертификаты и настройки почты, если они управляются вручную.
Правило 3-2-1: стандарт, который спасает
В ИТ-среде есть проверенная формула надёжного резервирования — 3-2-1. Она означает: три копии данных, на двух разных типах носителей, одна из которых хранится вне сервера сайта — в другом дата-центре или облаке. Почему это критично: при взломе или заражении вирусом-шифровальщиком злоумышленник получает доступ ко всему, что лежит на том же сервере или под тем же аккаунтом, — включая бэкапы. Поэтому минимум одна копия должна быть недоступна из админки сайта: в облачном хранилище с отдельным доступом, с включённой защитой от удаления (versioning или lock-режим). Это правило кажется избыточным ровно до первого инцидента.Как часто делать бэкапы: ориентир — объём потерь
Главный вопрос звучит не «как часто_backupить», а «сколько данных вы готовы потерять». Если интернет-магазин делает 50 заказов в день, а копия создаётся раз в сутки ночью, в худшем случае вы теряете день продаж и все заказы за него. Практические ориентиры: для магазина или портала с заказами базу данных стоит копировать каждые 1–6 часов, файлы — раз в сутки; для корпоративного сайта или блога с регулярными публикациями достаточно ежедневного бэкапа; для лендинга — копия после каждого изменения. И отдельно: перед любым обновлением CMS, переездом на другой хостинг или правками от разработчика обязателен ручной контрольный бэкап — большинство инцидентов происходит именно в момент изменений.Где хранить: не на том же сервере
Бэкап, лежащий рядом с сайтом на том же диске, защищает только от ошибок разработчика, но не от сгоревшего сервера или взлома. Оптимальное хранилище — облачное объектное хранилище. Цена вопроса — примерно 1–3 ₽ за гигабайт в месяц: даже «тяжёлый» сайт на 10 ГБ обойдётся в 10–30 ₽ ежемесячно, дешевле чашки кофе. Включите в хранилище версионность и настройте политику хранения: обычно держат 7–14 ежедневных копий плюс несколько месячных архивов. Месячные копии — страховка от коварного сценария, когда проблема (взлом, битая база) обнаруживается не сразу, а через две-три недели, и свежие бэкапы уже перезаписаны испорченными данными.Как автоматизировать: 4 рабочих способа
Ручные бэкапы «по памяти» работают ровно до первого отпуска и первого аврала. Настраивайте автоматизацию одним из способов:- Средства хостинга. В панелях ISPmanager, cPanel, Plesk и на большинстве тарифов виртуального хостинга резервное копирование по расписанию уже встроено. Проверьте, включено ли оно у вас, куда сохраняются копии и как их восстановить.
- Встроенные инструменты CMS. Настройте выгрузку копий в облако, а не в папку на том же хостинге.
- Скрипты по расписанию. Универсальный путь для VPS: cron-задача, которая делает дамп базы через mysqldump и синхронизирует файлы через rsync или rclone в облачное хранилище.
- Договор со студией на сопровождение. В поддержку сайта стоит включить настройку и регулярную проверку бэкапов — это в разы дешевле восстановления после сбоя.
Бэкап без проверки восстановления — это не бэкап
Худший момент, чтобы узнать, что бэкап не работает, — когда он понадобился. Реальные кейсы: дамп базы оказался битым, в копии нет паролей доступа, версия PHP на новом сервере несовместима со старым кодом. Поэтому минимум раз в квартал проводите тестовое восстановление на тестовой площадке: разверните копию, проверьте, что открываются страницы, работают заказы и интеграции. Заодно измерьте два показателя: RTO — сколько времени займёт полное восстановление сайта, и RPO — максимум данных, которые вы потеряете при сбое. Если RTO измеряется сутками, а RPO — неделей, значит, схема бэкапов настроена формально.Кому можно трогать бэкапы: безопасность доступа
Резервные копии — это полная копия бизнеса, и доступ к ним должен быть ограничен так же строго, как доступ к банку. Дайте доступ к хранилищу двум-трём ключевым людям, включите двухфакторную аутентификацию, не храните пароли в общих документах и чатах. Когда разработчик или сотрудник уходит из проекта, его доступы к бэкапам отзываются в тот же день. И ещё один уровень защиты: хотя бы одна копия должна храниться в режиме «только запись» или офлайн — это единственная страховка, которая сработает, если злоумышленник доберётся до админок и начнёт удалять всё подряд, включая резервные копии.Чек-лист: проверьте свой сайт сегодня
Пройдитесь по списку и честно ответьте на каждый пункт:- бэкапы создаются автоматически, а не руками «когда вспомним»;
- копии хранятся вне сервера сайта — в облаке или другом дата-центре;
- в копию входит не только код, но и база данных с заказами;
- хранится минимум 7–14 ежедневных копий и 2–3 месячных архива;
- восстановление хотя бы раз тестировалось, и вы знаете его сроки;
- доступ к хранилищу есть у 2–3 человек, у бывших подрядчиков доступ отозван;
- перед каждым обновлением и правками делается контрольный бэкап.
Резервное копирование — самая дешёвая страховка в digital: настройка занимает несколько часов, хранение — от пары сотен рублей в месяц, а потеря сайта без копий измеряется сотнями тысяч — недополученной выручкой, утраченной базой клиентов и работой «с нуля». Начните с простого шага: попросите вашего разработчика или хостинг-провайдера показать, где лежат копии, когда создавалась последняя и за сколько времени восстановится сайт. Если внятного ответа нет — не откладывайте: настройте бэкапы по правилам 3-2-1 на этой неделе, а не после первого сбоя. Наша студия подключается к проектам на сопровождение и берёт резервирование, мониторинг и восстановление на себя — обращайтесь, чтобы закрыть этот риск раз и навсегда.