Я Максим — веб-разработчик, и за мою практику было достаточно случаев, когда наличие свежего бэкапа спасало проект за пятнадцать минут. И несколько — когда бэкапа не оказывалось, и последствия были от неприятных до катастрофических. Однажды клиент потерял интернет-магазин с каталогом на 3 000 товаров, потому что хостер «потерял» данные при миграции серверов, а резервных копий не существовало. Восстановление заняло два месяца и стоило в десять раз дороже, чем стоила бы настройка автоматических бэкапов.

В этой статье расскажу, почему сайты ломаются, что именно нужно бэкапить, как часто это делать и как настроить автоматическое резервное копирование, чтобы никогда не оказаться в ситуации «всё пропало».

Почему сайты ломаются: реальные сценарии

Многие владельцы бизнеса думают, что их сайт — стабильная конструкция, которая будет работать вечно, если её не трогать. На практике угроз гораздо больше, чем кажется.

Обновление плагинов или CMS. Классическая ситуация: администратор обновил WordPress или один из плагинов — и сайт упал. Конфликт версий, несовместимость с темой, ошибка в обновлении. Если нет бэкапа — откатить невозможно, и приходится чинить вслепую.

Сбой хостинга. Да, хостинг-провайдеры теряют данные. Диски выходят из строя, RAID-массивы ломаются, при миграции серверов файлы исчезают. Я видел это дважды — и оба раза с достаточно крупными хостерами, которым клиенты доверяли.

Взлом и хакерские атаки. Злоумышленники получили доступ к панели управления, удалили контент, залили вредоносный код, зашифровали файлы. Без чистого бэкапа восстановление превращается в муку: нужно проверять каждый файл, искать заражённые участки кода, чистить базу данных.

Человеческий фактор. Разработчик случайно запустил миграцию на продакшн-базе вместо тестовой. Контент-менеджер удалил не тот раздел. Стажёр нажал «Удалить все» вместо «Удалить выбранные». Человеческие ошибки — самая частая причина потери данных, и защита от них только одна: бэкап.

Вирусы и вымогатели. Программы-шифровальщики, которые блокируют файлы и требуют выкуп, атакуют не только компьютеры — они атакуют и серверы. Если файлы сайта зашифрованы — без бэкапа вариантов нет.

Любая из этих ситуаций решается за 15-30 минут, если есть свежий бэкап. И превращается в проблему на недели (или становится нерешаемой) — если бэкапа нет.

Что именно нужно бэкапить

Сайт — это не один файл. Это набор компонентов, и для полного восстановления нужна копия каждого из них.

Файлы сайта

Весь код (PHP, JavaScript, HTML, CSS или файлы вашего фреймворка), загруженные изображения и документы, шаблоны и темы, конфигурационные файлы (.env, .htaccess, nginx-конфиги). Для сайта на WordPress это папка wp-content целиком плюс wp-config.php. Для сайта на Next.js — весь проект плюс папка public с медиафайлами.

Отдельно обратите внимание на загруженные файлы (изображения товаров, документы, прикреплённые PDF). Они часто занимают основной объём, и именно их сложнее всего восстановить — код можно взять из Git-репозитория, а вот 5 000 фотографий товаров, загруженных вручную за два года, без бэкапа не вернуть.

База данных

В базе данных хранится всё «живое» содержимое сайта: тексты страниц, товары и их описания, заказы, данные клиентов, настройки, комментарии, истории. Для интернет-магазина потеря базы данных — это потеря всей истории продаж, каталога товаров и клиентской базы. Это бэкап номер один по приоритету.

Для MySQL и MariaDB бэкап создаётся через mysqldump. Для PostgreSQL — через pg_dump. Оба инструмента выгружают базу в текстовый файл (SQL-дамп), который можно сжать и сохранить.

Конфигурация сервера

Если вы используете VPS или выделенный сервер — сохраняйте конфигурацию веб-сервера (nginx, Apache), cron-задачи (автоматические задания по расписанию), SSL-сертификаты (хотя их проще перевыпустить, чем восстанавливать), настройки PHP (php.ini) и Docker-конфигурацию (docker-compose.yml, если используете контейнеры).

