О необходимости создания резервных копий информации говорить можно много, но, к сожалению, как показывает мой опыт, ничто так не агитирует за серьезное отношение к бэкапу, как факт серьезной потери критичных данных (и весьма частые последующие “оргвыводы” в отношении “крайних”).
Ну, а пока это в вашей компании не случилось, давайте рассмотрим возможные методы и средства защиты.
Самое простое и самое понятное – так называемый Full Backup. Мы берем все наши данные и делаем их физическую копию. По окончании Full Backup мы будем иметь все наши даные в двух экземплярах, один – в оригинале, второй – в копии. Оба экземпляра полностью идентичны. Все просто и понятно – это плюс. Минус же заключается в том, что полная копия занимает ровно столько же места, сколько оригинал. Да и сам процесс создания копии может занимать значительное время. Хорошо если это папка “Мои Документы” вашего ноутбука, а если это полная копия терабайтного хранилища?
А ведь копию придется регулярно возобновлять, ведь если данные изменяются во время работы, то наша полная копия уже не будет копией. Значит ежедневно нам придется копировать терабайт во вторую копию, весь, целиком. А если мы хотим иметь несколько копий, например, позавчера и неделю назад? Готовьте место * N.
Итак минусы: объем копирования – время, место и загрузка мощностей при копировании, а также большое количество занятого места при множественных копиях.
Логичный выход из затруднения – инкрементальный (incremental) бэкап. Если за рабочий день изменяется всего лишь малая часть данных, то можно после первого полного бэкапа сохранять только изменившиеся файлы.
Но как же мы найдем эти изменившиеся файлы среди тысяч имеющихся?
Тут на помощь к нам приходят так называемые “атрибуты файловой системы”, специальные битовые поля, которые указывают свойства файла. Когда задумывалась структура файловой системы, то для специальных признаков файла были предназначены “флаги”-признаки, принадлежащие файлу наряду с его именем и, например, расширением.
Атрибуты есть даже в такой примитивной файловой системе, как FAT.
Классический набор атрибутов это признаки “только для чтения” (он устанавливается, если операционной системе запрещено файл удалять или записывать в него), атрибуты “скрытый”, “системный”, а также атрибут под названием “archive” – “архивный”. Этот атрибут выставляет OS в том случае, если файл как-либо изменяется средствами OS.
Если мы, проводя резервное копирование, сбросим у всех файлов этот флаг, то как только какой-то из файлов будет изменен, то OS вновь устновит бит-”флаг” “archive” для этого файла. Если теперь мы просмотрим атрибуты, то все файлы с выставленным флагом archive – это те файлы, которые нам надо сохранить “в архив” в инкрементальной копии.
Конечно, после сохранения мы (вернее, наша программа резервного копирования) вновь атрибут сбросим.
Это самый простой способ определения файлов для инкрементальной копии, поддерживаемой средствами самой OS.
Таким образом, каждая резервная копия будет состоять из одной полной и множества инкрементальных копий.
Однако, резервное копирование делается не столько ради него самого, как такового копирования, сколько ради возможности быстрого восстановления информации из него. Как же будет выглядеть процесс восстановления в такой схеме?
Нетрудно видеть, что для восстановления в схеме Full Backup + Incremental нам будет нужно восстановить сперва Full, а потом последовательно восстановить на него содержимое всех сделанных с момента Full Backup инкрементальных копий.
Почему недостаточно только последней?
Допустим мы имеем на диске файлы A, B, C и D.
После создания полной копии, в которую попали все 4 файла, мы изменяем в понедельник файл A и B. В инкрементальную копию понедельника попадут два измененных файла A и B. Во вторник изменим файл C и занесем его в инкрементальную копию вторника, однако файла A и B не изменялись во вторник, а значит в задание на копирование для вторника они не попадут.
В среду наши данные оказались повреждены. Если мы восстановим полную копию, а затем только последнюю инкрементальную, то мы потеряем все изменения для файлов A и B понедельника, что, конечно же, никуда не годится.
Поэтому мы вынуждены считать и восстановить данные со всех инкрементальных копий.
По этой причине стратегия Full + Incremental характеризуется быстрым процессом копирования, но значительно более медленным восстановлением, чем в случае Full Backup, ведь нужно последовательно прочитать множество ежедневных копий.
По этой причине стараются ограничить количество инкрементальных копий (как бы ни было привлекательно с точки зрения бэкапирования ограничиться только ими) и производить периодические полные копии. Наиболее популярная и распространенная стратегия это: суббота после окончания рабочей недели – full copy, ежевечерне, по окончанию рабочего дня – incremental.
Однако, в последние годы ряд производителей ПО резервного копирования предлагает функцию “постоянного инкрементального бэкапа”, при котором софт резервного копирования самостоятельно собирает внутри себя из множества инкрементальных копий “контрольные точки”, “псевдо-full backup”. Так, например, работает Tivoli Storage Manager, эта функция иногда встречается теперь и в системах резервного копирования других производителей.
Логичным выходом из ситуации с последовательным восстановлением был бы вариант, когда последняя резервная копия несла бы в себе все измененные по сравнению с Full Backup файлы, то есть разницу между Full и текущим положением, при этом из примера сверху в первый день в нее также попали бы файлы A и B, а во второй – три: A, B и C.
Такая схема называется Differential. За счет некоторого увеличения объема копии мы экономим время восстановления, ведь нам нужно восстановить всего 2 копии, большую Full и одну, последнюю, Differential.
При работе с атрибутами файлов при методе differential атрибут “archive” после копирования не сбрасывается. Таким образом в ежедневную копию попадают последовательно все измененные сегодня и ранее файлы, пока не придет время нового Full Backup, который и очистит все атрибуты “archive”.
Выбор стратегии остается за администратором: что для него важнее – более экономный расход места и более быстрое завершение процесса копирования для метода incremental или более быстрый процесс восстановления за счет большего расхода места и времени для метода differential?
Еще один метод, часто встречающийся в ПО, это метод daily backup. При этом в такой “ежедневный бэкап” попадают файлы измененные за день. Для определения файлов, которые следует сохранить, используется как бит “archive” так и дата последнего изменения файла.
Однако большинство этих методов родилось в доисторические времена, когда пары флопиков было достаточно для хранения резервных копий.
Сложности стали возникать при резервном копировании больших файлов.
Например почтовая база MS Exchange или большая база данных есть некий весьма обширный, во много сотен мегабайт размером файл. Но даже если внутри этой базы изменился один символ или добавилось одно письмо в килобайт размером, мы будем вынуждены сохранить его в инкрементальной копии целиком, все много сотен мегабайт заново. Ведь с точки зрения OS файл – изменился, и файловая система взведет флаг “archive”.
Для выхода из этой ситуации входит в применение метод т.н. continuous backup, появившийся, например, в такой системе как Symantec (ранее Veritas) Backup Exec, и постепенно появляющийся также в других продуктах в той или иной форме.
При этом методе на OS устанавливается программа-агент, которая отслеживает операции ввода-вывода, и, работая на “блочном” уровне, передает каждый изменившийся блок, непосредственно после его изменения, в программу-сервер, уже не обращая внимания на примитивные атрибуты файла. Кроме возможности экономично бэкапить большие слабоизменяемые файлы, этот “гранулярный” метод позволяет также улучшить оперативность резервного копирования, ведь при этом резервное копирование получается “continuous” – непрерывное, производящееся непосредственно после изменения, а не раз в день вечером.
Основные игроки на этом рынке в настоящее время это:
ранее Veritas, а ныне, после покупки компании Veritas компанией Symantec – Symantec Backup Exec, ориентированный прежде всего на платформу Windows, и его “старший брат”, многоплатформенный и гораздо более дорогой NetBackup.
Legato, а ныне EMC Software и их продукт класса названного выше NetBackup – Networker (когда-то первая система сетевого резервного копирования вообще).
Относительно широко распространена система, входящая в семейство программных продуктов Tivoli компании IBM – Tivoli Storage Manager, характеризующийся традиционной для IBM широчайшим функционалом и запредельной сложностью в настройке ;)
Часть продуктов имеет локальную распространенность. Так сравнительно широко распространенный у нас в стране CA ARCserve стал популярен вследствие весьма щадящей лицензионной политики CA.
Немецкая компания Commvault производит относительно малоизвестный, но довольно интересный продукт Galaxy, сильной стороной которого является хорошая интеграция с продукцией Microsoft (Commvault когда-то был инженерным подразделением MS в Германии).
Характерный для компаний с присутствием французского капитала Atempo Time Navigator имеет те же корни популярности, что Kaspersky Antivirus или The Bat у нас в стране – это французская программа.
Ну и наконец рано или поздно Microsoft сам доделает свой Data Protection Manager v.2, и такой мощный игрок на рынке безусловно заставит почувствовать себя неуютно множество конкурирующих в этой области компаний.
Среди систем резервного копирования “персонального класса” следует упомянуть такие имена как Genie-Soft Backup Manager (которой пользуюсь я на своем десктопе) или Dantz Retrospect, некоторое время купленный EMC, с тем чтобы дополнить собой в сегменте начального уровня мощный, но дорогостоящий и сложный продукт Legato Networker. Возможно, эти программы и не столь мощны, как перечисленные выше, не умеют взаимодействовать с централизованным управляющим сервером и копировать данные на огромные медиа-библиотеки, но вполне справляются с задачей защиты данных локального настольного компьютера или ноутбука.
Взято с блога about NetApp
One Comment