Как часто делать резервные копии сайта, чтобы не потерять заявки и заказы

1. Понять измененияЧто появляется на сайте за день.
2. Оценить последствияЧто сотрудники смогут вернуть вручную.
3. Подобрать сохранениеКакие копии и история нужны проекту.
4. Проверить результатНа какой момент действительно вернулись данные.

Что можно потерять между двумя копиями

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

1. 02:00Создана копия
2. 18:00Произошёл сбой

16 часов

Новые заявки, заказы и изменения между этими событиями

Условный пример. В выбранной копии этих изменений ещё нет; часть сведений может сохраниться в других системах.

Этот пример помогает поставить вопрос о частоте копирования в понятных для бизнеса терминах. Важнее определить, с какой потерей изменений вы сможете справиться, чем выбрать привычное «раз в день» без объяснения.

В техническом задании такое требование может называться RPO — целевая точка, до которой необходимо восстановить данные. Определение приведено в NIST — Recovery Point Objective. Само сокращение знать наизусть не нужно, но стоит попросить подрядчика объяснить, как выбранный способ хранения обеспечит согласованный результат.

Как оценить последствия для сотрудников и клиентов

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

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

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

Почему разные данные сохраняют с разной частотой

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

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

Прокрутите таблицу вправо, чтобы увидеть все столбцы.

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

Почему расписание не гарантирует свежие данные

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

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

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

Что делать, если обычных копий недостаточно

Для быстро меняющихся данных иногда используют дополнительный способ: сохраняют основную копию и последовательность последующих изменений. Это позволяет при восстановлении приблизиться к нужному моменту между полными копиями. Такие возможности описаны в документации PostgreSQL 18 — непрерывное архивирование и PITR и MySQL 8.4 — восстановление на момент времени.

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

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

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

Как долго хранить копии и когда менять расписание

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

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

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

Проверка по пунктам

Короткие ответы на частые вопросы

Нужна ли отдельная копия перед массовым изменением каталога?

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

Как выбрать расписание для ваших данных

Чтобы подобрать расписание копирования, расскажите, какие данные появляются на сайте и где ещё они сохраняются. Рекламафия поможет связать настройки с вашей ежедневной работой и проверить выбранный способ восстановления.

Отказоустойчивость и резервное копирование

Читайте также

• Как защитить заказы интернет-магазина и восстановить работу после сбоя
• Как проверить, получится ли восстановить сайт из резервной копии
• Резервные копии, отказоустойчивость и восстановление: что нужно вашему сайту
• Почему резервной копии у хостинга может быть недостаточно
• Как подготовить резервную площадку для сайта и проверить переключение

Источники

• NIST — Recovery Point Objective
• PostgreSQL 18 — непрерывное архивирование и PITR
• MySQL 8.4 — восстановление на момент времени

Обновлено 10 октября 2026 года.