Потеря конфигурации не так критична, как потеря данных — сервер можно настроить заново. Но если конфигурация была сложной (множество виртуальных хостов, кастомные правила перенаправлений, оптимизированные настройки PHP) — восстановление по памяти займёт часы. Бэкап конфигов экономит это время.

Как часто делать бэкапы

Частота бэкапов зависит от того, как быстро на сайте появляются новые данные. Чем активнее сайт — тем чаще нужно копировать.

Статический сайт-визитка. Контент меняется раз в несколько месяцев. Бэкап раз в неделю — достаточно. Фактически, после каждого обновления контента стоит делать дополнительную копию.

Блог с регулярными публикациями. Новые статьи, комментарии, правки — ежедневный бэкап базы данных обязателен. Файлы можно бэкапить раз в два-три дня, если новые изображения загружаются не каждый день.

Интернет-магазин. Ежедневный бэкап всего (база + файлы). При высокой активности (десятки заказов в час) базу данных стоит бэкапить каждые несколько часов. Потеря данных за целый день — это потеря заказов, которые уже были оплачены, но ещё не отправлены.

Сервис или SaaS-продукт. Непрерывное резервное копирование (continuous backup) или снапшоты каждый час. Для сервисов с пользовательскими данными потеря даже часа — это серьёзный инцидент.

Общее правило: спросите себя — «сколько данных я готов потерять?». Если ответ «ни одного дня» — бэкап нужен ежедневный. Если «ни одного часа» — каждый час. Это называется RPO (Recovery Point Objective) — допустимый объём потери данных.

Где хранить бэкапы

Главное правило, которое я повторяю каждому клиенту: бэкап не должен храниться на том же сервере, где работает сайт. Это правило настолько важно, что стоит его выделить отдельно. Если сервер «умрёт», сгорит диск или хакер зашифрует файлы — бэкап пропадёт вместе с сайтом. Смысл страховки теряется.

Облачное хранилище (S3-совместимое). Мой основной выбор. Yandex Object Storage, Selectel S3, MinIO — все работают по протоколу S3, что позволяет использовать стандартные инструменты для автоматической загрузки. Стоимость хранения — копейки: гигабайт в месяц стоит пару рублей. Надёжность — данные реплицируются между несколькими дата-центрами.

Другой сервер. Если у вас несколько серверов — можно настроить перекрёстное копирование. Бэкап с сервера А отправляется на сервер Б и наоборот. Это работает, но требует двойной оплаты серверов.

Яндекс Диск или Google Drive. Для небольших сайтов подходит. Бэкап можно автоматически загружать через API. Минус — ограниченное пространство и скорость загрузки.

Локальный компьютер. Как дополнительная копия — нормально. Как единственное место хранения — плохо (компьютер тоже может сломаться, и у него нет гарантий аптайма).

Золотое правило — правило 3-2-1: три копии данных, на двух разных типах носителей, одна — вне офиса (в облаке или на удалённом сервере). Для большинства бизнес-сайтов достаточно двух копий: одна на сервере хостинга (автоматический бэкап провайдера), вторая — в облачном хранилище.

Как настроить автоматическое резервное копирование

Бэкапы, которые делаются вручную, рано или поздно перестают делаться. Забыли, не было времени, «потом сделаю». Автоматизация — единственный надёжный вариант.

На шаред-хостинге

Большинство хостинг-провайдеров предлагают автоматические бэкапы из коробки. Но обязательно проверьте детали: как часто делаются копии (ежедневно, еженедельно?), сколько копий хранится (только одна последняя — это мало, нужно минимум 7 дневных), как восстановить (через панель управления, через запрос в поддержку?), входит ли бэкап в тариф или нужно доплачивать.

Не полагайтесь только на бэкапы хостера. Настройте дополнительное копирование в облако — это ваша страховка от ситуации, когда хостер «потеряет» и сайт, и свои бэкапы.

