Резервное копирование сайта: как настроить и что делать, если сайт упал

У 60% сайтов малого и среднего бизнеса, к которым я прихожу на аудит, нет рабочего бэкапа. Есть «встроенный бэкап хостинга», который никто ни разу не восстанавливал, — а в момент, когда он нужен, оказывается, что копия за вчера уже зашифрована вирусом. В этой статье — как настроить бэкапы, чтобы они реально спасали.

Правило 3-2-1: минимум, ниже которого — риск

• 3 копии данных — рабочая + два бэкапа.
• 2 разных носителя — например, диск хостинга + внешнее облако.
• 1 копия вне основной инфраструктуры — другой провайдер или холодное хранилище.

Правило родилось в корпоративном IT, но для сайта смысл тот же: если бэкап живёт на том же сервере, что и сайт, при взломе или падении дата-центра он теряется вместе с сайтом. Хостер-провайдерский бэкап — не полноценная копия, это удобство. Нужна хотя бы одна независимая копия.

Что бэкапить

Куда хранить

• Yandex Object Storage / VK Cloud / Selectel S3 — российские S3-совместимые хранилища, от 1.5 ₽/ГБ/мес. Оптимально для 90% сайтов.
• Отдельный VPS у другого провайдера с rsync по SSH — надёжно, стоит ~300–500 ₽/мес за диск.
• Backblaze B2 / Wasabi — дешёвое зарубежное S3, если санкции не мешают.
• Не храните только на хостинге. Не храните только у одного провайдера. Не храните только в одной стране, если это критично.

Бэкап, который вы ни разу не восстановили, — это не бэкап, а надежда. Раз в квартал разворачивайте копию на тестовый домен. 20 минут работы страхуют бизнес от катастрофы.

Как настроить: типовая схема

• Ежедневный дамп БД (mysqldump или pg_dump) → сжатие gzip → загрузка в S3 через aws-cli / rclone.
• Инкрементальные бэкапы файлов через restic или borg — экономят место в 5–20 раз против полных архивов.
• Cron на сервере в 3–5 утра (низкая нагрузка), уведомление в Telegram при ошибке.
• Автоматическое удаление старых копий: посуточно за 14 дней, понедельно за 60 дней, помесячно за 12 месяцев.
• Шифрование бэкапов на клиенте (restic/borg делают из коробки) — украденная копия бесполезна без ключа.

Сценарий 1: сайт взломали

• Не восстанавливайте вчерашний бэкап вслепую — точка входа могла быть заражена уже неделю. Восстановление без анализа = повторное заражение через сутки.
• Сначала: разверните бэкап на тестовый домен, проведите поиск бэкдоров (AI-Bolit, ImunifyAV), найдите дату первого заражения.
• Затем возьмите бэкап ЗА ДЕНЬ ДО первого заражения, дозалейте на него актуальные данные (заказы, комментарии за последние дни).
• Смените все пароли: админка, FTP/SSH, БД, панель хостинга. Обновите CMS и модули.
• Только после этого возвращайте сайт в бой.

Сценарий 2: неудачное обновление CMS/модуля

• Восстановление файлов последней версии + текущая БД — сайт возвращается за 15–30 минут.
• Если после обновления менялась структура БД (миграции) — откатывайте вместе с БД, иначе несовместимость.
• Правило безопасного обновления: перед любым апдейтом — свежий полный бэкап и dry-run на тестовой копии.

Сценарий 3: упал хостинг или дата-центр

• Разворачиваете сайт из S3-бэкапа на резервный VPS — 1–4 часа при готовой процедуре.
• Меняете DNS A-запись → сайт снова онлайн. TTL DNS держите 300–600 сек, чтобы переключение шло быстро.
• Раз в полгода прогоняйте эту процедуру целиком — иначе в стрессовый момент выяснится, что не работает.

Стоимость: сколько стоит нормальная схема

• S3-хранилище на 50–200 ГБ — 100–400 ₽/мес.
• Настройка автоматизации разово — 10–25 тыс ₽ (скрипты, крон, мониторинг, тестовый прогон восстановления).
• Ежеквартальная проверка восстановления — 3–5 тыс ₽ раз в 3 месяца.
• Полное восстановление после катастрофы «с нуля» без бэкапа — от 80 тыс ₽ и от 2 недель работы, часть данных теряется навсегда.

Мы настраиваем бэкапы под ключ: аудит текущей схемы, скрипты, мониторинг, документация процедуры восстановления, тестовый прогон. Для типового сайта укладываемся в 10–20 тыс ₽ разово плюс ~200 ₽/мес за хранилище. После настройки клиент получает инструкцию на одной странице — что делать в 3 сценариях аварии.