Резервное копирование данных не является самоцелью, а производится для обеспечения возможности
последующего восстановления. То есть планирование резервирования начинается с планирования
восстановления для каждой из возможных причин потери данных
(какой носитель содержит последнюю копию, где он находится,
как его использовать, как восстановить сервер резервирования, где описание сгоревшего сервера,
какие диски в нём были, как они были разбиты, конфигурация RAID и LVM).
Необходим мониторинг резервного копирования и процедуры тестирования для всех режимов копирования
и восстановления, включая аварийные ситуации, смену версии ОС, СУБД, системы резервирования или её замену.
Процесс резервирования и восстановления д.б. документирован достаточно хорошо, чтобы
позволить вам уйти в отпуск. Новый сервер должен [полу]автоматически включаться в систему
резервирования. На нём также удобно тестировать новую систему резервирования.
RTO (recovery time objective) - насколько быстрым должно быть восстановление
для данной группы данных и данной причины.
RPO (recovery point objective) - насколько назад по времени вы готовы потерять данные
из этой группы для данной причины. Группы данных могут быть связанными по RPO.
Периодичность и время хранения определяется потребностями бизнеса и регламентируется
правилами работы в локальной сети и рабочими инструкциями (иногда требуется система
управления версиями или CDP). Наличие регламента позволит вам сохранить работу в случае проблем.
Возможные причины потери данных и средства защиты или восстановления:
непредумышленная порча или удаление данных по ошибке пользователя;
поиск и восстановление файлов из резервной копии (может потребоваться CDP)
непредумышленная порча или удаление данных по ошибке администратора;
поиск и восстановление файлов из резервной копии (надо делать быстро!)
полный или частичный (плохие блоки) отказ диска;
для защиты данных возможно использование RAID технологии (RAID-1, RAID-5, RAID-6);
при одновременном отказе нескольких дисков из массива
требуется восстановление системы из резервной копии
физический отказ сервера; требуется мониторинг предупреждений;
требуется запасной сервер и восстановление системы из резервной копии
утрата сервера или группы серверов (кража, пожар, наводнение, ураган, ОБЭП);
требуется восстановление системы из резервной копии, хранящейся на другой территории
ошибки приложений, приводящие к удалению и порче данных;
требуется поиск и восстановление файлов из резервной копии
ошибка ОС, приведшая к повреждению файловой системы или отдельных файлов;
требуется восстановление системы или поиск и восстановление файлов из резервной копии
внезапное отключение питания, приведшее к невосстановимому повреждению файловой системы
(рекомендуется использовать файловую систему в режиме журнализации данных);
необходимо использование UPS с программным обеспечением аккуратного завершения работы
системы при исчерпании батареи, иначе требуется восстановление системы из резервной копии
порча или удаление данных в результате действий хакера или вредоносной програмы;
требуется восстановление системы из резервной копии или
тщательное расследование, поиск и восстановление файлов из резервной копии
обнаружение пропажи или порчи данных по истечении срока хранения резервных копий;
требуется архив долговременного хранения для полных ежемесячных копий
Последствия потери данных:
прямые потери для бизнеса (клиенты, заказы)
имидж компании, проблемы с надзорными органами
потери рабочего времени
неуверенность и обида сотрудников, они начинают копировать данные самостоятельно
административные последствия для системного администратора или его начальника
Дополнительные возможности, которые может обеспечить система резервирования данных:
Затраты на систему резервирования данных должны соответствовать потребностям.
Чтобы требовать денег необходимо определить:
сколько стоит потеря данных и простой на время восстановления
собрать статистику сколько раз система восстановления позволяла спасти данные
сколько "стоит" ручная самодельная система резервирования и сколько раз оператор ошибался
при установке ленты
Необходимо подготовить презентацию с описанием проблем и вашими предложениями
по исправлению ситуации, каков текущий риск и затраты, сколько надо денег,
каков будет процесс перехода на будущую систему. Презентация должна показать, что вы
обдумывали другие альтернативы и почему вы их отвергли. Как новая система будет справляться
с будущим ростом сети и до какого размера.
Процесс планирования системы резервирования и восстановления данных:
почему необходима защита данных
разбиение данных на группы
оценка стоимости потерь для каждой группы
оценка стоимости простоя на время восстановления
что необходимо резервировать:
всю систему (диск, раздел)
отдельные файловые системы
отдельные файлы
дополнительная информация (тип ОС, таблица разделов)
определение RTO и RPO для каждой группы данных и причины потери
когда:
периодичность полного и инкрементального резервирования
время резервирования
продолжительность резервирования
допустимый уровень потерь производительности производственной
системы (окно резервирования)
где должны храниться резервируемые данные: закрытое помещение или внешнее хранилище,
каталог (БД) носителей (номер, имя, место),
метки на носителях, хранилище носителей), отслеживание перемещений, считыватель штрих-кодов
для автоматизации редактирования БД, ежеквартальная инвентаризация, внешний аудит
кто будет организовывать процесс
как
Итак:
заручитесь поддержкой высшего звена (финансирование, координация, полномочия)
произведите оценку рисков (последствия различных вариантов катастроф, прогноз величины ущерба)
разработайте систему приоритетов,начиная с сетевых и информационных компонентов
рассмотрите все возможные варианты стратегии послеаварийного восстановления (и стоимость)
сбор данных (инвентаризация оборудования и ПО с датой)
подготовьте план в письменном виде (маршрутная карта подготовки плана, инструкции для
периодов до, во время и после аварии, процесс обновления плана)
разработайте процедуры проверки плана
регулярно проверяйте план в соответствии с разработанной процедурой
Опросник готовности к испытаниям
имеется ли план восстановления после аварий?
актуальны ли списки контактов?
хранятся ли копии плана в доступных после аварии местах?
сформирована ли комиссия по пересмотру планов?
собиралась ли она?
назначено ли ответственное на время восстановления лицо?
осведомлены ли начальники и подчинённые о своих обязанностях?
проинструктированы ли вновь принятые сотрудники?
проводились ли учения?
соответствует ли план и технические средства текущим потребностям?
не мешают ли они работать?
поручали ли вы оценку плана независимым экспертам?
поддерживает ли продукт большинство наших платформ (ОС, СУБД) в полном объёме
(атрибуты, ACL, fork, специальные файлы, AD, регистр, что будет при обновлении ядра?)
как сервер и как клиент; поддержка NDMP (Network Data Management Protocol) - стандартный
интерфейс с агентом резервного копирования
централизация: единая консоль управления, мониторинг, планировщик,
хранилище, БД по носителям и файлам
масштабируемость: возможность добавлять новые консоли, БД, хранилища в общую систему
возможность вынести сервера хранения и сервер БД на удалённую площадку
(интерфейс между компонентами)
может ли продукт копировать и восстанавливать разделы, MBR и диски (в т.ч. только изменения)
максимальный размер файла и файловой системы, раздел более 2ТБ, превышение размера носителя
сохранение и восстановление метаданных для всех типов файловых систем
(ctime, mtime, atime, права доступа, ACL, fork)
сохранение сопутствующей информации:
описание сервера, дисков, разделов, RAID, LVM, файловых систем
удовлетворяет ли продукт существенным повышенным требованиям по RTO, RPO, окну резервирования
резервирование данных удалённого офиса (малая пропускная способность канала передачи данных)
очень большой объём данных (не успевает в окно)
критические приложения с нулевым RTO или RPO
имеются ли механизмы обеспечивающие удовлетворение повышенных требований
LAN-free: использование SAN (FC HBA и FC коммутатор или iSCSI) позволяет уместиться в окно
Serverless (Server-Free): дисковый массив с несколькими входами подключается
напрямую к серверам с данными и серверу резервирования; на время резервного копирования
зеркало расслаивается или делается снимок файловой системы и сервер резервирования
получает данные напрямую
De-duplication backup systems: если несколько файлов на разных компьютерах одинаковы,
то делается только одна копия; если в большом файле изменяется несколько байт,
то в инкрементальную копию попадут только они; может быть реализована на уровне клиента
(меньше сетевой трафик) или сервера резервирования
снимок файловой системы на определённый момент времени; для защиты от аппаратных сбоев
его надо резервировать, но приложения на время резервирования останавливать не надо,
а снимок делается очень быстро; можно делать синхронные снимки для группы данных;
интерфейс с файловой системой (VSS) и агентами СУБД
репликация файлов или блоков на удалённую систему
near-CDP (Continuous Data Protection Systems) - регулярное создание снимков с их последующей
репликацией (или наоборот) обеспечивает возможность восстановления на моменты времени
с очень маленьким интервалом
CDP (Continuous Data Protection Systems) - при каждом изменении файла изменённые блоки записываются
в журнал на удалённом сервере, что позволяет восстановить файл на любой момент времени;
различаются методами буферизации изменений и методом (скоростью) восстановления;
очень малое окно, нулевое RPO и может иметь очень малое RTO (при поблочном методе восстановления);
CDP может действовать на уровне файловой системы или блочного устройства
может ли продукт резервировать несколько клиентов на одно устройство одновременно
(особенно важно для стримеров)
D2D2T (Disk-to-Disk-to-Tape), миграция данных, поиск в автоматическом режиме самых старых
копий, сброс их на ленту и очистка места
поддерживает ли продукт несколько резервных копирований с одного клиента одновременно
на несколько устройств хранения (большая система не успевает скопироваться за ночь);
надо ли вручную описывать несколько заданий или система может автоматически разбивать
задание по границе файловых систем или ещё более мелко
специфическая обработка данных: иногда требуется резервировать
сетевые файловые системы (NFS, CIFS/SMB), а иногда исключать их;
перед копирование может потребоваться выполнить пользовательскую программу;
специальные агенты для резервирования и восстановления БД (может использовать
API СУБД или свои методы)
наличие средств управления хранением данных
поддержка архивов (хранилище логически сгруппированной информации с возможностью
поиска и извлечения) или интерфейс к архивной системе -
лучше купить специальную программу работы с архивами
(в резервных копиях будет много мусора, искать будет очень трудоёмко, будет потрачено
очень много места, просто восстановить 10-летнюю копию будет дорого,
проблемы с совместимостью, отсутствуют метаданные, часть данных будет пропущена)
поддержка управления иерархическим хранением данных (HSM - Hierarchical Storage Management),
автоматический поиск неиспользуемых данных и перенос их "подальше" с автоматическим
возвращением при доступе
помощь в управлении жизненным циклом данных
наличие средств сокращения сетевого трафика (если под резервирование не выделена отдельная сеть):
сжатие на стороне клиента (управление силой сжатия, на каком уровне производится сжатие - поток,
файл, блок); гибкость при выборе месторасположения серверов хранения;
ограничение трафика на стороне клиента; поддержка SAN
стандартный или уникальный формат хранения; наличие автономных утилит для чтения оглавления,
проверки и извлечения файлов; доступно ли описание формата
лёгкость администрирования
сложность развёртывания
трудоёмкость обслуживания
процесс резервного копирования должен быть автоматизирован,
ручное обслуживание сведено к минимуму
изготовление копий носителей, отслеживание копий в каталоге
дублирование резервных копий (возможно собрав по кускам с разных носителей), отслеживание
копий в каталоге
создание копии копии одновременно с копией
консолидация копий сервера с целью ускорения восстановления
консолидация частично заполненных носителей с целью освобождения места
автоматическое обнаружение новых серверов, файловых систем, СУБД
возможность исключения файлов из списка сохраняемых, метод исключения
(шаблоны, регулярные выражения)
извещение о проблемах и необходимости ручного вмешательства: email (различные сообщение
на различные адреса для различных событий для различных групп серверов); API; SNMP; syslog
мониторинг: единая морда (с разбивкой по администраторам и ролям)
установка серверов и клиентов (ручная и автоматическая)
средства перехода на новую версию (ручное или автоматическое обновление)
безопасность
аутентификация между компонентами
шифрование данных при обмене между компонентами
аутентификация пользователей
ролевая авторизация: кто может только мониторить,
кто восстанавливать и какие сервера, кто может вмешиваться в процесс копирования
учёт действий пользователей
шифрование на стороне клиента
шифрование при хранении
лёгкость и скорость восстановления
независимость от платформы и версии
процесс восстановления должен быть прост и устойчив к ошибкам человека
поиск файлов по имени (шаблону), дате, хосту
параллельное восстановление с нескольких носителей
возможность самостоятельного восстановления для обычного или продвинутого пользователя
возможность заблокировать самостоятельное восстановление
восстановление на другой хост или другой каталог
восстановление с нуля (bare-metal restore), на каких платформах, степень автоматизации
как восстановить сервер резервирования (а если не работает DHCP, DNS, вся сеть?)
отслеживание версий восстанавливаемого файла
отслеживание удалённых файлов
управление перезаписыванием файлов поверх существующих
каталог: какой файл с какого клиента был записан на какой носитель и когда;
каков размер записи для каждого файла; платформонезависимость;
лёгкость восстановления каталога из резервной копии каталога;
восстановление каталога непоследственно с носителей
управление и учёт носителей (сколько времени хранить, где находится, что содержит);
метки на носителях (физические и логические), отслеживание перемещений
устойчивость к перезагрузкам серверов и клиентов, неожиданным отключениям питания,
проблемам с сетью и носителями; извещение оператора; выбор альтернативного пути
степень автоматизации работы с ленточными библиотеками, считывателями штрих-кодов,
автоматической очисткой, несколькими механизмами с горячей заменой
наличие функции проверки архива: чтение части носителя и сравнение с исходными файлами,
чтение носителя и сравнение оглавления с каталогом, чтение носителя и сравнение с исходными файлами,
чтение носителя и сравнение контрольных сумм с содержимым каталога
стоимость и принципы ценообразования (от числа клиентов, от числа устройств хранения и их типа,
от объёма, от типа поддержки
поставщик и условия поддержки, есть ли аналогичные клиенты
проблемы с лицензированием (сервер лицензий с доступом в интернет,
как восстановиться если его ещё нет)
Проблемы при смене системы резервирования:
цена покупки и развёртывания
что делать со старыми копиями
обучение персонала
риск потери данных при настройке и во время обучения
падение уровня обслуживания во время освоения продукта
Симптоматические отличия систем уровня рабочей группы и уровня предприятия:
разделение администраторов на группы с различными правами и ролями
системы уровня предприятия позволяют работать с ленточными библиотеками
системы уровня рабочей группы легче осваивать
системы уровня предприятия поддерживают больше платформ - ОС, СУБД, почтовых серверов
системы уровня предприятия интегрированы с другими продуктами (миграция данных,
обеспечение высокой доступности)
Continuous data protection (CDP) - сохранение в момент изменения
Для резервного копирования в Linux можно использовать
утилиты cpio (GNU), tar (GNU), pax, star, dd,
dump/restore (Linux: необходимо размонтировать файловую систему; Solaris: ufsdump;
SGI: xfsdump; AIX: rdump; зависимость от типа файловой системы; проблемы с совместимостью),
ntbackup, rsync/ssh.
Приведу пример использования ssh и cpio для автоматического резервного копирования
по сети:
выделяется сервер хранения backup с достаточно большим разделом под каталог /backup
скрипт do_local_backup.sh
кладётся в /root/backup.local на каждом клиенте
(а также требуемые make-file-list.sh,
make-pkg-list.sh,
fileinfo.c);
он генерирует сжатый поток в формате cpio только тех файлов,
которые не входят в состав установленных пакетов (требуется отключить prelink);
можно упростить до простейшей комбинации "find|cpio|gzip"
на сервере backup в соответствии с расписанием (через cron)
выполняется скрипт, по очереди вызывающий каждого клиента:
Фирма Veritas
купила фирму OpenVision с продуктом
NetBackup (NBU),
затем купила отделение Network and Storage Management Group у фирмы Seagate
с продуктом Backup Exec (BE), затем купила фирму Kernel Group с продуктом Bare Metal Restore (BMR).
Установка BE гораздо проще, но NBU легче в использовании, более производителен
и более универсален, хорошо масштабируется (есть примеры с 4000 клиентов).
Версия Symantec Veritas NetBackup 6.5 выпущена 15 августа 2007 года.
Symantec Backup Exec System Recovery (назывался LiveState Recovery) - восстановление с нуля.
Veritas NetBackup Bare Metal Restore.
Классическая архитектура с центральным сервером (Master) и несколькими
серверами хранения (Media Server). Имеется возможность экспорта и импорта данных
между центральными серверами.
Основной упор разработчики сделали на создании единой централизованной системы,
так что не должно быть проблем совместимости между сервером и клиентами на различных
платформах (80% - MS Windows). Имеются версии центрального сервера под MS Windows,
Linux (модулей ядра нет), Solaris, AIX. Клиенты - MS Windows, Linux, Solaris, HP-UX, ESX.
В качестве СУБД для хранения информации о носителях и файлах используется MS SQL
или Oracle (покупается отдельно) - на курсах внутри обнаружилась Sybase.
Имеется шифрование при передаче и хранении (алгоритм неизвестен),
оплачивается отдельно.
BMR (bare metal recovery) входит в состав клиента
(MS Windows, Linux, Solaris, HP-UX). ОС восстанавливается автоматически (под MS Windows PE),
данные восстанавливаются обычным путём. Возможно восстановление на новый сервер
(хранится MBR и прочие данные ). На курсах выяснилось - не входит!
CDP для MS Windows и Linux обещается в первом же обновлении за те же деньги.
Обновление вышло (6.5.1), но CDP в нём нет.
Есть автоматический повтор заданий на случай временной недоступности
клиента.
snapshot файловых систем для "тяжёлых" дисковых систем (EMC, IBM)
и Veritas File System. VSS под вопросом (в настройках есть, но мутно).
Имеется дедуплицирование данных (как отдельная опция PureDisk) - экономия до 100:1.
Модуль генерации отчётов NetBackupReporter по отдельной лицензии
(в этой версии входит в NOM).
Лицензии устанавливаются (ключ) на каждом мастере и клиенте,
нет выделенного сервера лицензий и проверки лицензий через Интернет.
Есть автоматизация обновления клиентов (через LiveUpdate), кеширование обновлений.
Своя ролевая система аутентификации и авторизации.
Первоначальный продукт CA (Computer Associates International)
ARCserve был переименован в CA BrightStor ARCserve.
BrightStor Enterprise Backup получен после поглощения фирмы Sterling Software.
Обе системы слиты воедино в версии CA ARCserve Backup r11.5 (2005).
Версия 12 ожидается в начале 2008.
Есть демо-версия
BrightStor ARCserve Backup 11.5 под Linux
(SP1, January, 2006)
и Windows (SP3, февраль 2007). Версия под Linux менее функциональна, чем под MS Windows
(нет спроса).
Сервер управления и сервер хранения не разделены,
т.е. основной сервер (ARCserve Backup Server) должен работать на компьютере,
к которому подключены устройства хранения).
Зато несколько серверов могут обмениваться данными (?) между собой,
однако общая очередь обещана только в версии 12.
Агенты ограничены по подключению к "правильному" серверу - например, агент Exchange
не может работать с сервером на Linux. Восстановление данных только в той же ОС, в которой
происходило копирование (99% - MS Windows).
В качестве СУБД для хранения информации о носителях и файлах используется MS SQL
в версии сервера для MS Windows (покупается отдельно) и Ingres в версиях под Linux и Unix
(код Ingres открыт CA в 2004 году, GPL2, бизнес продан в 2005).
Имеется возможность хранить каталог в файле LVDS (.db), но будут проблемы с масштабированием.
СУБД может быть локальной или общей для нескольких серверов.
Шифрование в версии 11.5 неудовлетворительно: шифрования канала
передачи данных нет совсем, шифрование хранения - 3DES. В версии 12 обещается AES
в обоих случаях.
Disaster Recovery (bare metal recovery) является отдельной опцией по
отдельной лицензии. Доступна для клиентов под MS Windows, Linux и Solaris.
До аварии создаётся ASR диск, хранящий информацию о разделах и дисках.
После аварии необходимо вручную установить ОС, запустить программу с ASR диска,
которая связывается с сервером и восстанавливает остальное.
В качестве быстрого восстановления есть возможность восстановления структуры каталогов.
Есть специальный агент для восстановления AD.
CDP есть и входит в базовый комплект (?).
Автоматического перезапуска неудачных заданий нет
(объясняется неразумностью такого желания в общем случае).
Возможно имитировать с помощью генерации нового задания в постскрипте при аварийном
завершении текущего задания. Имеется отдельный продукт для ноутбуков и рабочих станций,
которые не всегда включены.
Лицензии устанавливаются на центральном сервере (в т.ч. агентские
и опционные), нет выделенного сервера лицензий и проверки лицензий через Интернет.
Имеется удалённая установка агентов, в т.ч. Solaris и Linux.
Своя ролевая система аутентификации и авторизации (отдельный сервер).
Интерфейс через браузер (шифрования нет?) или командный язык.