|
|
Bog BOS: Резервное копирование и восстановление данных
|
Последнее изменение файла: 2019.04.29
Скопировано с www.bog.pp.ru: 2025.05.01
Bog BOS: Резервное копирование и восстановление данных
Целью резервного копирования данных (резервирования) является
снижение риска потери данных предприятия.
Резервное копирование данных не является самоцелью, а производится для обеспечения возможности
последующего восстановления. То есть планирование резервирования начинается с планирования
восстановления для каждой из возможных причин потери данных
(какой носитель содержит последнюю копию, где он находится,
как его использовать, как восстановить сервер резервирования, где описание сгоревшего сервера,
какие диски в нём были, как они были разбиты, конфигурация 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
- стандартный или уникальный формат хранения; наличие автономных утилит для чтения оглавления,
проверки и извлечения файлов; доступно ли описание формата
- лёгкость администрирования
- сложность развёртывания
- трудоёмкость обслуживания
- процесс резервного копирования должен быть автоматизирован,
ручное обслуживание сведено к минимуму
- изготовление копий носителей, отслеживание копий в каталоге
- дублирование резервных копий (возможно собрав по кускам с разных носителей), отслеживание
копий в каталоге
- создание копии копии одновременно с копией
- консолидация копий сервера с целью ускорения восстановления
- консолидация частично заполненных носителей с целью освобождения места
- автоматическое обнаружение новых серверов, файловых систем, СУБД
- возможность исключения файлов из списка сохраняемых, метод исключения
(шаблоны, регулярные выражения)
- интерфейс: командная строка, текстовое меню, графический клиент, Java, web-интерфейс
- извещение о проблемах и необходимости ручного вмешательства: email (различные сообщение
на различные адреса для различных событий для различных групп серверов); API; SNMP; syslog
- мониторинг: единая морда (с разбивкой по администраторам и ролям)
- установка серверов и клиентов (ручная и автоматическая)
- средства перехода на новую версию (ручное или автоматическое обновление)
- безопасность
- аутентификация между компонентами
- шифрование данных при обмене между компонентами
- аутентификация пользователей
- ролевая авторизация: кто может только мониторить,
кто восстанавливать и какие сервера, кто может вмешиваться в процесс копирования
- учёт действий пользователей
- шифрование на стороне клиента
- шифрование при хранении
- лёгкость и скорость восстановления
- независимость от платформы и версии
- процесс восстановления должен быть прост и устойчив к ошибкам человека
- поиск файлов по имени (шаблону), дате, хосту
- параллельное восстановление с нескольких носителей
- возможность самостоятельного восстановления для обычного или продвинутого пользователя
- возможность заблокировать самостоятельное восстановление
- восстановление на другой хост или другой каталог
- восстановление с нуля (bare-metal restore), на каких платформах, степень автоматизации
- как восстановить сервер резервирования (а если не работает DHCP, DNS, вся сеть?)
- отслеживание версий восстанавливаемого файла
- отслеживание удалённых файлов
- управление перезаписыванием файлов поверх существующих
- каталог: какой файл с какого клиента был записан на какой носитель и когда;
каков размер записи для каждого файла; платформонезависимость;
лёгкость восстановления каталога из резервной копии каталога;
восстановление каталога непоследственно с носителей
- управление и учёт носителей (сколько времени хранить, где находится, что содержит);
метки на носителях (физические и логические), отслеживание перемещений
- устойчивость к перезагрузкам серверов и клиентов, неожиданным отключениям питания,
проблемам с сетью и носителями; извещение оператора; выбор альтернативного пути
- степень автоматизации работы с ленточными библиотеками, считывателями штрих-кодов,
автоматической очисткой, несколькими механизмами с горячей заменой
- наличие функции проверки архива: чтение части носителя и сравнение с исходными файлами,
чтение носителя и сравнение оглавления с каталогом, чтение носителя и сравнение с исходными файлами,
чтение носителя и сравнение контрольных сумм с содержимым каталога
- стоимость и принципы ценообразования (от числа клиентов, от числа устройств хранения и их типа,
от объёма, от типа поддержки
- поставщик и условия поддержки, есть ли аналогичные клиенты
- проблемы с лицензированием (сервер лицензий с доступом в интернет,
как восстановиться если его ещё нет)
Проблемы при смене системы резервирования:
- цена покупки и развёртывания
- что делать со старыми копиями
- обучение персонала
- риск потери данных при настройке и во время обучения
- падение уровня обслуживания во время освоения продукта
Симптоматические отличия систем уровня рабочей группы и уровня предприятия:
- разделение администраторов на группы с различными правами и ролями
- системы уровня предприятия позволяют работать с ленточными библиотеками
- системы уровня рабочей группы легче осваивать
- системы уровня предприятия поддерживают больше платформ - ОС, СУБД, почтовых серверов
- системы уровня предприятия интегрированы с другими продуктами (миграция данных,
обеспечение высокой доступности)
- Continuous data protection (CDP) - сохранение в момент изменения
- развитые средства шифрования
- disk-to-disk-to-tape
- учёт носителей и файлов, где что лежит
Преимущества резервного копирования на диск
- диски дешевле ленты
- диски надёжнее
- диски предоставляют больше возможностей (например, позволяют записывать в середину массива)
- быстрый доступ к данным
- большая скорость при необходимости (RAID-0)
- позволяют полностью автоматизировать процесс резервного копирования
- ленты надо ежегодно перематывать, а через некоторое время копировать
- стримерные лентопротяжки не могут работать медленнее своей крейсерской скорости,
иначе начинают дёргаться
Недостатки резервного копирования на диск
- диски требуют более аккуратного обращения
Популярные продукты:
- персональные:
- уровня рабочей группы:
- уровня предприятия:
Для резервного копирования в Linux можно использовать
утилиты cpio (GNU), tar (GNU), pax, star, dd,
dump/restore (Linux: необходимо размонтировать файловую систему; Solaris: ufsdump;
SGI: xfsdump; AIX: rdump; зависимость от типа файловой системы; проблемы с совместимостью),
ntbackup, rsync/ssh.
Приведу пример использования ssh и cpio для автоматического резервного копирования
по сети:
- выделяется сервер хранения backup с достаточно большим разделом под каталог /backup
- на нём генерируется безпарольный ключ для ssh
ssh-keygen -t dsa -b 2048 -N "" -f ~/.ssh/backup
- этот ключ раскладывается по клиентам в root/.ssh/authorized_keys с указанием
command="/root/backup.local/do_local_backup.sh",no-X11-forwarding,no-port-forwarding,\
no-pty,no-agent-forwarding ...
- скрипт do_local_backup.sh
кладётся в /root/backup.local на каждом клиенте
(а также требуемые make-file-list.sh,
make-pkg-list.sh,
fileinfo.c);
он генерирует сжатый поток в формате cpio только тех файлов,
которые не входят в состав установленных пакетов (требуется отключить prelink);
можно упростить до простейшей комбинации "find|cpio|gzip"
- на сервере backup в соответствии с расписанием (через cron)
выполняется скрипт, по очереди вызывающий каждого клиента:
/usr/bin/ssh -T -i ~/.ssh/backup имя-клиента > \
/backup/имя-клиента/имя-клиента.`date +%Y%m%d%H%M%S`.cpio.gz
- поиск, обработка ошибок и очистка свободного места выполняются вручную
Фирма 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.
Своя ролевая система аутентификации и авторизации (отдельный сервер).
Интерфейс через браузер (шифрования нет?) или командный язык.
IBM Tivoli Storage Manager включает управление архивами, CDP покупается отдельно
- Express Storage Manager: для SMB, только Windows
- Storage Manager: для малых предприятий
- Storage Manager Extended: для больших предприятий
(Disaster Recovery Manager,
disaster recovery planning, работа с ленточными библиотеками)
Можно заказать демо (50 клиентов, 60 дней).
|
|
Bog BOS: Резервное копирование и восстановление данных
|
Copyright © 1996-2025 Sergey E. Bogomolov; www.bog.pp.ru