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


    В соответствии с законодательными требованиями, отраслевыми нормативами и корпоративными политиками от компании могут требоваться длительные сроки хранения корпоративной информации (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 лет назад...

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

    В следствие вышеизложенного как предпочтительную можно рекомендовать стратегию постоянной миграции старых резервных копий на современные версии продуктов и накопителей, по мере того, как компания на них переходит. Стратегия же сохранения всех моделей аппаратных накопителей и всех версий старых бэкап-продуктов (с оплачиваемой годами поддержкой), а также необходимости постоянного тестирования восстановления на всем этом разнообразии, выглядит более затратной в многолетней перспективе и больше подвержена рискам (в частности того, что что-то будет все же забыто — то есть рискам «человеческого фактора»).
    • +6
    • 12,1k
    • 4
    Veeam Software
    133,00
    Продукты для резервного копирования информации
    Поделиться публикацией

    Комментарии 4

      0
      Мы живем в будущем! Теперь хранение бэкапов можно аутсорсить, например, на Amazon Glacier (стоимость хранения одного терабайта в год составит 125 долларов, что для серьезной компании — практически бесплатно).

      Вся головная боль из сабжа в таком случае ложится на поставщика сервиса, который обязуется соблюдать условия оказания услуги. :)
        0
        Может, мы и живем в будущем, но вот только законы и проверяющие/регулирующие органы живут в прошлом. Не знаю как в России, но в Украине, если у вас в бекапе лежат персональные данные — забудьте про облака:(.

        И не совсем понимаю, как с помощью указанного вами сервиса решается проблема старых бекап-продуктов, т.к. там предлагается только место под архив — сам архив еще нужно как-то сделать.
          0
          > Не знаю как в России, но в Украине, если у вас в бекапе лежат персональные данные — забудьте про облака:(.

          Та же фигня. :( Но всякие паспортные данные можно хранить в относительно маленькой базе, а по поводу пользовательских файлов можно, наверно, в EULA оговорить хранение на Амазоне.

          > И не совсем понимаю, как с помощью указанного вами сервиса решается проблема старых бекап-продуктов, т.к. там предлагается только место под архив — сам архив еще нужно как-то сделать.

          Делать можно любыми имеющимися в наличии средствами, не заботясь об их phase out'е. Ведь хранить локально бэкап длительное время не требуется: сделал бэкап рядом со вчерашним, залил на Амазон, стер вчерашний.

          А если вы о том, как перезалить на Амазон старые бэкапы, то и сабж ответа на этот вопрос не дает. В статье описаны способы предотвращения проблемы. А если заранее не позаботился, то так и так покупать на барахолке старое оборудование.
          +1
          Именно бэкапить на Glacier — крайне плохая идея. Потому что восстанавливаться из этого «бэкапа» придется до морковкина заговения.
          На самом деле Amazon Glacier это не backup, а archive storage, а это совершенно другого класса задача.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое