X

Напишите нам!

X

Стать партнером!

X

Запланировать бесплатное тестирование Palo Alto Networks

Резервные копии не заменят архивирование

23 декабря 2008

Создание резервных копий и архивирование выполняют совершенно разные функции. Задача архивирования —сохранить документы, файлы и электронные письма таким образом, чтобы даже по прошествии многих лет их можно было легко и быстро найти с помощью заданных критериев поиска. Кроме того, необходимо обеспечить подлинность документов. А резервные копии позволяют максимально быстро восстановить данные на какой-то определенный момент времени.

При разработке проектов по архивированию следует заранее определить ближайшие и отдаленные цели: повышение производительности, соблюдение правовых предписаний (Compliance) и т.д. К примеру, если кому-то из сотрудников дается задание на доработку некоего устройства, то ему сразу же понадобятся определенные документы, в частности, самая новая версия соответствующего файла и информация о том, где и кем он обрабатывался в прошлом. Если изображение не переведено в цифровую форму, а существует лишь на бумаге и находится в другом месте, то продуктивная работа невозможна. Однако даже если все необходимое имеется в цифровом виде, но не классифицировано и не снабжено однозначными характеристиками, то собрать информацию в полном объеме очень трудно. При поиске на файловых серверах, как правило, очень трудно выбрать самую последнюю редакцию чертежа и понять, кто с этим файлом работал ранее.
 
Если решение для архивирования должно отвечать требованиям аудита, то обязательно учитываются сроки хранения документов. Согласно параграфам 239 и 257 торгового кодекса, а также параграфу 147 налогового законодательства ФРГ, сроки хранения договоров в Германии составляют от шести до десяти лет. В отдельных отраслях они увеличены до 20(торговля земельными участками) и 30 (медицинские карты) лет.
 
Нормативный акт «Принципы надлежащего бухгалтерского учета с применением средств электронной обработки данных» (Grundsaetze ordnungsgemaesser, Datenverarbeitung gestuetzter Buchfuehrungssysteme, GoBS) регулирует обращение с данными в архивных системах, «пригодных для аудита». При необходимос-ти предприятие должно доказать, что оно соблюдает все требования, предъявив документы, соответствующие GoBS. В этой связи следует также упомянуть о вопросах соблюдения законодательства в определенных отраслях экономики: речь идет о таких актах, как Sarbanes-Oxley, Basel II или Bafin.
 
Архивирование осуществляется на два основных типа носителей. Во-первых, это решения с однократной записью и многократным чтением (Write Once, Read Many, WORM) в виде автозагрузчиков дисков DVD: цифровая информация записывается на DVD, и ее уже нельзя изменить. Вторая возможность — системы адресации хранения по содержимому (Content Addressed Storage, CAS) со специальными жесткими дисками, когда для однозначной идентификации оцифрованная информация снабжается индивидуальным отпечатком (Fingerprint), присваиваемым архивируемому файлу. 

Архивирование документов.


Вначале, помимо определения требований ИТ, следует выяснить, какие документы требуется архивировать. Нужна ли классификация, и если да, то по каким признакам? Специализированное ПО для архивирования документов поддерживает функции индексации и поиска информации, а их учет упрощается благодаря концепциям классификации. Обычно программное обеспечение предоставляет интерфейсы к различным стандартным приложениям. Если требуется долгосрочное хранение, надо подумать и о том, что спустя какое-то время то или иное приложение уже не будет использоваться, поэтому понадобятся специальные конвертеры или программы для просмотра документов. Конвертация в форматы TIFF и PDF считается надежной с точки зрения ее воспроизведения в будущем, но она должна осуществляться с сохранением всех метаданных и возможностей поиска.

Резервное копирование.


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

Резервное копирование баз данных.


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

 
Для противодействия этому явлению поставщики соответствующих решений разработали интерфейсы оперативного резервного копирования, такие как Oracle Recovery Manager (RMAN). Теперь вместе с интерфейсами к клиентским программам резервного копирования данные можно сохранять напрямую — из базы данных на носитель резервной копии. Одновременно механизмы RMAN позволяют сохранить все, что необходимо для обеспечения согласованности резервных копий.
Клаус Зандер — менеджер по услугам центра обработки данных компании BT Germany. 

Особенности архивирования электронной почты в России.


Архивирование и создание резервных копий не одно и то же. Первое предусматривает постоянное сохранение новых объектов данных, что позволяет отследить очередность их изменений и быстро восстановить интересующую версию файла. Второе подразумевает создание среза информации на определенный момент времени. Таким образом, при резервном копировании возможна потеря промежуточной информации: если в интервале между двумя срезами файл изменялся несколько раз, то восстановить документ удастся только на определенный период времени. Архивирование же позволяет последовательно воспроизвести все изменения.
 
Применительно к электронной почте это означает, что только архивирование позволяет сохранить всю переписку пользователей, как этого требуют регламентирующие документы или внутренняя политика безопасности. В случае резервного копирования любой пользователь, в том числе и злоумышленник, в интервалах между созданием резервных копий может удалить с сервера либо часть сообщений, либо все сразу, и резервная копия окажется «пустой». Архивирование позволяет копировать каждое письмо, и, удалив его, пользователь не сможет повлиять на состояние архива.
 
Реалии российского рынка таковы, что ведение архива носит добровольно-рекомендательный характер. В США и странах Европы другая ситуация: если компания заявляет о соответствии требованиям стандартов FOIA, ISO 17799, ISO 13335, SOX, HIPAA, то ведение архива электронной почты является для нее обязательным. Сегодня на рынке не так много реально работающих решений (как программных, так и аппаратных). Основная проблема, с которой сталкиваются пользователи, заключается в поддержке решением либо всего одной платформы (Windows, UNIX или Linux), либо единственного продукта (в большинстве случаев это Microsoft Exchange Server). Кроссплатформенное решение с поддержкой всех протоколов и видов серверов (POP3, IMAP, Exchange, Domino и др.) до определенного момента никто не предлагал.
 
Еще один сложный и важный вопрос — время поиска. Одна из российских банковских структур на горьком опыте убедилась в необходимости установки системы архивирования после того, как для разбирательства в европейском суде пять ее сотрудников вынуждены были потратить неделю, чтобы найти и восстановить в системе резервного копирования искомую переписку. После инцидента заказчик осознал необходимость в такой системе архивирования, которая, во-первых, требовала бы меньших трудозатрат при поиске сообщений и, во-вторых, обеспечивала бы архивирование всей электронной почты компании и возможность дальнейшего использования при проведении как внутренних, так и внешних расследований.
 
На практике ведение архива электронной почты позволяет отстоять в суде как личные интересы, так и интересы компании. В Европе и США предоставление истории таких сообщений считается обычной практикой, причем во многих странах это требование является обязательным, а срок давности архива достигает 20 лет. В России существует несколько документов, регламентирующих ведение архива. Наиболее актуальные: Федеральный закон «Об архивном деле в Российской Федерации» и СТО БР ИББС-1.0-2006. К сожалению, российского опыта использования электронной почты в качестве доказательств в суде недостаточно для того, чтобы назвать это обычной практикой, но случаи не единичны, и судьи все чаще рассматривают электронную переписку как один из аргументов. Как бы то ни было, до определенного момента внедрение системы архивирования будет личным делом каждого руководителя. Однако примеров и доказательств в пользу ведения корпоративного архива тысячи, и рано или поздно его эффективность оценят все руководители, уважающие репутацию и интересы своей компании.

Источник: LAN 
Автор: Клаус Зандер

netwell_logo_sm.jpg


537
(0)