Политика хранения резервных копий определяет, какие состояния данных остаются доступными, как долго они хранятся и что происходит по окончании срока хранения. Её назначение шире простой экономии места. При слишком коротком сроке нужная версия данных может быть удалена раньше, чем обнаружится ошибка. Слишком длинный срок увеличивает объём, затраты и количество конфиденциальных данных, которые необходимо защищать.
Полезная политика определяет необходимые временные рамки, детализацию точки восстановления, места хранения, исключения из правил удаления и ответственного за каждую систему. Готовый набор дней, взятый из примера другого, не может заменить эти решения.
Разделите четыре различных вопроса о хранении
График резервного копирования не определяет всю политику хранения данных
|
Концепция |
Отвечает на этот вопрос |
Что следует проверить отдельно |
|---|---|---|
|
Частота резервного копирования |
Как часто появляется новая точка восстановления |
Завершение задач и пригодность данных |
|
Срок хранения резервных копий |
Какие точки восстановления остаются доступными и сколько они могут быть старыми |
Уровень детализации истории и возможность восстановления |
|
Неизменяемость |
Как долго запрещено изменение или удаление, и какие разрешения применяются |
Режим, область действия и когда защита прекращается |
|
Хранение и ведение документации |
Какую информацию требует организация, чтобы вы ее хранили, находили или удаляли |
Применимые требования, поиск, доказательства и исключения |
Длительный период хранения не гарантирует автоматическое предоставление подробной истории. Если вы сохраняете только одну точку восстановления в месяц, вы не можете обещать восстановление в любой день этого месяца. С другой стороны, частые резервные копии не помогут вам найти старое состояние, если вся история истекает до того, как кто-то обнаружит проблему.
Резервная копия и архив служат различным, но связанным целям. Резервная копия восстанавливает выбранное состояние системы или ее данных. Архив может поддерживать длительное хранение и поиск отдельных записей. Вместо автоматического применения периода хранения архива ко всем полным резервным копиям системы, уточните требуемый результат.
Для облачного приложения, проверьте историю версий, корзину, правила хранения данных и функции резервного копирования отдельно. Их область действия и доступные операции могут отличаться. Политика хранения не доказывает, что необходимое восстановление возможно, а название провайдера не гарантирует его недоступность.
Соберите требования для каждой группы данных
Определите требуемую глубину и детализацию истории
Спросите у владельца системы, какие ошибки необходимо исправить и когда люди обычно их обнаруживают. Немедленное удаление и скрытая поврежденность, обнаруженные при последующей сверке, требуют разных исторических данных. Учитывайте завершенные бизнес-циклы, проверки данных и возможность восстановления предыдущего работоспособного состояния.
Укажите, насколько точно вам необходимо выбрать состояние: конкретную транзакцию, ближайший момент, день или менее частый исторический период. Сравните это с изменениями данных и согласованным уровнем RPO (Recovery Point Objective). RPO описывает допустимую потерю последних изменений, но не определяет автоматически глубину всей истории.
Перечислите данные и зависимости, которые необходимо восстановить вместе. Приложению может потребоваться база данных, файлы, настройки и совместимые версии компонентов. Длительное хранение одного элемента не поможет, если связанный компонент уже устарел или не может быть использован.
Проверьте ограничения и обязанности
Классифицируйте данные по ценности, чувствительности и применимым правилам. Владелец процесса подтверждает необходимость хранения данных. Технический владелец проверяет возможности продукта и стоимость. Согласуйте требования к документам, персональным данным и исключениям из удаления с ответственными лицами в организации.
Не присваивайте один период хранения всем данным только потому, что кто-то упоминает HIPAA, GDPR, финансовое регулирование или закон другой страны. Каждое требование относится к конкретным данным, организациям и деятельности. Запишите согласованный результат этой оценки в политику резервного копирования, а не делайте предположения, основанные на названии закона.
Определите уровни истории и проверьте ограничения продукта
Сохраняйте только те точки восстановления, которые вам необходимы, а не просто больше файлов
Вы можете разделить политику на подробную историю последних событий и менее частые более старые точки. Схема GFS обычно описывает комбинацию ежедневных, еженедельных и ежемесячных резервных копий. Это помогает организовать историю, но не предписывает обязательные периоды хранения и не гарантирует каждое промежуточное состояние.
Для каждого уровня определите, как выбирать точки восстановления, как долго их хранить и как они перемещаются между уровнями. Убедитесь, что продукт использует определенное событие для расчета возраста: начало работы, создание точки восстановления или другое событие. Проверьте часовой пояс и правила перекрытия. Фактически важным является сохраненный набор данных, а не легко понятное название расписания.
Если вы используете полные и инкрементные резервные копии, определите, какие данные требуются для выбранной точки восстановления. Ручное удаление отдельного файла из цепочки резервных копий рискованно. Используйте поддерживаемую систему управления жизненным циклом и убедитесь, что она сохраняет зависимости других точек восстановления. Проверьте реализацию, прежде чем полагаться на утверждение, что каждая точка независима.
Разделите хранение, тип хранения и доступность восстановления
Перемещение старой истории в более дешевый класс хранения может изменить время восстановления, стоимость восстановления и ограничения на удаление. Прежде чем это сделать, убедитесь, что вы можете получить доступ к данным в течение необходимого времени. Низкая стоимость хранения не может компенсировать неподходящий путь восстановления.
Например, AWS Backup использует отдельные настройки для расписаний, жизненного цикла и перехода в хранилище холодного типа. Поддержка перехода зависит от ресурса, и существуют ограничения на минимальный период хранения и изменения конфигурации. Проверьте текущие условия вашего сервиса. Не переносите номера и ограничения одного продукта на другой.
Для копий, хранящихся в другом месте, проверьте правила самого места назначения. Период хранения, класс хранения и поведение после удаления основной копии могут отличаться от исходной. Запишите, какие копии контролирует политика, включая старые ручные копии и данные, сохраненные после вывода системы из эксплуатации.
Согласуйте правила и исключения перед удалением
Неизменяемость может препятствовать преждевременному удалению. Ее продолжительность не всегда соответствует всему периоду хранения. Проверьте оба значения, разрешения на их изменение и необратимые настройки. Удлинение периода может привести к дополнительным затратам, а сокращение его с помощью стандартных средств может оказаться невозможным.
Расследование или другое согласованное исключение может потребовать от вас приостановки удаления определенного набора данных. Укажите причину, объем, ответственного лица, дату рассмотрения и процедуру отмены исключения. Убедитесь, что продукт поддерживает это. Не предполагайте, что каждый резервный копий автоматически обеспечивает юридическое обязательство.
Заполните матрицу политики хранения
Используйте отдельную строку для каждой системы или класса данных с одинаковыми требованиями. Заполните поля в скобках после согласования. Если данные в одной системе имеют различные ограничения, разделите строки и проверьте, может ли продукт применять различные правила, не ставя под угрозу полное восстановление.
Матрица хранения с полями для согласования
|
Система и данные |
Необходимая история |
Уровни и периоды хранения |
Местоположение и доступность |
Удаление и исключения |
Владение и проверка |
|---|---|---|---|---|---|
|
[Операционная база данных и связанные файлы] |
[Окно обнаружения ошибок и требуемая точность состояния] |
[Последние точки, менее частые записи и продолжительность каждого уровня] |
[Основные и удаленные копии, класс хранения и время извлечения] |
[Срок действия, блокировка и согласованные исключения] |
[Владелец процесса, владелец ИТ и дата проверки] |
|
[Рабочие документы] |
[Требуемые предыдущие состояния и бизнес-циклы] |
[Поколения и периоды хранения, основанные на согласованных потребностях] |
[Места и методы поиска и извлечения данных] |
[Срок действия и правила для конфиденциальных данных] |
[Владельцы и подтверждение восстановления] |
|
[Конфигурации и данные восстановления] |
[Совместимость и требуемые версии] |
[Сроки хранения, соответствующие зависимым системам] |
[Доступ к данным при потере основной среды] |
[Удаление зависимостей и специальные исключения] |
[Владелец и результаты проверки для полного набора данных восстановления] |
|
[Устаревшая система] |
[Подтвержденная необходимость сохранения истории] |
[Оставшиеся точки восстановления и окончательная дата хранения] |
[Место хранения, инструменты восстановления и владелец данных восстановления] |
[Процесс завершения хранения каждой копии] |
[Владелец для завершения хранения и проверки] |
Добавьте версию политики и настройки, которые ее реализуют, в таблицу. Запишите утвержденные исключения и процесс изменений отдельно. Это позволяет сравнивать принятое решение с фактической конфигурацией, вместо того, чтобы искать информацию в электронных письмах и старых рабочих файлах.
Проверьте применение и завершение политики
После настройки сравните ожидаемые и фактические точки восстановления на границах уровней. Убедитесь, что необходимая старая история сохранена, и что правила не конфликтуют. Проверьте, как существующие точки восстановления ведут себя после изменения политики: продукт может применять новые настройки к ним по-разному, чем к новым копиям.
Восстановите выбранную старую и недавнюю точку восстановления. Проверьте доступность приложения, необходимых зависимостей и данных в соответствующей классе хранения. Для зашифрованной копии подтвердите доступ к ключам дешифрования. Измерьте время восстановления и убедитесь, что восстановленные данные поддерживают бизнес-задачу.
Срок действия должен инициировать желаемое действие, при условии наличия блокировок и исключений. Проверьте результаты удаления, ошибки и оставшиеся копии в других местах. Удаление записи из каталога не всегда немедленно освобождает каждый физический блок. Общие данные, цепочки и механизмы хранения могут влиять на это. Подтвердите, как сервис и тип носителя проверяют удаление.
Не обещайте немедленное удаление отдельной записи из каждого неизменяемого полного резервного копирования. Если правила доступа или удаления требуют специальной обработки, заранее согласуйте технически осуществимый процесс. Уничтожение носителей также не является универсальной операцией для каждого истекшего облачного резервного копирования.
Проверьте затраты, защиту и исключения
- Сравните фактическую глубину и детализацию истории с таблицей.
- Отслеживайте рост объема, неудачные операции и ошибки жизненного цикла.
- Проверьте разрешения, защиту доступа администратора и доступность ключей.
- Включите затраты на хранение, восстановление, передачу и поддержание совместимости.
- Проверьте сроки хранения после изменения бизнес-циклов, систем, угроз или согласованных требований.
- Подтвердите необходимость продолжения использования исключений и завершите их в соответствии с принятым решением.
- Сохраняйте результаты проверки, ответственных лиц и историю изменений политики.
Автоматизация помогает последовательно применять графики и удаление. Она также последовательно применяет неправильное правило. Отслеживайте исключения и проверяйте результат. Бесконечное хранение только на случай, если, и один период для всей компании требует столько же обоснований, сколько и сокращение истории.
Нужно согласовать глубину истории резервных копий и проверить её реализацию? Обратитесь в DKs Enterprises по вопросам резервного копирования и аварийного восстановления. Подготовьте матрицу систем, текущие сроки хранения и известные исключения, чтобы обсудить необходимые работы.
