Четыре причины пересмотреть свой механизм резервного копирования данных
Увидев в заголовке статьи фразу «резервное копирование данных», вы наверняка подумали: «Ну вот, еще один крупный специалист по безопасности будет сейчас мне рассказывать, почему обязательно делать то, что я и так уже делаю». На самом деле, речь пойдет о другом. Вспомните, когда вы последний раз обсуждали с сотрудниками отдела информационной безопасности, ЗАЧЕМ вы делаете резервное копирование данных?
Магнитные пленки с резервными копиями, в огромных количествах хранящиеся на удаленном складе, могут создать вам, отделу информационной безопасности, корпоративным и государственным аудиторам гораздо больше проблем, чем вы можете себе представить.
Суть проблемы
За последние 26 лет мне довелось неоднократно участвовать в аварийном восстановлении данных из резервных копий, и очень часто это приводило к радикальному изменению механизма резервного копирования, поскольку текущая политика в этой сфере приводила к огромным расходам или ставила компанию под угрозу административных санкций из-за невозможности восстановить данные из имеющихся резервных копий. Все это привело меня к одному простому выводу: куда разумнее вырабатывать принципы резервного копирования в зависимости от характера потенциальных внутренних и внешних требований к восстановлению данных.
Чтобы решить проблемы, связанные с резервным копированием данных, нужно прежде всего проанализировать структуру этого механизма, а затем осуществлять его периодическое тестирование. И то, и другое следует делать с учетом потенциального сценария ситуации, в которой может потребоваться восстановление данных. К наиболее распространенным сценариям такого рода можно отнести следующие:
1...Аварийное восстановление системы после критического сбоя 2...Восстановление старых данных в рамках судебного расследования 3...Восстановление данных, утраченных из-за ошибки пользователя или сбоя в программе 4...Обеспечение целостности данных
Восстановление баз данных после критического сбоя системы
Когда заходит речь о резервном копировании данных, первое, что приходит на ум — аварийное восстановление системы. Базовые настройки приложений для резервного копирования обычно рассчитаны именно на этот сценарий. Ведь мы создаем резервные копии данных на магнитных пленках главным образом именно для восстановления после критического сбоя системы. Однако многие организации по несколько лет хранят резервные копии на складах, зачастую обосновывая это обязательными требованиями государственных органов. Но ведь данные, которые могут потребоваться аудиторам или государственным органам, должны быть легко доступны, поэтому вместо того, чтобы хранить ценные биты информации на быстро портящихся магнитных лентах на пыльных полках, куда разумнее разработать более совершенную систему резервного копирования. Храните резервные копии на недорогих носителях (например, дешевых дискетах или оптических дисках) и включайте в них только данные, соответствующие обязательным законодательным требованиям.
Кроме того, необходимо создать условия для быстрого восстановления данных из резервных копий при сбое критически важной системы. Степень отрицательного воздействия сбоя сервера или информационного центра на положение компании прямо пропорциональна продолжительности работ по его аварийному восстановлению. Оно должно быть успешно завершено до истечения допустимого времени простоя. Инновационные решения в этой сфере позволяют восстанавливать системную среду даже на другой аппаратной платформе (подробнее об этом читайте в обзоре "Acronis True Image for Microsoft Windows SBS").
Другая проблема, связанная с резервным копированием, вызвана стремлением копировать абсолютно все данные, а иногда еще и на две магнитных пленки. Неограниченно долгое хранение данных, которые хранить вовсе необязательно, является одной из причин, вызывающих необходимость восстановления этих данных в рамках второго упомянутого мной сценария.
