Слово «бэкап» знакомо всем, но проверяют его единицы. Пока копии нужны «на всякий случай», они выглядят как страховка. В момент аварии выясняется, что архив битый, лежит на том же диске или содержит базу недельной давности без файлов.
Ниже — три собирательные истории, которые повторяются с завидной регулярностью, и правила, которые закрывают каждую из них. Истории не про «плохих админов»: в каждой сработала логика «мы же настроили», просто её никто не проверил.
Что обычно думают про резервное копирование
| Ожидание | Реальность |
|---|---|
| «Хостинг делает бэкапы — этого хватит» | Копии есть, но восстановить можно только целиком сайт на момент суток назад, а точечно — нет |
| «Плагин настроен, значит копии делаются» | Задача падает по таймауту на большом сайте, письма об ошибке уходят в спам |
| «Копия лежит на сервере, всё под рукой» | При отказе диска или шифровальщике пропадают и сайт, и копии |
| «Файлы бэкапятся, база тоже» | Между ними нет согласованности: база от 10:00, файлы от 22:00 |
Разница между «бэкап настроен» и «бэкап работает» — ровно одна процедура: тестовое восстановление. Всё остальное — вопрос удачи.
История первая: копии были, но битые
Интернет-магазин на WordPress, 400 товаров, плагин копирования с настройкой «ежедневно, хранить 14 дней». Через восемь месяцев после переезда на новый сервер сайт упал: обновление плагина несовместимо с версией PHP.
Восстановление показало, что все 14 последних архивов весят одинаково — 12 МБ. Для сайта с базой на 80 МБ это невозможно. Задача падала на этапе архивации базы, но плагин писал в лог «готово» и удалял старые копии. Последний рабочий архив был трёхмесячной давности, без заказов за этот период.
- Что подвело: никто не смотрел на размер и содержимое копий, а сообщения об ошибках не читались.
- Что спасло бы: проверка размера и распаковка одного архива раз в месяц; уведомление при отклонении размера от среднего.
- Стоимость: двое суток ручной сверки заказов и восстановление части данных из писем и CRM.
Правило: непроверенная копия — это не копия. Пока вы хотя бы раз не развернули архив в отдельный каталог и не открыли сайт, вы не знаете, что внутри.
История вторая: копия лежала рядом с оригиналом
Сайт услуг, VPS с двумя сайтами. Копирование настроено качественно: ежедневно, база и файлы, хранение 30 дней. Единственная деталь — каталог `/backup` находился на том же диске, что и сайты.
Диск умер ночью. Хостинг поднял сервер на новом железе, но вместе с отказавшим диском исчезли и копии. Уцелела одна недельная копия, которую администратор когда-то скачал себе на ноутбук, чтобы «посмотреть, как выглядит архив».
- Что подвело: физическая близость копии к источнику. Один отказ — минус и сайт, и страховка.
- Что спасло бы: выгрузка в отдельное хранилище (другой сервер, объектное хранилище, облако) — автоматически, а не «иногда».
- Стоимость: два дня восстановления по частям и потеря заявок за неделю.
Тут же вторая версия этой истории: шифровальщик. Он шифрует всё, до чего дотянется, включая смонтированные каталоги и сетевые диски. Копия на том же сервере с теми же правами шифруется вместе с сайтом — и восстановить нечего.
История третья: восстановили, но не то
Корпоративный портал на Битрикс24 (коробка). Инцидент: сотрудник удалил раздел с документами и настройки прав. Копии делались штатным скриптом: дамп базы ежедневно в 3:00, файлы — раз в неделю.
Базу восстановили за час, но фотографии и файлы, загруженные за последние шесть дней, остались только в старой копии — их отсутствие выяснилось уже после запуска, когда пользователи начали жаловаться на битые вложения. Пришлось останавливать портал повторно и восстанавливать файлы из недельного архива, а документы за эту неделю — искать по почте.
- Что подвело: разные расписания для базы и файлов. Согласованности между ними не было ни на минуту.
- Что спасло бы: единый цикл «база + uploads» с одинаковой точкой отсечения и отдельная проверка, что вложение открывается после восстановления.
- Стоимость: два простоя по несколько часов и ручной сбор документов.
Бэкап проверяется не фактом создания файла, а открытием сайта из этого файла. Всё остальное — вера.
Правило 3-2-1 и что считать настоящей копией
Классическая формула резервного копирования: три копии данных, две разные среды хранения, одна — вне основного места. Для малого бизнеса она переводится так:
- 1. Сайт и база на сервере.
- 2. Ежедневная копия в другом месте (объектное хранилище, второй сервер, облачный бакет).
- 3. Раз в неделю или месяц — холодная копия, которую нельзя удалить с сервера (архив в отдельном кабинете, скачанный на локальный диск).
Три критерия, по которым копию можно считать настоящей:
| Критерий | Как проверить | Признак проблемы |
|---|---|---|
| Полнота | Размер архива сопоставим с размером сайта | Копия весит одинаково месяцами или резко меньше |
| Целостность | Распаковать и открыть в отдельном каталоге | Архив не открывается, база не импортируется |
| Восстановимость | Развернуть на поддомене или тестовой копии | Сайт открывается, а вход в админку и вложения — нет |
Отдельно про доступность: копии должны быть защищены теми же правами, что и остальная инфраструктура, но доступ к ним не должен зависеть от сотрудника, который их настраивал. Если архив лежит на личном диске администратора — это не резервная копия, а личный сувенир.
Что бэкапить: список, а не ощущение
Типичная ошибка — считать, что «сайт» это файлы. Восстановление без базы даёт пустые страницы, восстановление базы без файлов — битые картинки и вложения.
| Объект | Частота | Почему отдельно |
|---|---|---|
| База данных | Ежедневно | Контент, заказы, заявки, настройки — самое ценное |
| Загруженные файлы | Ежедневно | Фото товаров и вложения; без них сайт формально работает, но выглядит сломанным |
| Код темы и плагинов | При каждом изменении | Свои правки легко потерять при обновлении |
| Конфигурация сервера | При каждом изменении | `htaccess`, правила редиректов, cron, настройки PHP |
| Почта и лиды в CRM | Ежедневно или непрерывно | Заявки — это деньги; теряются чаще, чем кажется |
| 1С (если есть обмен) | По регламенту | Восстановление базы 1С — отдельная процедура и отдельные сроки |
Диагностика за 30 минут: работает ли ваш бэкап
Проверка не требует доступа к серверу на уровне администратора — хватает панели хостинга и админки сайта.
| Где смотреть | Что искать | Норма |
|---|---|---|
| Панель хостинга | Дата и размер копий | Копия за последние сутки, размер растёт вместе с сайтом |
| Журнал задач плагина | Последний запуск и ошибки | Успешный запуск сегодня, ошибок нет |
| Каталог с архивами | Где физически лежат файлы | Не на том же диске, что сайт |
| Расписание | Совпадают ли точки для базы и файлов | Один цикл или разница не больше нескольких минут |
| Права и доступы | Кто может удалить копии | Отдельные права, не те же, что у сайта |
| Тестовое восстановление | Дата последней проверки | Не реже раза в квартал |
Последняя строка — главная. Если вы не помните, когда в последний раз разворачивали копию, значит, проверки не было.
Сколько стоит потеря данных
Простой считается не «моральным ущербом», а конкретными деньгами. Возьмём сайт, который приносит 15 заявок в неделю со средним чеком 40 000 ₽ и конверсией в сделку 20 %.
- Один день простоя — около 2 заявок и 16 000 ₽ ожидаемой выручки.
- Потеря недели заявок — 15 лидов и 120 000 ₽.
- Потеря базы за месяц (заказы, клиенты, история) — часто дороже выручки: восстановить историю общения невозможно.
Сравните с ценой вопроса: ежедневные копии в объектном хранилище стоят в районе нескольких сотен рублей в месяц, проверка восстановления — пара часов работы раз в квартал. Разница на порядки, но решение обычно принимают после аварии, а не до.
Когда виновата не копия, а процесс
Бывает, что копии в порядке, а данные всё равно теряются: сотрудники удаляют записи, обмен с 1С перезаписывает цены, интеграция дублирует сделки. В таких случаях бэкап — это лечение симптома.
- Если удаляют данные руками — нужны права и журнал действий, а не ежедневный откат. Подробнее: пароли и доступы: как перестать хранить их в переписке.
- Если расходится учёт — причина в обмене, а не в копиях: один источник правды: почему 1С, CRM и Excel спорят.
- Если сбой повторяется — нужна не копия, а разбор интеграции: почему интеграции ломаются через полгода.
Настроить копии и регламент проверки мы берём в рамках обслуживания сайтов и администрирования Битрикс24: ежедневные копии в отдельное хранилище, тестовое восстановление раз в квартал, отчёт с датой и результатом.
Что зафиксировать в договоре на обслуживание
Резервное копирование редко попадает в договор целиком — обычно одной строкой «исполнитель обеспечивает резервное копирование». Этого мало: нужны числа и процедура.
- Частота и глубина хранения: «ежедневно, хранение 30 дней, месячная копия — 12 месяцев».
- Состав: база + загруженные файлы + конфигурация, единым циклом.
- Место: отдельное хранилище, не на том же сервере.
- Проверка: тестовое восстановление раз в квартал с отчётом (дата, что разворачивали, результат).
- Срок восстановления: за какое время исполнитель обязуется поднять сайт из копии.
- Кто платит за простой: сервисная компенсация, если восстановление не удалось по вине исполнителя.
- Выдача копий при расторжении: архив передаётся заказчику, а не остаётся у подрядчика.
Последний пункт часто забывают. История, где после смены подрядчика сайт живёт, а копий нет вообще, потому что они «на аккаунте старого админа», встречается регулярно. Формулировки про сроки и ответственность разобраны в статье SLA в договоре: семь формулировок.
Частые вопросы
Достаточно ли бэкапов хостинга?
Как последний рубеж — да, как основной механизм — нет. Обычно хостинг хранит копии 1–7 дней, восстанавливает целиком и не по вашему расписанию. Для заявок и заказов этого мало.
Как часто делать копии?
База — ежедневно, при активных продажах дважды в день. Файлы — ежедневно или инкрементально, если их много. Конфигурация — перед любым изменением. Для сайта без заказов допустимо ежедневно; для интернет-магазина — не реже раза в сутки и с хранением месяца.
Хватит ли копии только базы?
Нет. База без файлов даёт сайт без картинок и вложений, а иногда без работающих скриптов темы. Копировать нужно комплектом.
Нужно ли шифровать архивы?
Если копия уходит в облако, шифрование полезно: в архиве персональные данные клиентов. Главное — не потерять ключ и хранить его отдельно от архива.
Сколько места занимают копии?
При ежедневных полных копиях и хранении 30 дней это около 30 размеров сайта; 1,5–3 размера получается только при инкрементальных копиях или дедупликации в объектном хранилище. Если места не хватает — сокращают глубину и делают недельные архивы, а не отказываются от ежедневных.
Что делать сразу после взлома?
Не восстанавливать поверх работающего сайта: сначала снять копию текущего состояния для разбора, затем поднимать чистую версию из архива и менять все доступы. Порядок действий — в статье Взломанный сайт: пять сценариев и что делать в первый час.
Что сделать на этой неделе
- Откройте панель и посмотрите дату и размер последней копии.
- Проверьте, где физически лежит архив — на том же диске или нет.
- Сравните расписание копий базы и файлов.
- Разверните копию на тестовом поддомене и откройте любую страницу с картинками.
- Запишите в договор частоту, глубину хранения и обязанность проверять восстановление.
Для коробочного Битрикс24 к этому добавляется каталог `bitrix/backup` и настройка самого продукта: штатное резервное копирование есть, но по умолчанию часто выключено или пишет копии в тот же каталог.
