Резервное копирование сайта — это страховка от неприятных сценариев: неудачное обновление, сбой хостинга, удаление файлов, взлом или человеческая ошибка. Проблема в том, что «бэкапы есть» не всегда означает «сайт можно восстановить». Разберём, как настроить копирование так, чтобы оно реально спасало.
Что нужно копировать в первую очередь
Для полноценного восстановления обычно нужны две части: файлы сайта и база данных. Если копировать только одну часть, восстановление может быть неполным или бесполезным.
| Что копируем | Почему важно |
|---|---|
| Файлы сайта | Шаблоны, изображения, документы, загруженные файлы, скрипты, настройки проекта. |
| База данных | Контент, пользователи, заявки, настройки CMS и модулей, структура разделов. |
| Конфиги окружения | Параметры подключения, cron-задачи, настройки веб-сервера и интеграций. |
Если сайт на CMS (в том числе 1С-Битрикс), не полагайтесь только на «автобэкап хостинга». Лучше иметь свою управляемую схему и понимать, где лежат копии.
Где хранить резервные копии
Главный принцип: копии должны быть не только на том же сервере, где работает сайт. Если «упадёт» сервер, диск или аккаунт хостинга, вы потеряете и сайт, и бэкапы сразу.
Базовая практика — правило 3-2-1:
- 3 копии данных (основные данные + минимум 2 резервные)
- 2 разных носителя/хранилища (например, сервер + облако)
- 1 копия вне основной площадки (offsite)
Для сайтов бизнеса обычно хватает схемы: локальный бэкап на сервере + ежедневная выгрузка в облачное хранилище. Если проект критичный, добавляют третье хранилище и более строгий регламент.
Как часто делать бэкапы
Частота зависит от того, как часто меняются данные. Если заявки и заказы идут каждый день, недельной копии мало.
| Тип сайта | Рекомендуемая частота |
|---|---|
| Лендинг/визитка (редкие изменения) | 1–2 раза в неделю + копия перед любыми изменениями |
| Корпоративный сайт с формами | Ежедневно (ночью) + отдельная копия перед обновлениями |
| Интернет-магазин/активный сервис | Ежедневно файлы + частые дампы БД (несколько раз в день) |
Частые ошибки, из-за которых бэкап не спасает
- Копии на том же сервере. Упал сервер — копий нет.
- Нет проверки восстановления. Архив есть, но распаковать нельзя или база не поднимается.
- Один и тот же архив перезаписывается. Ошибка попала в копию, откатиться некуда.
- Не копируются пользовательские загрузки. После восстановления сайт «без картинок» и документов.
- Нет копии перед обновлением. Неудачное обновление — и сложный ручной откат.
Чтобы не попасть в эти сценарии, полезно держать простой регламент: кто отвечает, куда складываются копии, как часто проверяется восстановление.
Проверка восстановления: обязательный этап
Минимум раз в полгода восстановите сайт из бэкапа на тестовый поддомен. Это не «паранойя», а рабочая проверка, что процесс действительно пригоден в аварии.
- Разворачиваете файлы и базу на тестовом окружении
- Проверяете открытие ключевых страниц
- Проверяете формы и отправку заявок
- Проверяете авторизацию и админку
- Фиксируете время восстановления (RTO) и объём потери данных (RPO)
Если восстановление заняло «весь день и нервы», регламент нужно улучшать, а не надеяться, что «в следующий раз будет проще».
Бэкапы и безопасность
Резервные копии тоже содержат персональные данные, поэтому их нельзя хранить «как попало». Ограничьте доступы, используйте шифрование архивов и не выкладывайте копии в публичные директории. В сочетании с базовыми мерами из статьи про безопасность сайта это значительно снижает риски.
Для сайтов на Битрикс стоит привязать бэкапы к графику обновлений: перед каждым обновлением ядра и модулей делайте отдельную копию. Это особенно важно, если у вас активная техподдержка Битрикс и обновления ставятся регулярно.
Что может контролировать владелец без техподготовки
- Есть ли понятный график бэкапов и ответственное лицо
- Где хранятся копии и есть ли «внешнее» хранилище
- Была ли проверка восстановления за последние 6–12 месяцев
- Есть ли отдельная копия перед крупными изменениями и обновлениями
- Как быстро можно восстановить сайт в случае сбоя
Этого уже достаточно, чтобы не жить в иллюзии «всё под контролем», а реально понимать уровень риска.
Когда обращаться к специалистам
Если проект важен для продаж или лидов, настройку бэкапов лучше сделать один раз правильно: с автоматизацией, проверкой восстановления и регламентом. Специалисты ADES помогают выстроить такую схему в рамках сопровождения сайта: резервное копирование, мониторинг и безопасные обновления.
Часто задаваемые вопросы
Достаточно ли копий, которые делает хостинг?
Это хороший базовый уровень, но лучше иметь собственную независимую копию. Тогда вы не зависите полностью от одного провайдера и его политики хранения.
Нужно ли делать бэкап перед маленькой правкой?
Перед правкой текста — обычно нет. Перед обновлением CMS, модулей, изменением кода, миграцией или работой с базой — обязательно да.
Сколько хранить резервные копии?
Зависит от проекта, но практичный минимум: ежедневные копии за 7–14 дней, недельные за 1–2 месяца и месячные за 3–6 месяцев. Это помогает откатиться к «чистой» версии, если проблема обнаружилась не сразу.
Что важнее: частота или проверка восстановления?
Важны оба пункта. Частые копии уменьшают потерю данных, а проверка восстановления подтверждает, что копии вообще рабочие. Без проверки даже «ежечасные бэкапы» могут оказаться бесполезными.
Читайте также
- Чек-лист: что проверить на сайте в начале года — пункт про бэкапы и тест восстановления
- Зачем нужен SSL-сертификат — безопасность передачи данных
- Как обновить Битрикс: по шагам — обновления только после резервной копии