Копии хранятся 3, 7 или 30 дней: как выбрать глубину бэкапа
Показываем, как рассчитать срок хранения резервных копий по задержке обнаружения, времени принятия решения о восстановлении и интервалу снимков — без выбора «на глаз».
В этой статье
Глубину хранения резервных копий выбирают не по принципу «чем больше, тем спокойнее», а по худшему правдоподобному времени обнаружения ошибки. Практический ориентир: срок хранения должен быть больше суммы задержки обнаружения, времени на подтверждение причины и принятие решения о восстановлении и одного интервала между снимками. Иначе последняя исправная точка может исчезнуть как раз к моменту, когда станет понятно, что восстанавливать.
Частота и глубина — разные параметры. Ежедневное копирование отвечает на вопрос, как часто появляется новая точка. Хранение семь дней — как долго старая точка остаётся доступной. Семь ежедневных копий также не всегда означают семь полных суток истории: важны точные часы создания и удаления, пропущенные задания и правила провайдера.
Сначала найдите последнюю безопасную точку
Возьмём учебный сценарий магазина. Снимок создаётся каждый день в 02:00. Ошибка импорта попала в базу в понедельник в 13:00, но её заметили только в пятницу в 10:00. К 16:00 команда подтвердила причину и выбрала восстановление. Последняя заведомо исправная копия была создана в понедельник в 02:00.
Событие | Момент относительно ошибки | Что это меняет |
|---|---|---|
Последняя безопасная копия | T−11 ч | К моменту принятия решения её возраст составит 110 часов |
Ошибка попала в данные | T0 | Все более поздние снимки могут содержать дефект |
Проблему обнаружили | T+93 ч | Трёхдневная история уже слишком коротка |
Решение о восстановлении принято | T+99 ч | Нужна исправная копия возрастом 110 часов — четыре суток и четырнадцать часов |
В этом примере трёх дней недостаточно, семь дней сохраняют нужную точку, а тридцать дней не дают дополнительной пользы именно для этого сценария. Вот тут интересно: если ошибка случилась за минуту до очередного снимка, последняя безопасная копия окажется почти на сутки старше самой ошибки. Поэтому к времени обнаружения добавляют полный интервал копирования и не округляют результат вниз.
Оцените максимальную задержку обнаружения: не среднюю, а ту, которая возможна для редко проверяемой функции.
Добавьте время на проверку причины, согласование отката и получение доступа к копиям.
Добавьте один интервал между снимками: он покрывает неблагоприятное положение ошибки между двумя заданиями.
Сверьте результат с точным временем удаления копий и оставьте запас на границе срока.
Такой расчёт задаёт бизнес-требование, а не универсальный стандарт. Руководство NIST по планированию восстановления предлагает определять требования и приоритеты для конкретной системы; оно не назначает всем сайтам одинаковые 3, 7 или 30 дней.
Что на практике дают 3, 7 и 30 дней
Глубина | Когда может хватить | Где риск |
|---|---|---|
3 дня | Ошибки видны в тот же день, проверки идут ежедневно, решение принимается быстро | Дефект перед выходными или в редко используемой функции успеет пережить всю историю |
7 дней | Проверки идут несколько раз в неделю; сумма задержки обнаружения, времени принятия решения и интервала копирования с запасом меньше семи суток | Месячные выгрузки, закрытие периода и медленные жалобы клиентов могут обнаружить проблему позже |
30 дней | Ошибка может проявиться с большой задержкой, но расчёт вместе со временем принятия решения, интервалом копирования и запасом укладывается в тридцать суток | Более длинная история бесполезна без понятного состава копии, доступа и теста восстановления |
Таблица не выбирает тариф автоматически. Если складские остатки товаров сверяются раз в неделю, а платёжные статусы — каждый день, им могут понадобиться разные способы защиты. Для базы заказов полезны более частые точки или журналы изменений, а для редко меняющихся файлов — более длинная история. Один срок на весь проект удобен в договоре, но не всегда описывает реальный риск.
Почему ежедневный бэкап может не оставить безопасной копии
Ошибка долго остаётся незаметной и попадает во все новые снимки.
Задание формально запущено, но база, пользовательские файлы или конфигурация не вошли в копию.
Снимки хранятся в той же учётной записи и удаляются вместе с рабочими данными.
Провайдер считает срок от точного времени создания, а команда мысленно считает календарные дни.
Сбой копирования уменьшил число точек, но уведомление никто не обработал.
Восстановление не проверяли после обновления CMS, базы или интеграций.
При атаке программы-вымогателя, которая шифрует данные, одного длительного хранения копий мало. Руководство CISA по защите от программ-вымогателей рекомендует держать критичные копии офлайн и в зашифрованном виде, а также регулярно проверять их доступность, целостность и процедуру восстановления. Доступная на запись копия может быть испорчена теми же учётными данными, что и основной сервер.
Несколько групп резервных копий полезнее единого срока хранения
Для проекта с разной скоростью обнаружения можно разделить историю. Например, это учебная модель, а не готовая политика: семь ежедневных точек закрывают недавние ошибки, пять еженедельных — проблемы, найденные при недельной сверке, двенадцать ежемесячных — редкие ошибки закрытия периода. Состав и независимость каждого слоя всё равно проверяют отдельно.
Слой | Пример расписания | Какую задачу решает |
|---|---|---|
Короткий | Ежедневно, хранить 7 резервных копий | Быстрый откат недавнего изменения |
Средний | Раз в неделю, хранить 5 резервных копий | Ошибка обнаружена на следующей сверке |
Длинный | Раз в месяц, хранить 12 резервных копий | Сезонное или отчётное сравнение |
Объём считают с открытыми допущениями. Если полная копия занимает 80 ГиБ, семь независимых полных копий потребуют до 560 ГиБ до учёта сжатия и дедупликации: 80 × 7 = 560. Инкрементальная схема может занять меньше, но её нельзя оценить без объёма изменений и правил сборки цепочки. Экономия места не должна превращать одну повреждённую базовую копию в отказ всей истории.
Что уточнить у хостинга или подрядчика
Что именно входит в копию: база, файлы, почта, конфигурация, задания и пользовательские загрузки.
По какому часовому поясу создаются точки и в какой момент они удаляются.
Считается ли глубина календарными днями, полными сутками или количеством точек.
Что происходит при пропущенном задании и кто получает уведомление.
Можно ли удалить сервер и копии одной учётной записью; есть ли отдельное или неизменяемое хранение.
Сколько занимает получение копии и кто имеет право начать восстановление.
Можно ли восстановить проект в изоляции без писем, платежей, обмена с 1С и обращений к рабочим API.
Если сравниваете варианты сопровождения, смотрите не только число дней: на странице комплексной поддержки варианты различаются глубиной хранения, но до выбора всё равно нужно согласовать состав данных, место копий и порядок восстановления.
Критерий приёмки выбранной глубины
Для каждой критичной функции записана максимальная задержка обнаружения, а не удобная средняя.
Расчёт включает время принятия решения о восстановлении и полный интервал между снимками.
В панели видны реальные точки с датами; число и возраст совпадают с условиями хранения.
Есть хотя бы одна безопасная точка для выбранного контрольного сценария.
Последнее изолированное восстановление завершилось проверкой заказов, оплат, файлов и интеграций.
Копии защищены от удаления тем же событием или доступом, который повредит основной сайт.
После изменения CMS, базы, расписания или состава данных расчёт и тест повторяются.
Отдельная проверка резервной копии через RPO, RTO и тестовое восстановление отвечает на вопрос, можно ли вернуть магазин в работу. Материал о копии вне основного хостинга помогает проверить независимость места хранения. Глубина — третья отдельная проверка: останется ли нужная исправная точка к моменту решения.
Итоговый критерий простой: выбран не самый длинный срок хранения из предложений провайдера, а срок, который переживает ваш худший правдоподобный сценарий обнаружения ошибки и принятия решения о восстановлении. Если расчёт даёт пять суток, трёхдневный вариант уже не подходит, а семидневный нужно проверить по фактическим часам создания и удаления. Красивое слово «ежедневно» тут, увы, не заменяет календарь.
Backup retention depth is chosen not by the principle "the more, the calmer," but by the worst-case plausible time to detect an error. A practical guideline: retention time must exceed the sum of detection delay, time to confirm the cause and decide on restoration, plus one snapshot interval. Otherwise, the last valid point may disappear just when it becomes clear what needs to be restored.
Frequency and depth are different parameters. Daily backups answer how often a new point appears. Storing for seven days means how long an old point remains available. Seven daily backups do not always mean seven full days of history: exact creation and deletion times, missed jobs, and provider rules matter.
First, find the last safe point
Let's consider a store training scenario. A snapshot is created daily at 02:00. An import error entered the database on Monday at 13:00, but it was noticed only on Friday at 10:00. By 16:00, the team confirmed the cause and selected recovery. The last known good copy was created on Monday at 02:00.
Event | Moment relative to the error | What this changes |
|---|---|---|
Last safe backup | T−11 h | By the time the decision is made, its age will be 110 hours |
The error entered the data | T0 | All subsequent snapshots may contain the defect |
The issue was discovered | T+93 h | A three-day history is too short |
The decision to restore has been made | T+99 h | A working copy aged 110 hours is needed — four days and fourteen hours |
In this example, three days are insufficient, seven days preserve the needed point, and thirty days offer no additional benefit for this specific scenario. Here is an interesting point: if the error occurred one minute before the next snapshot, the last safe copy will be almost a full day older than the error itself. Therefore, the full backup interval is added to the detection time, and the result is not rounded down.
Assess the maximum detection delay: not the average, but the one possible for a rarely checked function.
Add time for verifying the cause, agreeing on a rollback, and obtaining access to copies.
Add one interval between snapshots: it covers the unfavorable error position between two jobs.
Verify the result against the exact time of copy deletion and leave a margin at the deadline.
Such a calculation sets a business requirement, not a universal standard. NIST Recovery Planning Guide recommends defining requirements and priorities for a specific system; it does not assign the same 3, 7, or 30 days to all sites.
What 3, 7, and 30 days provide in practice
Depth | When it may suffice | Where the risk lies |
|---|---|---|
3 days | Errors are visible on the same day, checks are performed daily, and decisions are made quickly | A defect occurring before the weekend or in a rarely used feature may survive the entire history |
7 days | Checks occur several times a week; the sum of detection delay, decision time, and copy interval plus a buffer is less than seven days | Monthly exports, period closure, and slow customer complaints may reveal the problem later |
30 days | An error may appear with a significant delay, but the calculation, together with decision time, copy interval, and buffer, fits within thirty days | A longer history is useless without a clear understanding of the copy's composition, access, and recovery test |
The table does not automatically select a tariff. If warehouse stock levels are reconciled once a week while payment statuses are checked daily, they may require different protection methods. Order databases benefit from more frequent points or change logs, while rarely changing files need a longer history. A single retention period for the entire project is convenient in a contract but does not always reflect the actual risk.
Why a daily backup may not leave a safe copy
The error remains unnoticed for a long time and gets included in all new snapshots.
The task is formally started, but the database, user files, or configuration were not included in the copy.
Snapshots are stored in the same account and are deleted along with the working data.
The provider counts the term from the exact creation time, while the team counts calendar days mentally.
A copy failure reduced the number of points, but no one processed the notification.
Recovery was not tested after updating the CMS, database, or integrations.
In the event of a ransomware attack that encrypts data, long-term storage of copies alone is insufficient. CISA's guide to ransomware protection recommends keeping critical copies offline and encrypted, regularly verifying their availability, integrity, and recovery procedures. A writable copy can be corrupted by the same credentials used for the main server.
Multiple backup groups are more useful than a single retention period
For a project with varying detection speeds, you can separate the history. For example, this is a training model, not a finalized policy: seven daily snapshots cover recent errors, five weekly ones cover issues found during weekly reconciliation, and twelve monthly ones cover rare period-closing errors. The composition and independence of each layer must still be verified separately.
Layer | Schedule example | Task addressed |
|---|---|---|
Short | Daily, keep 7 backups | Quick rollback of recent changes |
Medium | Weekly, keep 5 backups | Error detected during the next verification |
Long | Monthly, keep 12 backups | Seasonal or reporting comparison |
The volume is calculated with open assumptions. If a full copy takes 80 GiB, seven independent full copies require up to 560 GiB before accounting for compression and deduplication: 80 × 7 = 560. An incremental scheme may take less, but it cannot be estimated without the volume of changes and chain-building rules. Space savings must not turn a single corrupted base copy into a failure of the entire history.
What to clarify with the hosting provider or contractor
What exactly is included in the copy: database, files, email, configuration, tasks, and user uploads.
Which time zone is used to create points and when they are deleted.
Whether depth is measured in calendar days, full days, or the number of points.
What happens when a task is skipped and who receives the notification.
Whether a server and copies can be deleted with a single account; whether separate or immutable storage exists.
How long it takes to retrieve a copy and who has the right to initiate recovery.
Whether a project can be restored in isolation without emails, payments, 1C integration, or calls to active APIs.
When comparing support options, look beyond the number of days: on the comprehensive support page, variants differ in storage depth, but before choosing, you must still agree on the data composition, copy locations, and recovery sequence.
Acceptance criterion for the selected depth
For each critical function, the maximum detection latency is recorded, not a convenient average.
The calculation includes the time to decide on recovery and the full interval between snapshots.
The panel displays actual points with dates; the count and age match the storage conditions.
There is at least one safe point for the selected control scenario.
The last isolated recovery was completed with checks for orders, payments, files, and integrations.
Copies are protected from deletion by the same event or access that would damage the main site.
After changes to the CMS, database, schedule, or data composition, the calculation and test are repeated.
A separate backup verification via RPO, RTO, and test restoration answers the question of whether the store can be restored to operation. Material on copies stored outside the main hosting helps verify the independence of the storage location. Depth is the third separate check: will the required valid point remain available by the time the decision is made?
The final criterion is simple: choose not the longest retention period offered by the provider, but the one that survives your worst plausible scenario for error detection and decision-making on restoration. If the calculation yields five days, a three-day option is already unsuitable, and a seven-day option must be verified against actual creation and deletion timestamps. Unfortunately, the attractive word 'daily' does not replace a calendar here.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.