Stfw.RuОрганизация Backup
🕛 23.06.2006, 12:24
I. IntroНачнем с зубрения терминов и определений. Бэкапом (backup, b4kup или по-простонародному резервное копирование) назовем асинхронный, по отношению к модификации, процесс создания копии хранимой информации (данных), позволяющий восстановить предыдущее состояние данных. Процесс возврата данных в предыдущее состояние называется восстановлением (recovery). Копироваться могут файлы и данные различных приложений, такие как базы данных или почтовые архивы.
Бэкап может преследовать одну из двух целей: иметь копию данных на случай полной утери оригинала (например, из-за отказа оборудования, сбоя программного обеспечения или даже пожара) или для восстановления отдельных утраченных или испорченных файлов или каталогов.
Оперативным часто называют бэкап с копией данных, которая предназначена для быстрого восстановления в случае, если повреждение или удаление данных обнаружено немедленно после того, как это случилось (например, в течение нескольких минут или часов). Оперативный бэкап обновляется достаточно часто (один или несколько раз в сутки).
Хранимой называют резервную копию, предназначенную для длительного хранения, возможно в физически удаленном месте (off-site). Хранимые копии создаются на случай, если модификация данных обнаружена спустя длительный срок или на случай серьезных внешних обстоятельств - пожары, кражи и т.п.
Бэкап бывает локальный и сетевой. Локальным бэкап называется, если копируемые данные находятся локально по отношению к процессу копирования. Т.е. даже если мы бэкапим локальные данные на сетевой диск, это все равно будет считаться локальным бэкапом. Сетевым бэкап называется в том случае, если процесс резервного копирования обращается к копируемым данным через сеть.
По типу хранения данных можно выделить реплику, файловый бэкап (архив) и ленточный бэкап.
Реплика - это копия файлов или других данных, хранящаяся в том же виде и формате, что и оригинальные данные. Мы можем создать реплику файлов, скопировав эти файлы на другой диск или реплику базы данных, импортировав эту базу на другой сервер. Чаще всего реплики используется для создания оперативных бэкапов.
При файловом бэкапе архивируемые данные записываются в файл специального формата, называемый архивом. В архиве могут как файлы, так и данные приложений.
При ленточном бэкапе, архив располагается на заменяемом внешнем носителе. Мы не будем отдельно рассматривать бэкапы на DVD, CD или ZIP и магнитооптических дисках - в случае, если съемный носитель извлекается после копирования, такой бэкап можно приравнять к ленточному, если нет - то к файловому.
После внедрения, резервное копирование это, как правило, процесс автоматический. Оператор резервного копирования следит лишь за тем, чтобы резервное копирование прошло без ошибок, за наличием свободного места, сменой съемных накопителей и т.п. По способу восстановления, резервные копии можно разделить на восстанавливаемые пользователем и восстанавливаемые администраторам. В случае файловых или ленточных бэкапов наличие администратора восстановления, как правило, необходимо из соображений безопасности. Администратор восстановления будет иметь доступ ко всем архивным данным.
Бэкап привилегии: в POSIX совместимых системах (Linux и различные варианты Unix) пользователь root имеет возможность доступа к любым файлам, независимо от их разрешений, поэтому процесс резервного копирования обычно работает с привилегиями root. В операционных системах семейства Windows NT (Windows 2000, XP, 2003) это не так. Даже на администратора и учетную запись локальной системы действуют файловые разрешения, что может помешать процессу бэкапа. Поэтому, в Windows имеются специальные пользовательские привилегии SeBackupPrivilege (<Архивирование файлов и каталогов>) и SeRestorePrivilege (<Восстановление файлов и каталогов>), которые можно задать через локальные или доменные политики. Процесс, обладающий привилегией SeBackupPrivilege, может получать доступ к файлам на чтение, а SeRestorePrivilege - на удаление и запись независимо от файловых разрешений. Это позволяет производить резервное копирование из-под непривилегированной учетной записи, а так же изменять сведения о владельце файла, что при отсутствии подобных привилегий невозможно даже для администраторов. Кроме администраторов, по умолчанию, обе привилегии имеют пользователи группы BackupOperators.
Hintы:
Поскольку привилегии SeBackupPrivilege и SeRestorePrivilege это очень серьезные привилегии, позволяющие обойти механизмы защиты операционной системы, Microsoft рекомендует создать отдельные группы и отдельные учетные записи для резервного копирования и восстановления данных. При этом ни в коем случае не следует использовать подобные учетные записи для других задач и, тем более, для повседневной работы.
При резервном копировании по расписанию создайте отдельную учетную запись с привилегией SeBackupPrivilege и мощным паролем, запускайте задание по расписанию с этой учетной записью. Не используйте ее для других целей.
Другая проблема, возникающая в системах с принудительной блокировкой файла, опять же, в первую очередь, в Windows, это доступ к открытым файлам. Т.е. к тем, файлам, которые открыты каким-либо приложением на запись при архивировании или на чтение при восстановлении. При работе через стандартный файловый API подобный доступ не возможен, поэтому решается она по-разному.
Атрибут <архивный>: правильнее было бы перевести название этого атрибута как <архивировать>. Это битовый атрибут файла, доступный во многих файловых системах (начиная с FAT). Операционная система устанавливает этот атрибут для любого файла, открываемого на запись. Это позволяет отследить и архивировать только файлы, которые изменялись с момента, как сброса атрибута.
II. Tools
Изучаем инструментарий.
Системные утилиты копирования файлов.
В простейшем случае, для создания реплики файловой структуры можно, конечно, воспользоваться командой copy в Windows и cp или rcp в *nix. Однако возникает много вопросов, на которые эти утилиты не могут ответить - копировать или не копировать сведения о владельцах файлов, права доступа, атрибуты, что делать в случае разрыва сетевого соединения. В Windows проблема решается с помощью утилиты xcopy, которая к тому же поддерживает работу с атрибутом <архивный> и копирование по дате модификации.
Пример использования xcopy:
Xcopy d:\datafiles\*.* \\backupsrv\databackup /M /E /C /Q /G /H /R /K /X /Y 2>>d:\xcopy.log
Создает реплику каталога d:\datafiles в \\backupsrv\databackup, при этом копируются только файлы и каталоги, включая пустые, измененные с последней процедуры копирования (инкрементально) с любыми флагами (включая скрытые и системные), а так же копируются флаги, разрешения и параметры аудита, копирование не прекращается при любых ошибках, не дается запросов на перезапись файла.
Hintы:
При запуске из командного процессора (cmd.exe) 2>>d:\xcopy.log перенаправляет поток стандартной ошибки stderr (дескриптор 2) в конец файла d:\xcopy.log. Это стандартный прием, который можно использовать в командных файлах (.bat или .cmd) для сохранения журнала и поиска ошибок. Однако, такое перенаправлени не сработает при запуске xcopy через меню <Пуск> или по расписанию. В таком случае следует запускать xcopy через cmd (cmd.exe /C Xcopy.
К реплике можно дать доступ на чтение пользователям для самостоятельного восстановления файлов.
Утилита robocopy (Robust Copy) из Resource Kit для Windows или rsync для *nix позволяют, кроме того, синхронизовать каталоги (удалять файлы, которых нет в источнике, копировать файлы если они новее чем имеющиеся и т.д.). У Robocopy для этого есть полезный ключик /MIR. Следует иметь ввиду, что Robocopy /? дает не полный список возможных ключей, полный список можно найти в файле robocopy.doc. Robocopy имеет большое количество опций по управлению процессом копирования и журналирования.
Службы репликации:
Служба репликации Windows (File Replication Service, FRS) позволяет синхронизовать несколько каталогов друг с другом.
Рис: репликация в DFS
Служба репликации предназначена, в первую очередь, для распределения нагрузки между серверами и распространяет изменения достаточно быстро, однако можно запретить репликацию данных в рабочее время, что позволяет использовать FRS и в качестве инструмента оперативного бэкапа. Управлять репликацией легче всего через оснастку управления распределенной файловой системой DFS, хотя FRS может работать и отдельно. File Replication Service поддерживает практически любое число реплик и позволяет управлять расписанием и топологией репликации, т.е. изменения могут передаваться не от каждого к каждому, а по цепочке, хотя для организации резервного копирования все это не очень интересно. Репликация является двунаправленой, т.е. изменения можно вносить в любую из реплик.
Честно сознаюсь, что ни разу не сталкивался со службами файловой репликации под *nix, но уверен, что они существуют. Коммерческие решения для репликации так же существуют, например у Veritas (Symantec).
Архиваторы.
Сегодня уже выглядит неочевидным, что архиваторы, такие как tar, pkzip или rar, создавались как средства резервного копирования, но это именно так. И если pkzip по какой-то необъяснимой причине движется в сторону сетевых сервисов, в продукте PKZip Server появилась поддержка FTP и электронной почты, то консольная версия rar остается вполне пригодной для резервного копирования. О tar речь пойдет отдельно. Разумеется, все архиваторы поддерживают работу с архивным битом и архивирование по дате модификации. Многие поддерживают синхронизацию архива. Но Rar, кроме того, умеет использовать backup-привилегии и поддерживает доступ к открытым файлам (точнее сказать к большинству, могут быть проблемы, например, с доступом к файлам которые отображены в виртуальную память). Так же могут архивироваться NTFS-потоки, информация о безопасности и есть всякие вкусности, полезные при резервном копировании по расписанию и длительном хранения данных на внешнем носителе, например добавление информации для восстановления данных при физическом повреждении.
Hintы:
Архиваторы часто используют временный файл при создании архива, и только по окончании архивации переименовывают его. Чтобы процесс переименования проходил без копирования данных необходимо, чтобы временный файл создавался на том же томе, на котором будет храниться архив. Расположение временного файла, как правило, можно указать через ключи.
Не стоит засовывать все данные в один архив, т.к. извлечение одного файла из архива может оказаться длительным процессом. Лучше создавать отдельный архив, например для каждого корпоративного каталога. Кстати, при такой стратегии потребуется меньше места на временный файл.
Сохраняйте список файлов, вошедших в архив, чтобы, при необходимости, легче было найти, в каких архивах имеются версии файла, который нужно восстановить. Очень часто пользователи не помнят точного расположения. Построение списка файлов по архиву может занять много времени. Если архиватор не поддерживает создание списка в отдельном файле при архивировании, используйте перенаправление вывода в командной строке, как это было показано раньше.
Утилиты ленточного копирования.
Из штатных утилит, это, конечно же, tar для * nix и ntbackup для Windows. Не стоит забывать, что TAR это Tape ARchiver и формат tar ориентирован на хранение данных на ленте. Обычно, tar используется совместно с rmt или другой утилитой управления ленточным носителем.
NTBackup является облегченной версией, без поддержки сетевых служб, мощного коммерческого решения Veritas Backup Exec. Это вполне приемлемое решение в большинстве мелких/средних сетей с небольшим количеством серверов.
Подробный обзор этих утилит делать не будем - такого добра в сети навалом. Но надо отметить, что в Windows XP и Windows 2003 ntbackup использует технологию теневого копирования тома, что позволяет избежать проблем с открытыми файлами и несовпадение версий файлов (когда копия одного файла снята по времени раньше копии другого, а файлы должны использовать совместно).
Hintы:
Лучше не использовать мастер резервного копирования в Windows. Во-первых, список файлов создается в профиле пользователя и, если задание будет запускаться из-под другой учетной записи, оно не сможет туда обратиться. Во-вторых список создается в Unicode-формате и, как показывает опыт, в Windows 2000 иногда, при невыясненных обстоятельствах, возникают <глюки> с его распознаванием. Лучше хранить список файлов в обычном тексте.
Сам формат tar не поддерживает сжатия, но позволяет подключать внешний архиватор (ключики -z или -gzip, -Z или -compress, -j или -bzip2). gzip имеет слабую степень сжатия, а bzip2 очень сильное потребление процессора, так что приходится выбирать. Поддерживается так же ключик -use-compress-program, позволяющий указать программу сжатия.
Коммерческие сетевые Backup-решения.
Идеология сетевых бэкапов - центральный сервер, управляющий процессом копирования и агенты, которые устанавливаются на различные системы для обеспечения доступа к данным. В процессе, серверная часть получает копируемые данные через агентов. Агент для Windows, например, может обеспечивать еще и доступ к открытым файлам. При этом нет необходимости доступа к данным через какие-то другие сетевые службы, такие как сеть Microsoft (CIFS) или NFS и возможен доступ не только к файловой информации, но и к данным приложений. Классическими решениями являются Brightstor ArcServe (перекуплен Computer Associates) и различные продукты Veritas BackupExec, NetBackup и иже с ними (перекуплен ). На скриншотах - попавшаяся под руку не очень свежая версия ArcServe, я бы рекомендовал все-таки продукты Veritas, но идеология очень схожая.
Hintы:
Не забывайте делать бэкап базы данных самого сервера резервного копирования, желательно отдельно от всего остального, иначе процесс восстановления будет нетривиальным.
Настоятельно рекомендуется добавить дополнительный сетевой адаптер в сервера хранящие данные. Это убивает сразу несколько Му-Му: трафик backup не засоряет основной сетевой сегмент, исключается возможность прослушивания трафика, который, как правило, не шифрован. Можно запретить доступ к агенту из основного сегмента, а безопасность агента Backup - самое тонкое место в сетевом бэкапе.
Microsoft Windows Server Data Protection Manager 2006
Весьма интересный новый продукт из линейки Windows Server, который нельзя засунуть ни в одну из имеющихся категорий. Продукт свежий, ошибки есть даже на картинке компакт-диска распространяемого среди партнеров, но идея очень любопытная. Фактически, DPM это сетевое расширение технологии теневого копирования тома ( Volume Shadow Copy), которая описывалось в статье <Нужен ли бэкап>.
Как и в классическом сетевом бэкапе на клиентские компьютеры устанавливаются агенты, причем делается это непосредственно с сервера. Агенты передают на сервер теневые копиии по заданному расписанию (до 8 раз в сутки). Преимущества такой технологии просто огромны: Shadow Copy создается на уровне дисковых блоков и передаются лишь изменения файлов. Оъем передаваемой по сети и хранимой информации минимален. Можно хранить огромное количество версий файла, занимая относительно не много места. Поиск нужных версий легко осуществляется при необходимости восстановления. Устраняется проблема открытых файлов.
Как и в случае с теневой копией, восстановление может быть произведено самим пользователем через версии файла. Кроме того, PDM интегрируется в ntbackup, что позволяет легко сбросить <образ> удаленного компьютера на ленту, не обращаясь к нему по сети. Основной недостаток - все это, и сервер DPM и агенты для файловых серверов, работает только с Windows 2003 SP1. Восстановление предыдущей версии файла возможно так же из-под Windows XP или Windows 2000 SP4. Но будущее этой технологии обеспечено.
III. Strategy
Ну а теперь поговорим о том, как со всем этим правильно жить. Порцесс резервного копирования состоит из трех стадий: планирования, внедрения и поддержки. О поддержке и внедрении мы уже немного поговорили, по планирование - самая важная стадия. И определиться с тем, какие данные бэкапить и насколько часто - это еще не планирование.
Hintы:
Невозможно организовать эффективное резервное копирование в среде, где нет централизованного хранения данных. Поэтому, заранее необходимо обеспечить, чтобы все данные пользователя хранились на файловых серверах. Необходимо рассмотреть возможность внедрения роуминговых профилей или перенаправления системных папок (таких как <Мои Документы>) на сетевой диск. Пользовательский компьютер должен быть легко заменяемым, бэкапить его почти бессмысленно. Если в организации не автомаизирван процесс установки системы и приложений, то можно один раз создать копию системного раздела после того, как все установлено.
Другая проблема - это хранение лишней информации на файловых серверах. Рано или поздно там оказываются фотографии, MP3 и видео - все это не имеющее отношения к рабочему процессу. Опыт показывает, что хорошо помогает внутренняя тарификация по подразделением за использованное дисковое пространство или система штрафов. Но важно не переборщить, иначе пользователи будут хранить данные локально.
Принимая во внимание возможность сбоя, например сервера базы данных, в который грузится информация в реальном времени, необходимо организовать процесс сбора информации так, чтобы она могла где-либо накапливаться до того, как попадет в базу, чтобы не допустить существенных потерь информации во время простоя.
Необходимо выработать несколько документов:
План резервного копирования
Инструкцию оператора резервного копирования
План аварийного восстановления
Инструкция администратора аварийного восстановления
Инструкция пользователей
План резервного копирования это самое простое. Но он должен быть исчерпывающим. Для его составления должны привлекаться пользователи, т.к. зачастую только они могут классифицировать свои данные, чтобы определить содержание оперативных и хранимых бэкапов. Обязательным должно быть указание где, как и сколько хранить копии, как осуществлять к ним доступ и какими полномочиями необходимо для этого обладать, как контролировать процесс резервного копирования. Необходимо так же регулярно проверять целостность архивов, проводить контрольное восстановление данных. По плану производится внедрение резервного копирования с использованием доступных средств и затем составляется инструкция оператора.
Пример из реальной жизни. Телекоммуникационная компания. Имеется план резервного копирования, которое регулярно производится. Однажды, в разгар рабочего дня, из-за сбоя SCSI драйвера <запарывается> содержимое дисков на RAID-котроллере основного сервера баз данных, через которую осуществляется биллинг и управление услугами. Единственным выходом остается восстановление из бэкапа. Администраторы пытаются приступить к процессу, но оказывается: 1. Процесс восстановления много-гигабайтной базы занимает длительное время, причем спрогнозировать его они не в состоянии. 2. Клиенты не могут воспользоваться услугами, и, вместо восстановления базы данных, приходится искать временное решение, которое позволило бы использовать хотя бы основные услуги. 3. Весь этот процесс сопровождается постоянными звонками доброжелателей из различных подразделений, указывающих на проблемы с базой. 4. Никто не знает что делать, чтобы реанимировать базу и систему в целом после процесса восстановления и приходится читать документацию. 5. Когда база, наконец, приведена в рабочее состояние, выясняется, что есть накопленная за это время биллинговая информация, но нет никаких средств для ее обработки и загрузки. 6. После написания на ходу и на коленке, без тестирования, необходимых утилит выясняется, что часть записей оказалась продублирована и их необходимо вычистить. Итог: процесс полного восстановления занял свыше 5 дней. 7. Через еще через 2 дня происходит аналогичный сбой SCSI драйвера.
В чем ошибка? Во-первых в отсутствии резервного сервера, который бы синхронизировался с основным и который можно было бы быстро пустить на замену. Во-вторых в отсутствии правильного плана аварийного восстановления и инструкций. План должен предусматривать не только то, какая информация откуда и куда восстанавливается. План аварийного восстановления должен предусматривать возможность введения <аварийного> режима работы системы на время сбоя - например, без подключения новых услуг но со сбором биллинговой информации. Аварийный режим должен предусматривать и оповещение сотрудников или перевод звонков на службу поддержки пользователей. Возможно, усиление службы поддержки за счет сотрудников других подразделений, чтобы справиться со звонками пользователей. План должен предусмотреть действия, которые необходимо предпринять после аварийного восстановления старых данных. Естественно, все это для разных категорий данных. Процесс восстановления должен быть оттестирован, для этого он должен проводиться регулярно, чтобы учесть возможные изменения системы. По результатам тестирования в плане должны быть указаны все ожидаемые сроки и то, какие операции можно распараллелить. Кроме того, план обязательно должен включать пункт о необходимости анализа причин сбоя и их устранения, причем первичная диагностика должна быть до начала процесса восстановления данных, а по окончании работ должна производиться полная диагностика и устранение причин сбоя, чтобы не допустить повторения проблемы.
По плану аварийного восстановления составляются инструкции администратора. Разумеется, план должен предусматривать и восстановление отдельных файлов по запросу пользователей.
Пользовательская инструкция так же не является лишней. Очень часто весь процесс резервного копирования оказывается почти неэффективным лишь потому, что пользователи не знают о возможности восстановления файлов. Задачи пользовательской инструкции - информировать о том, какие данные, за какой срок и как можно восстановить и кому для этого нести пиво. Пиво, кстати, в данном случае является хорошим дисциплинирующим фактором, т.к. иначе пользователи будут халатно относиться к своим данным. Важно только не переборщить с запросами, иначе пострадают пользователи, почки и ни в чем не повинный почтовый сервер.
IV P.S.
Надеюсь, теперь все достаточно напуганы, чтобы понять, что процесс бэкапа это не просто ntbackup запущенный через меню Пуск. Это лишний повод собраться, выпить кружку чая, обсудить и пошевелить мозгами. Настоятельно рекомендуется все это делать регулярно.
Перепечатка данной статьи невозможна без разрешения издательства Gameland