Срок хранения резервных копий нельзя выбирать по привычке: "храним неделю", "храним месяц" или "чем дольше, тем лучше". Правильный срок зависит от того, какую проблему нужно пережить и через сколько времени компания поймет, что данные испорчены или потеряны.
Если ошибка обнаруживается сразу, достаточно близкой точки восстановления. Если неправильные данные незаметно жили в системе две недели, последняя копия уже содержит ту же проблему. Поэтому retention должен начинаться не с календаря, а со сценариев восстановления.
Какие сценарии нужно описать
Для небольшой компании обычно хватает нескольких базовых сценариев: случайное удаление файла, массовая порча данных, неудачное обновление, ошибка обмена между системами, сбой сервера, повреждение базы, шифрование, потеря облачного аккаунта или ошибочное изменение прав доступа.
У каждого сценария есть свое время обнаружения. Пользователь заметит удаленный документ через час, бухгалтерская ошибка может всплыть при сверке через неделю, а поврежденный архив может обнаружиться только при попытке восстановиться. Один срок хранения не покрывает все эти случаи одинаково хорошо.
| Сценарий | Когда обычно обнаруживают | Что важно в retention |
|---|---|---|
| Случайное удаление файла | от минут до нескольких дней | частые свежие точки и быстрый поиск |
| Ошибка в базе или обмене | через дни или недели | несколько исторических точек до момента ошибки |
| Неудачное обновление | сразу или в первый рабочий цикл | точка перед изменением и проверка отката |
| Шифрование | обычно быстро, но масштаб не сразу понятен | изолированные копии и несколько независимых точек |
| Аудит старого состояния | через месяцы | отдельный архив только для выбранных данных |
Частота копирования и срок хранения - разные решения
Частота отвечает на вопрос, сколько изменений можно потерять между копиями. Срок хранения отвечает на вопрос, насколько далеко назад можно вернуться. Эти параметры связаны, но не заменяют друг друга.
Например, можно делать копию каждый час и хранить только два дня. Это хорошо для свежих сбоев, но не поможет при ошибке, найденной через неделю. Можно хранить ежемесячный архив год, но он не спасет от потери данных за текущий день. Политика backup должна сочетать короткие частые точки и более редкие длинные точки там, где это оправдано.
Данные нужно разделять
Не все данные требуют одинакового retention. Рабочая база, файловый сервер, почта, облачные документы, конфигурации оборудования, виртуальные машины и архивы меняются с разной скоростью и имеют разную цену восстановления.
Если все хранить по максимальному сроку, быстро растут объемы, усложняется контроль и возрастает риск, что backup станет дорогим, медленным и непрозрачным. Если все хранить по минимальному сроку, компания теряет защиту от поздно обнаруженных ошибок. Нужна классификация: критичные рабочие данные, операционные данные, конфигурации, архивы и временная информация.
Длинное хранение не равно надежность
Длинный retention бесполезен, если старую точку нельзя восстановить, найти или проверить. Иногда компания хранит много копий, но не знает, какая из них была до ошибки, где лежит нужная база, сколько займет восстановление и хватит ли места для развертывания.
Поэтому вместе со сроком хранения нужно определять проверку восстановления. Проверять стоит не только последнюю копию. Для сценариев позднего обнаружения нужно периодически поднимать более старую точку и убеждаться, что она читается, содержит нужные данные и не конфликтует с текущими зависимостями.
Как учитывать емкость
Retention всегда упирается в место, скорость передачи и окно backup. Рост копий может вытеснять старые точки раньше планового срока, если емкость рассчитана без запаса. Особенно это заметно у файловых серверов, баз, видеоданных, вложений почты и систем с большим количеством изменяемых блоков.
Хорошая политика должна отвечать на вопрос, что произойдет при нехватке места. Какие точки удаляются первыми? Какие данные имеют исключение? Кто утверждает сокращение срока хранения? Если эти правила не описаны, backup-система может тихо удалить именно ту историю, ради которой retention и создавался.
Пример практичной модели
Вместо одного правила можно использовать уровни. Свежие копии хранятся часто и недолго, чтобы быстро возвращать последние изменения. Средние точки хранятся реже, чтобы закрывать ошибки, найденные через несколько недель. Длинный архив применяется только к тем данным, где есть реальная потребность вернуться далеко назад и возможность проверить восстановление.
Такая модель не является универсальной нормой. Для каждой компании сроки должны утверждаться владельцами данных: бухгалтерией, продажами, складом, производством, руководством. IT-команда или подрядчик помогают перевести бизнес-сценарий в техническую политику, но не должны единолично решать, сколько истории нужно бизнесу.
Что зафиксировать в регламенте
В регламенте должны быть перечислены наборы данных, частота копирования, сроки хранения, место хранения, ответственный владелец, проверка восстановления, исключения и порядок изменения политики. Отдельно стоит указать, какие сценарии эта политика покрывает, а какие нет.
Если такой связи нет, backup обсуждается как техническая галочка. Когда связь есть, становится понятно, зачем хранится каждая точка, какой риск она закрывает и что нужно проверять, чтобы копии не оказались бесполезными в момент восстановления.