Как часто нужно делать резервные копии сайта и бизнес-системы?

Резервные копии нужны так часто, чтобы после сбоя компания могла вернуться к приемлемой точке без болезненной ручной работы. Для сайта с редкими изменениями это может быть раз в сутки. Для CRM, интернет-магазина или учетной системы, где данные меняются весь день, одной ночной копии обычно мало. Правильную частоту определяет не календарь, а цена потерянных данных и время на восстановление.

Начните не с расписания, а с двух честных ответов

Первый: сколько данных можно потерять без серьезного ущерба? Второй: как долго система может не работать, прежде чем остановится нормальная работа? Это не технические вопросы. Их лучше обсуждать с теми, кто отвечает за заказы, деньги, клиентов и производство.

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

В техническом разговоре эти границы часто называют RPO и RTO. Не обязательно запоминать сокращения. Достаточно зафиксировать по-русски: «мы готовы потерять не больше такого-то периода данных» и «система должна вернуться в работу не позднее такого-то времени».

Как выбрать частоту для разных систем

Универсальной цифры нет, но есть понятная логика.

• Редко меняющийся сайт: ежедневная копия базы и файлов обычно является разумным минимумом, если изменения публикуются нечасто.
• Корпоративный сайт с заявками: база данных заслуживает более частых копий, потому что в ней появляются обращения и заявки, которые не всегда можно восстановить по почте.
• Интернет-магазин, CRM, учетная система: частота должна соответствовать потоку операций; одной ночной точки может быть недостаточно.
• Система с критичными операциями: нужно отдельно проектировать резервирование данных и сценарий переключения, а не надеяться на обычный архив.

Важно не путать полную копию с быстрым журналом изменений. Полный архив удобен для понятного восстановления. Более частая защита базы или изменений помогает сократить потерю данных между полными копиями. Какой набор нужен, зависит от конкретной системы и от того, действительно ли команда умеет им пользоваться.

Почему «раз в сутки» иногда не отвечает на вопрос

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

Иногда данные уже есть в другой системе: заказ сохранен у платежного провайдера, обращение пришло на корпоративную почту, документ остался в ЭДО. Это помогает восстановиться, но не должно становиться заменой нормальной копии. Собирание разрозненных следов — медленный и нервный процесс. Лучше заранее решить, какие данные считаются первичным источником и как они попадают в резерв.

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

Копия, которую нельзя восстановить, не является защитой

Самая опасная фраза в этой теме: «Бэкапы есть, мы их видели». Файл может создаваться по расписанию, но быть пустым, поврежденным, неполным или лежать рядом с системой, которая сгорит вместе с ним. Еще хуже, когда архив технически целый, но никто не знает порядок восстановления.

Поэтому резервное копирование состоит из двух частей: создать копию и регулярно проверить восстановление. Вторая часть ценнее первой. Она отвечает на реальные вопросы: хватает ли файла, в каком порядке поднимать базу и файлы, какие доступы нужны, что произойдет с интеграциями, сколько времени это занимает.

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

Где хранить резервные копии

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

Практичная логика — иметь несколько копий на разных носителях и хотя бы одну отдельно от рабочего контура. Конкретная реализация может быть разной: отдельное хранилище, другой сервер, защищенный облачный аккаунт. Важнее проверить, что у этих мест разные точки отказа и доступ к ним ограничен.

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

Какие копии стоит хранить

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

Обычно полезно иметь короткую плотную историю свежих копий и более редкие точки за прошлые недели или месяцы. Срок хранения надо выбирать осознанно: слишком короткий не оставляет пути назад, слишком длинный без контроля превращает хранилище в дорогой склад. Владелец системы должен понимать, сколько версий есть, где они лежат и кто вправе их удалить.

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

Кто отвечает за результат

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

Полезно заранее определить, кто имеет право начать восстановление. В большинстве случаев это серьезное действие: оно может заменить актуальные данные более старой версией. Решение не должно зависеть от того, кто первым увидел ошибку в чате. Нужен короткий путь согласования и ясный человек, который понимает последствия для клиентов и операционной работы.

Полезно записать это на одной странице: владелец процесса, расписание, место хранения, срок хранения, порядок проверки, контакты на случай восстановления. Такой документ не обязан быть сложным. Его ценность в том, что он помогает не искать пароль и ответственного, когда время уже дорого.

Защита данных связана и с доступами. Отдельная копия не спасет, если один скомпрометированный аккаунт может удалить и рабочую систему, и все архивы. В материале об ответственности за данные и доступы в облаке я подробно объясняю, почему удобный сервис не отменяет необходимости управлять правами.

Короткий чек-лист

1. Назовите системы и данные, потеря которых действительно остановит работу.
2. Для каждой определите допустимую потерю данных и простой.
3. Настройте копии с подходящей частотой, а не по привычке.
4. Храните хотя бы одну копию отдельно от рабочего контура.
5. Оставляйте историю версий, чтобы можно было вернуться до момента ошибки.
6. Проверяйте восстановление по расписанию и фиксируйте результат.
7. Ограничьте права на удаление архивов и держите актуальные контакты.

Связанные вопросы

• Что нужно включить в резервную копию сайта, кроме файлов?
• Как проверить, что восстановление из копии действительно работает?
• Чем резервная копия отличается от отказоустойчивости?
• Кто должен иметь доступ к архивам компании?

Хорошая частота резервного копирования не выглядит впечатляющей. Она просто соответствует тому, как живет ваш бизнес, и проверена до аварии. Это тот случай, когда спокойная регулярная дисциплина стоит намного дешевле одного героического восстановления.