На WordPress

Самый простой способ — плагины. UpdraftPlus — мой фаворит: бесплатная версия умеет делать полные бэкапы (файлы + база) по расписанию и автоматически отправлять в облако (Яндекс Диск, Google Drive, S3). Настраивается за 5-10 минут, работает стабильно.

BackWPup — альтернатива с похожей функциональностью. Хорош для тех, кому нужен экспорт в разных форматах.

На VPS или выделенном сервере

Здесь я обычно пишу bash-скрипт, который делает три вещи: создаёт дамп базы данных (mysqldump), архивирует файлы сайта (tar + gzip), загружает архив в S3-хранилище (через aws-cli или rclone). Скрипт ставится в cron на нужное расписание — и работает автоматически каждый день.

Для проектов на Docker я бэкаплю volumes контейнеров и отдельно — дамп базы из контейнера с MySQL или PostgreSQL. Docker-compose файл и .env отдельно сохраняются в Git-репозиторий — это уже версионированная копия.

Для проектов с Git

Код сайта, который хранится в Git-репозитории (GitHub, GitLab, Bitbucket) — уже защищён. Каждый коммит — это точка восстановления. Но Git не защищает базу данных и загруженные файлы (медиа) — их нужно бэкапить отдельно.

Сколько копий хранить и как долго

Я рекомендую следующую схему ротации бэкапов:

Ежедневные бэкапы — хранить 7-14 последних. Этого достаточно, чтобы откатиться на любой день за последние одну-две недели.

Еженедельные бэкапы — хранить 4 последних. Для случаев, когда проблема обнаружилась не сразу (например, вирус внедрился давно, но заметили только через неделю).

Ежемесячные бэкапы — хранить 3-6 последних. Для совсем запущенных случаев и для соответствия требованиям хранения данных.

Такая схема занимает разумный объём хранилища и покрывает подавляющее большинство сценариев восстановления.

Проверяйте бэкапы: бэкап Шрёдингера

Вот ключевая мысль, которую я стараюсь донести до каждого клиента: бэкап, который невозможно восстановить, — бесполезен. Пока вы не проверили, что копия рабочая — вы не знаете, есть ли у вас бэкап вообще. Я называю это «бэкап Шрёдингера»: он одновременно и есть, и нет, пока не откроешь коробку.

Раз в месяц (а для критичных сайтов — раз в неделю) проделайте следующее: скачайте последний бэкап, разверните его на тестовом окружении (локальном компьютере, тестовом сервере или Docker-контейнере), убедитесь, что сайт открывается и работает, проверьте, что данные актуальные (последние заказы, свежие статьи).

Если что-то не так — у вас есть время исправить проблему, пока оригинал ещё жив. Если проверка проходит успешно — вы спокойны.

Документируйте процедуру восстановления

Бэкап — это только половина дела. Вторая половина — процедура восстановления. Когда случился инцидент — не время разбираться, как восстановить сайт из архива. Всё должно быть задокументировано заранее: где лежат бэкапы (ссылки, доступы), как развернуть бэкап пошагово, какие учётные данные нужны (доступ к хостингу, SSH-ключи, пароли от баз данных), кто ответственный за восстановление.

Я оставляю каждому клиенту документ «Процедура восстановления из бэкапа» — две-три страницы с пошаговой инструкцией. Это позволяет восстановить сайт даже тому, кто не участвовал в его создании.

Итоги

Бэкапы — это страховка. Они не нужны до тех пор, пока не станут жизненно необходимы. А когда станут — каждая минута без рабочей копии будет стоить денег, нервов и репутации.

Настройте автоматическое резервное копирование сегодня. Проверьте, что копии работают. Задокументируйте процедуру восстановления. И забудьте об этом — пусть бэкапы тихо делаются в фоне, а вы занимаетесь развитием бизнеса.

Если нужна помощь с настройкой резервного копирования для вашего сайта — обращайтесь. Настрою автоматические бэкапы, проверю восстановление и оставлю документацию.