Особенности долгосрочного хранения резервных копий

в 12:33, , рубрики: backup, Veeam, виртуализация, резервное копирование, системное администрирование, метки: , ,

Особенности долгосрочного хранения резервных копий
В соответствии с законодательными требованиями, отраслевыми нормативами и корпоративными политиками от компании могут требоваться длительные сроки хранения корпоративной информации (5, 10 и даже 30 лет). На что нужно обратить особое внимание в таком случае?

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

Для примера, рассмотрим следующую ситуацию:

  • 2000: Приобретен бэкап продукт X, Приобретен накопитель на лентах модели T1
  • 2005: Продолжает использоваться продукт X, Произведен апгрейд накопителя до модели T2
  • 2008: Приобретен бэкап продукт Y, Приобретен накопитель на лентах модели D1
  • 2011: Продолжает использоваться продукт Y, Произведен апгрейд накопителя до модели D2

Затем наступает 2012 год, в котором происходят события, когда нужно восстановить информацию из репозитория резервных копий:

  • Январь 2012: Государственный контролирующий орган требует предоставить различную произвольную информацию, относящуюся к периоду 2007-2011 гг. Информация за период 2008-2011 предоставляется мгновенно, так как ее резервное копирование было выполнено с помощью используемого в настоящий момент продукта резервного копирования Y. Информацию за более ранние периоды восстановить быстро не получилось, так как ИТ-департамент не имеет в наличии модели ленточного накопителя (T2), подходящей для восстановления резервной копии
  • Февраль 2012: ИТ департамент приобретает уже снятый с производства производителем, бывший в употреблении ленточный накопитель модели T2
  • Март 2012: Приобретенный накопитель модели T2 подключается ИТ департаментом к серверу резервного копирования используемого в настоящий момент продукта Y, после чего обнаруживается несовместимость текущего продукта и формата данных резервной копии, созданной в бэкап-продукте X. Для восстановления требуется установка продукта X, однако обнаруживается, что имеющаяся в компании старая версия продукта X не совместима с используемой в настоящей момент версией операционной системы.
  • Апрель 2012: Производителю продукта X посылается запрос на получение последней версии продукта X, которая поддерживает современную операционную систему. Производитель выставляет четырехзначный счет на оплату неоплаченной поддержки за 2008-2012 гг.

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

Таким образом, можно дать следующие рекомендации:

  • При долгосрочном хранении нужно принимать во внимание политику смены оборудования
  • Даже, если модели накопителей не меняются, могут измениться носители информации
  • Носители информации имеют гарантийные сроки хранения и каждые 5-7 лет их нужно пересоздавать заново

Регулярное обновление резервных копий на носителях каждые 5-7 лет

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

  • Новая копия, полученная после восстановления (все равно) будет отличаться от оригинальной
  • Контролирующие органы могут не поверить в неизменность информации, полученной после такого пересоздания
  • Процесс восстановления большого количества носителей информации может потребовать заметное количество ресурсов ИТ департамента

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

Сохранение всех версий бэкап-продуктов и всех моделей аппаратуры

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

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

Если не учитывать эти соображения, то можно столкнуться со следующим набором типовых проблем при восстановлении данных, скажем, 10-летней давности:

  • Давно устаревшая модель накопителя на лентах отсутствует на складе ИТ департамента
  • Нужный накопитель найден, но его физически невозможно подключить к серверу (например, современные материнские платы уже часто не имеют «на борту» разъемов COM, LPT и PS/2, тогда как 10 лет назад этого невозможно было себе представить)
  • Процедура тестирования восстановления ни разу не была проведена за 10 лет, поэтому при восстановлении «что-то идет не так»
  • В качестве «бонуса» к последнему пункту: продукт/аппаратура более не поддерживается производителем, гарантийный срок на аппаратуру закончился, поддержка последний раз была оплачена 5 лет назад...

В качестве заключения

В следствие вышеизложенного как предпочтительную можно рекомендовать стратегию постоянной миграции старых резервных копий на современные версии продуктов и накопителей, по мере того, как компания на них переходит. Стратегия же сохранения всех моделей аппаратных накопителей и всех версий старых бэкап-продуктов (с оплачиваемой годами поддержкой), а также необходимости постоянного тестирования восстановления на всем этом разнообразии, выглядит более затратной в многолетней перспективе и больше подвержена рискам (в частности того, что что-то будет все же забыто — то есть рискам «человеческого фактора»).

Автор: sysmetic

Источник

Поделиться

* - обязательные к заполнению поля