Не допустите потери данных! Ленточная библиотека к вашим услугам::Журнал СА 6.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5101
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6343
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7599
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7922
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6979
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 Не допустите потери данных! Ленточная библиотека к вашим услугам

Архив номеров / 2007 / Выпуск №6 (55) / Не допустите потери данных! Ленточная библиотека к вашим услугам

Рубрика: Администрирование /  Продукты и решения

Виталий Банковский

Не допустите потери данных! Ленточная библиотека к вашим услугам

Какое самое кошмарное событие в работе системного администратора? Правильно, потеря всех данных. Тогда он вспоминает, что собирался сделать архивирование данных в 1995 году. Знакомо? Если еще нет – тогда эта статья для вас.

Итак, предстоит задача оценки и внедрения системы создания резервных копий серверов в ситуации, когда объем первичных средств (дополнительные накопители, CD/DVD) уже недостаточен для сохранения растущих объемов данных. Для начала предлагаю вам проанализировать три наиболее используемых типа систем хранения резервных копий данных, а также программные и аппаратные средства, обеспечивающие сам процесс создания и сохранения резервных копий. На втором этапе расскажу о внедрении системы создания копий с применением одного из типа хранилища – ленточной библиотеки.

Выбор хранилища резервных копий

При выборе типа хранилища резервных копий данных я рассматривал три варианта хранилища архивных данных:

  • Дисковый массив.
  • DVD-RAM-библиотека.
  • Ленточная библиотека.

Сразу скажу, что хотя DVD-библиотеки и выглядят привлекательно с точки зрения надежности, стоимость таких систем в настоящее время остается очень высокой.

Для начала давайте оценим стоимость все трех решений для объема 14 Tб (см. таблицы 1-3). Как видите, цена решения на ленточной библиотеке составляет почти в два раза дешевле, чем стоимость сохранения копий данных на жестких дисках и почти в 8 раз дешевле стоимости решения на основе DVD-библиотеки.

Таблица 1. Стоимость системы сохранения резервных копий данных на жесткие диски

Компонент

Пример

Стоимость

Корпус с 40 слотами для жестких дисков

RM8U8042

$4,000 US

RAID-контролер, 24 порта

Areca ARC-1170 SATA II 24

2 x $1,500 US = $3000 US

Материнская плата с процессором и памятью

$1500

Жесткие диски, 28 штук, 500 Гб каждый

Hitachi, Seagate

28 x $130 = $3640

Окончательная стоимость:

$12,410 US

Таблица 2. Стоимость системы сохранения резервных копий данных на ленточную библиотеку

Компонент

Пример

Стоимость

Ленточная библиотека с LTO2 накопителем

DELL PowerVault 136T

$5,000 US

Лента,  72 картриджа

Fujitsu LTO2

72 x $30 = 2160

Окончательная стоимость:

$7,160 US

Таблица 3. Стоимость системы сохранения резервных копий данных на DVD-библиотеку

Компонент

Пример

Стоимость

DVD-библиотека с 1525 слотами

Plasmon D-1525 DVD

$36,545 US

DVD RAM 4.7 Гб плюс картридж производителя

$640 US за упаковку из 40 носителей, 30 упаковок, итого: $19200 US

Окончательная стоимость:

$55,745 US

Источник: http://www.opticaljukeboxes.com/dvd?plasmon_d-1525.htm.

Стабильность

В среднем одна лента способна выдержать порядка 250 полных циклов перезаписи. Я использовал приблизительно 6 лент каждую неделю, т.е. 24 ленты в месяц. С 60 лентами, загруженными в ленточную библиотеку, каждая лента используется в среднем 2,5 раза в месяц. Таким образом, мы получаем, что в среднем одна лента способна прослужить около 100 месяцев (250/2,5=100). Конечно, все зависит ещё и от условий окружающей среды. Например, если температура часто меняется или присутствует пыль, то это может значительно сократить время жизни ленты. На первый взгляд, стабильность системы на диски выглядит более высокой по сравнению с лентами, но как показывает опыт, время жизни SATA-дисков при очень высоких загрузках составляет в среднем 1-2 года в зависимости от внешних факторов. Поэтому нужно учитывать нагрузку при выборе решения.

Длительное хранение

Если вы хотите хранить ваши данные в течение длительного срока, например, банковские записи, то вы можете сохранить данные на лентах, затем выгрузить их из библиотеки и сохранить в другом безопасном месте на длительное время. В среднем ленты имеют срок хранения порядка 30 лет, правда, этот срок может резко сократиться при частом перезаписывании. И, как вы понимаете, такая схема практически недоступна в случае решения на дисках. Также сюда можно добавить потенциальный фактор, что жесткие диски могут просто не запуститься после столь длительного хранения из-за затвердевания смазки механических частей. Поэтому система хранения на лентах мне видится более гибкой, позволяющей решать обе задачи – хранение оперативных копий и возможность хранения данных в течение очень длительного времени. Например, работа может происходить по следующему сценарию: ежедневно производится запись измененных данных на ленту и раз в месяц создается полная копия всех данных, затем кассеты изымаются и помещаются в удаленное безопасное место.

Масштабирование

К уже имеющейся библиотеке можно добавить новые. При наличии двух SCSI-портов один архивирующий сервер может обслуживать до 15 библиотек с суммарным объемом 210 Tб.

Охлаждение и потребление энергии

Dell PowerVault 136-T использует порядка 110 Ватт, тогда как решение на 28 дисках и сервере использует порядка 800-1000 Ватт. Так как рекомендованная рабочая температура жестких дисков составляет 40-50°C, то в случае решения на жестких дисках нужно позаботиться о качественной охлаждающей системе, и это тоже нужно учитывать при составлении окончательной сметы при выборе решения. Плюс, если процесс создания архивных копий затягивается на многие часы, то стоимость потребленной электроэнергии может составить внушительную сумму.

Доступность

Из-за того, что системы хранения на лентах являются синхронными, только одна операция доступна в какой-то момент времени. Например, если вы хотите восстановить ваши данные, то вы будете вынуждены остановить текущую процедуру архивирования. Системы хранения на дисках лишены этого недостатка, что является большим преимуществом перед лентами, особенно когда необходимо иметь асинхронный доступ к данным, например, если вы предоставляете ваше решение многим клиентам, которые хотят иметь параллельный доступ.

Вам необходимо рассмотреть все требования и выбрать наиболее подходящее решение. Единственное, что можно посоветовать, так это начать с более дешевой конфигурации на ленточной библиотеке, а затем добавить хранилище на дисках, таким образом вы можете хранить полные данные на лентах за последние несколько месяцев и одновременно воспользоваться преимуществами хранения на жестких дисках.

Структура системы

Я покажу шаги, необходимые для создания хранилища на лентах. Наша система будет состоять из следующих компонентов:

  • Архивирующий сервер (сервер резервного копирования).
  • Ленточная библиотека.

Архивирующий сервер собирает данные с серверов, сжимает, сохраняет на собственный носитель для временного хранения и последующей записи на ленту. Кроме этих базовых операций, сервер также создает расписания сохранения полных и частичных данных с серверов.

Выбор аппаратного обеспечения

Попробуем выбрать аппаратное обеспечение, необходимое для создания нашей системы. Как вы помните, есть два компонента архивирующего сервера, которые интенсивно используются: процессор для сжатия данных и накопитель для временного хранения данных. Исходя из этого, у нас есть выбор построения системы на основе простенького P4 с небольшим жестким диском до сервера с аппаратной компрессией и высокопроизводительным, вместительным хранилищем SAN.

Также нужно учитывать, что процесс сбора данных с серверов использует немалое количество ресурсов подсистем ввода-вывода, и если ваши серверы достаточно нагружены, то вам необходимо учитывать и этот фактор для выбора конфигурации, которая могла бы собирать данные серверов в минимально возможное время для предотвращения перегрузки серверов в час пик.

Таким образом, можно рассмотреть три класса аппаратного обеспечения.

Начальный уровень

Подходит для небольшого количества серверов (например, от 1 до 20 серверов с 100-200 Гб на каждом сервере) и в случае, если вы не ограничены временными рамками для процесса архивирования. Для такого решения можно воспользоваться системой с одним-двумя процессорами и непроизводительным SATA-накопителем.

Средний уровень

Этот уровень можно порекомендовать для 200-300 серверов, но если и здесь вы не ограничены по времени. Подойдет система с 2-4 ядрами, SCSI/SAS/FC-накопителями на 400‑800 Гб. Вы можете спросить: «Почему SCSI/SAS/FC предпочтительнее?». Накопитель должен быть способен передавать порядка 600-1000 Гб в день, и на данный момент только накопители серверного класса с интерфейсами SCSI/SAS/FC способны выдержать такую нагрузку.

Высший уровень

Важным отличием этого решения от двух предыдущих является способность системы архивировать данные с серверов в максимально короткое время, таким образом, производительность серверов в час пик не пострадает. Для этой конфигурации вы можете воспользоваться контроллером аппаратного сжатия AHA362-PCIX, который предоставляет скорость до 3 Гб в секунду. Для обеспечения такой скорости сохранения на архивном сервере вам также необходим соответствующий накопитель, способный работать на этой скорости. Приблизительно можно рассчитать его конфигурацию по формуле:

hNumber = bSpeed/hSpeed

где:

  • hNumber – количество дисков, необходимых для накопителя;
  • bSpeed – средняя скорость передачи архивного сервера;
  • hSpeed – средняя скорость записи на каждый жесткий диск.

Для примера возьмем ситуацию – вы хотите сохранять данные на скорости 1 Гб в секунду, и каждый накопитель способен сохранять на скорости 30 Мб в секунду. Таким образом, вам необходимо, как минимум, 5 жестких дисков. Конечно, чем больше дисков установлено, тем большую скорость вы можете получить. Хотя при возрастании количества дисков кривая зависимости скорости от количества дисков будет падать, и в этом случае можно подумать о создании массива RAID10. Так как цена на SAN-накопители падает в последние годы (стоимость начального SAN-накопителя на 14 слотов составляет порядка $2500 US), то такое решение может рассматриваться как наиболее эффективное по соотношению качества, скорости и стоимости.

Инсталляция аппаратного обеспечения

Я использовал «среднюю конфигурацию» со следующими компонентами:

  • Два процессора AMD 270 с двумя ядрами в каждом.
  • Четыре 300 Гб SCSI-диска, собранные в массив RAID5.
  • Ленточная библиотека Dell Powervault 136-T с 60 кассетами (доступно до 72 кассет).
  • Два LTO-2-накопителя, установленных в библиотеку.

Таким образом, полный объем хранилища составил порядка 12 Tб, которого было достаточно для сохранения 8 Tб, включая частичные и полные архивы.

Инсталляционный процесс включает в себя два шага – подключение кабелей и загрузку кассет в библиотеку.

Подключение кабелей

Вам необходимо последовательно соединить все SCSI-устройства. Если у вас 2 накопителя на лентах, то вам понадобится 3 SCSI-кабеля и один терминатор. Шаги подключения приведены ниже:

  • Подключите первый разъем автозагрузчика (tape exchanger) в SCSI-порт архивирующего сервера.
  • Второй разъем автозагрузчика должен быть подключен к первому разъему первого ленточного накопителя.
  • Второй разъем первого накопителя должен быть подключен к первому разъему второго накопителя.
  • И второй разъем второго накопителя должен быть закрыт SCSI-терминатором.

Структура подключения приведена рис 1.

Рисунок 1. Схема подключения библиотеки к серверу

Рисунок 1. Схема подключения библиотеки к серверу

Установка программного обеспечения

Я использовал программный пакет Amanda (http://www.amanda.org). Предварительно были рассмотрены разные программы, но комбинация возможностей Amanda сыграла решающую роль в выборе последней:

  • Бесплатность. Если у вас большое количество серверов, то лицензионные отчисления могут поставить крест на всем решении или проделать большую дыру в бюджете компании.
  • Безопасность. Шифрование на уровнях передачи и хранения данных. Шифрование на уровне передачи является особенно важным, если серверы расположены в месте, отличном от расположения системы архивирования.
  • Развитый планировщик. Пока другие системы лишь предоставляют доступ к командам архивирования данных и вам необходимо самому определять стратегию архивирования, Amanda имеет собственный планировщик задач архивирования, способный выполнять такие нетривиальные требования, как распределение запусков задач полного архивирования по всему циклу архивирования.

Инсталляция Amanda на сервер

В работе я использую Linux, а конкретнее – CentOS 4.4. Поэтому все дальнейшие указания рассчитаны на эту операционную систему, хотя Amanda работает на большинстве UNIX‑подобных операционных системах.

Скачайте amanda с сайта http://sourceforge.net, распакуйте и проинсталлируйте, как написано в инструкции, или следуйте нижеприведенному примеру. Я использовал версию 2.4.5p1:

tar -xzvf amanda-2.4.5p1.tar.gz

cd amanda-2.4.5p1

./configure --with-user=root --with-group=root

make

make install

По умолчанию имя конфигурации называется «DailySet1», и она расположена в /usr/local/etc/amanda/DailySet1. Вам необходимо скопировать конфигурационные файлы из каталога example/* в каталог /usr/local/etc/amanda/DailySet1/.

Также вам надо установить программу mtx для операций с ленточными накопителями.

Подготовка ядра для сервера

Также вам необходимо включить опции ядра для поддержки автозагрузчика и ленточного накопителя. Вы можете воспользоваться модулями или статически включить поддержку в ядро. На наших серверах в целях безопасности мы используем ядра с полностью выключенной поддержкой модулей.

Необходимо включить следующие опции в ядре Linux (см. рис. 2):

  • SCSI Tape support;
  • SCSI Media changer support;
  • Probe all LUNs on each SCSI device;
  • SCSI generic support.

Рисунок 2. Конфигурация ядра Linux

Рисунок 2. Конфигурация ядра Linux

После установки нового ядра и перезагрузки сервера введите команду «dmesg», и если все настроено правильно в ядре, вы должны увидеть ваши устройства:

Vendor: DELL Model: PV-136T Rev: 3.37

Type:   Medium Changer ANSI SCSI revision: 02

Vendor: IBM   Model: ULTRIUM-TD2  Rev: 53Y3

Type:   Sequential-Access ANSI SCSI revision: 03

Vendor: IBM   Model: ULTRIUM-TD2  Rev: 53Y3

Type:   Sequential-Access ANSI SCSI revision: 03

Настройка Amanda

Теперь речь пойдёт о настройках, которые необходимо применить, чтобы заставить DELL PowerVault 136T работать. Как упоминалось ранее, я использовал LTO2 (200gb/400gb) drives.

В нашем случае конфигурационные файлы были расположены в /usr/local/etc/amanda/DailySet1. Два файла, которые подлежат правке: changer.conf и amanda.conf.

Настройка amanda.conf

Большинство опций подходят для типичных случаев, но есть такие, которые необходимо изменить.

Имя вашей организации:

org "Bigsoft Home"

Адрес администратора системы архивирования. На этот адрес будут отправляться отчеты об архивировании. Если у вас большое количество серверов, то нужно позаботиться, чтобы все почтовые системы могли успешно доставить большие письма.

mailto report@domain.com

Количество параллельных процессов архивирования. Я получил число максимального количества процессов, равное 24 на 4 ядрах AMD 270 (два процессора, четыре ядра). Если скорость превышает 1 Гб в секунду, то вам необходимо гигабитное и выше подключение к сети:

inparallel 12

Максимальная скорость для использования сервером. Это не жесткое ограничение и лишь помогает планировщику в определении максимального количества запущенных процессов для получения скорости, не превышающей этот предел:

etusage 600000 Kbps

Если на ваших серверах расположено громадное количество файлов (порядка несколько миллионов), то необходимо увеличить это значение по умолчанию, иначе процесс подсчета размера всех файлов закончится неудачно.

etimeout 208000

Настройка автозагрузчика

В этом разделе мы расскажем, как настраивать Amanda для использования автозагрузчика лент, установленного в библиотеке. Параметры автозагрузчика находятся в двух файлах – amanda.conf и changer.conf.

Для начала займемся amanda.conf.

Runtapes 5

Количество лент, используемых для каждого запуска. Если это число меньше, чем необходимо для сохранения ежедневных данных, то вы получите сообщение об ошибке, и Amanda перейдет в degraded режим. Вам необходимо подобрать это число экспериментальным путем или по предварительной оценке из расчета суммарный объем данных плюс максимальный объем файлов, измененных между запусками процедур архивирования.

tpchanger "chg-zd-mtx"

Тип программы управления автозагрузчиком. Если у вас SCSI-автозагрузчик, то автор рекомендует использовать программу chg-zd-mtx как наиболее развитую и «понимающую» большинство SCSI-автозагрузчиков.

tapedev "/dev/nst0"

Путь к ленточному накопителю.

changerfile "/usr/local/etc/amanda/DailySet1/changer"

Путь к системному файлу статуса автозагрузчика.

changerdev "/dev/sg2"

Путь к устройству автозагрузчика. Вам необходимо найти число после «sg» с помощью запуска программы «dmesg» и найти порядок автозагрузчика в списке SCSI-устройств. В нашем случае SCSI RAID имел число 0, SCSI-контроллер имел число 1 и автозагрузчик имел число 2.

tapetype LTO2

Тип ленточных кассет. Amanda.conf содержит список практически всех типов кассет, из которого нужно выбрать используемый в вашей системе, например, LTO2, LTO3, или недавно появившийся LTO4. Понятно, что при покупке библиотеки у вас есть выбор, какой тип ленточного накопителя вы установите в систему.

amrecover_changer "chg-zd-mtx"

Типы программы для управления загрузчиком для процесса восстановления.

Далее займемся changer.conf. Есть несколько опций, которые необходимо поменять для PowerVault 136-T:

eject > 1

Накопители поддерживают команду eject для выбрасывания кассеты в автозагрузчик.

sleep 5

Подождать 5 секунд перед началом использования кассеты после загрузки.

cleanmax 10

Максимальное количество использования чистящего картриджа. Это число может меняться, поэтому необходимо свериться с руководством по эксплуатации конкретного типа чистящего картриджа.

changerdev  /dev/sg0

Путь к автозагрузчику.

havebarcode 1

havereader=1

Как описано в разделе «Нанесение меток на ленту», PowerVault 136-T имеет собственное устройство чтения штрих-кодов, и для его использования нужно включить эту опцию:

labelfile  /var/log/amanda/labelfile.txt

Файл, где сохраняется список кассет, и их метки:

offline_before_unload=1 offlinestatus=1 OFFLINE_BEFORE_UNLOAD=1

Как правило, ленточные накопители требуют команды «offline» перед тем, как кассета может быть выгружена.

Настройка временного хранилища

Как вы уже знаете, Amanda сохраняет данные на собственное временное хранилище, и затем, когда оно заполняется или процедура архивирования завершена, сохраняет данные из этого хранилища на ленту. Необходимо описать хранилище в конфигурационном файле amanda.conf:

holdingdisk hd1 {

  comment "main holding disk"

  directory "/home/amanda"  # Путь к данным на диске

  use 300 Gb                # Доступное пространство

  chunksize 1Gb             # Разбить данные на куски по 1 Гб

}

Вы можете настроить несколько систем хранилища. Например, если на сервере установлены несколько накопителей.

Настройка стратегии архивирования

Рассмотрим, как настроить тип процедуры архивирования и как составлять список серверов, подлежащих копированию.

Настройка стратегии

Сперва необходимо описать стратегии для Amanda. Для большинства ситуаций одной стратегии уже достаточно, хотя можно настроить множество стратегий для специфичных случаев.

define dumptype default

{

global

estimate calcsize

program "GNUTAR"

dumpcycle 14

comment "root partitions dumped with tar"

compress server fast

index

priority medium exclude list "amandaexclude"

tape_splitsize 20 Gb

}

Ниже приведены описания каждой опции:

  • global – означает, что эту стратегию можно использовать независимо в списках серверов. Например, можно настроить несколько стратегий, затем объединить их вместе и придать статус «global». Для простоты мы не использовали такую схему построения стратегий.
  • estimate calcsize – используемый метод для определения общего размера файлов на серверах. Существует два наиболее полезных варианта этой опции – calcsize и server. В случае calcsize Amanda запустит небольшую программу на каждом сервере, которая просуммирует размер всех файлов. Это наиболее аккуратный способ для оценки объема, но может занять продолжительное время в случае большого количества файлов. Второй вариант server указывает Amanda использовать данные, полученные из предыдущих запусков. Если объем данных сильно разнится от запуска к запуску, то это может привести к составлению неправильного расписания заданий.
  • program «GNUTAR» – программа для сбора данных на клиентах. Если не стоит задача делать дамп файловых систем, то это – оптимальная опция.
  • dumpcycle 14 – как часто необходимо создавать полный архив серверов. В нашем случае мы остановились на двух неделях.
  • compress server fast – выбор стороны, на которой будет происходить сжатие данных. Есть два варианта -server – для сжатия на архивирующем сервере и client – для сжатия на стороне клиента. У меня была возможность установить 4 ядра на архивирующем сервере, поэтому я использовал архивирование на стороне сервера. Максимальная скорость сжатия составила порядка 600 Мб в секунду. Дополнительно можно установить один из уровней сжатия – best, custom, fast.
  • index – указывает Amanda, что необходимо создавать базу данных содержимого на кассетах. По умолчанию эта опция выключена. Но это необходимо включить, иначе будет невозможно сделать поиск данных на кассетах.
  • exclude list «amandaexclude» – на каждом диске, на каждом клиенте необходимо расположить этот файл, который может содержать пути и маску файлов и директорий, которые необходимо исключить из архивирования (например, лог-файлы). Даже если необходимо включить все файлы, этот файл должен существовать, но может быть пустым. Иначе процесс архивирования завершится неудачно. Для подробностей обратитесь к разделу «Исключение и разделение данных».
  • priority medium – для некоторых дисков на клиентах можно указывать различные уровни приоритетов: high, medium, low. Если система архивирования не имеет достаточно места для сохрания данных, она выберет диски с более высоким приоритетом для замещения дисков с меньшим приоритетом, таким образом, важные данные с большим приоритетом получают большую гарантию сохранности.
  • tape_splitsize 20 Gb – для уменьшения фрагментации ленточного пространства вы можете разбить большие архивы на более мелкие на момент записи на ленту. Например, если объем ваших дисков в среднем составляет 100 Гб, то однозначно проблема фрагментации проявится, потому каждый раз Amanda будет вынуждена искать свободное место на лентах на 100 Гб. Ограничение максимального размера архива позволит записывать архивы кусками по 20 Гб (как в данном примере). Сегментация больших архивов на более мелкие позволит существенно уменьшить проблему фрагментации носителей.

Описание клиентов

На этом этапе мы опишем серверы-клиенты, а также каталоги, которые подлежат архивированию. Специальный файл disklist отвечает за это описание (по умолчанию он находится в каталоге /usr/local/etc/amanda/DailySet1). Этот файл содержит список каталогов, которые необходимо архивировать, например:

server1.domain.com / {

 default

}

server1.domain.com /boot {

 default

}

server1.domain.com /var {

 default

}

server1.domain.com /usr {

 default

}

server1.domain.com /home {

 default

}

Вы могли бы спросить: «Почему бы просто не определить корневой каталог «/» вместо списка каталогов?». Когда Amanda запускает программу сбора данных (tar) на серверах, то используется опция «stay on single filesystem», которая указывает tar оставаться на текущей файловой системе. Таким образом, монтирование по NFS или другие манипуляции с файловой системой не приведут к двойному или циклическому архивированию. Я использую отдельные разделы для /boot, /home/, /usr, and /var, поэтому необходимо было указать все разделы. Также, если какой-то раздел содержит большие объемы данных, то вместо указания этого каталога необходимо использовать список подкаталогов.

Для подробностей обращайтесь к разделу «Исключение и разделение данных».

Создание меток на лентах и кассетах

Перед использованием библиотека должна знать о кассетах, которые установлены. Для этого мы должны обучить библиотеку, и этот процесс включает два шага:

  • инициализация библиотеки;
  • создание списка кассет для Amanda.

Инициализация библиотеки

Первоначально кассеты не имеют никаких меток, которые позволили бы библиотеке идентифицировать каждую кассету. Для этого необходимо купить специальные бумажные метки и разместить их на каждую кассету. Их можно купить на сайте http://www.issidata.com (USA) или на http://www.invictus.ru (Россия) или просто напечатать с помощью GNU‑Barcode. Каждая метка имеет уникальный цифровой и штрих-коды, причем последний используется сканером штрих-кода для поиска кассет. После создания меток на кассетах поместите кассеты в библиотеку. Процесс помещения кассет может разниться для каждого типа библиотеки, поэтому лучше обратиться к документации производителя.

Создание списка кассет для Amanda

После того как мы разместили все кассеты в библиотеку и библиотека нашла их, время приступить к созданию меток Amanda на каждой ленте, что может быть выполнено с помощью следующей команды:

amlabel DailySet1 DailySet1-NR  slot SlotID

где NR-номер кассеты (любое число, но желательно, чтобы оно совпадало с номером слота), и SlotID – номер слота в библиотеке. Например, если у вас 60 кассет, то можно воспользоваться следующим скриптом:

#!/usr/bin/perl

use strict;

foreach my $i(1..60)

{

 system("amlabel -f DailySet1 DailySet1-$i  slot $i");

}

Запуск и проверка

Таким образом, мы выполнили все первоначальные шаги и подошли к финальной стадии – запуск процесса архивирования.

Всего существует три режима работы процесса архивирования:

  • архивирование всех данных всех серверов;
  • архивирование конкретного сервера;
  • архивирование конкретного диска конкретного сервера.

Для начала попробуем создать резервную копию одного диска нашего сервера:

amdump DailySet1 server1.domain.com /home

Эта команда указывает Amanda сделать копию данных, расположенных на сервере server1.domain.com в каталоге /home. Процесс занимает некоторое время и включает в себя следующие этапы:

  • запуск планировщика задач;
  • оценка объема данных на клиенте;
  • сбор данных и отправка на временное хранилище архивирующего сервера;
  • запись архивных данных с временного хранилища на ленту.

Если есть желание понаблюдать за процессом, то можно увидеть процессы calcsize, tar, sendbackup на клиенте и gzip на архивирующем сервере. Как только процедура архивирования завершится, необходимо проверить результат всего процесса.

Проверка архива

После того, как мы завершили архивирование, можно проверить результаты процесса с помощью команды:

amadmin DailySet1 info servername [disk]

В нашем случае это должно выглядеть вот так:

amadmin DailySet1 info server1.domain.com /usr

Current info for server1.domain.com /usr:

Stats: dump rates (kps), Full: 2109.9, 1071.6, -1.0

Incremental: -1.0, -1.0, -1.0

compressed size, Full: 36.8%, 36.8%,-100.0%

Incremental: -100.0%,-100.0%,-100.0%

Dumps: lev datestmp tape file origK compK secs

0 20070517 DailySet1-1 66 1288890 474720 225

Здесь можно видеть уровень архива (полный или инкрементальный), имя кассеты, где был сохранен архив, дату, количество файлов, оригинальный и сжатый объемы архива и количество секунд, потраченных на процедуру. Если все выглядит правильно, то можно запускать систему в рабочем режиме, т.е. ежедневно.

Исключение и разбивка данных

В разделе будут описаны два очень важных момента в работе системы – как исключить данные из процесса архивирования и как разбить большой объем данных на несколько архивов меньшего размера.

Исключение данных

Как уже было показано, в нашей стратегии архивирования мы указали файл, который содержит список файлов, которые необходимо исключить из архивов:

define dumptype default

{

......

exclude list "amandaexclude"

......

}

Файл amandaexclude должен быть расположен в верхнем каталоге каждого каталога, определенного в файле disklist. Например, если определен /home в файле disklist, то файл amandaexclude должен быть расположен в /home/amandaexclude. В этом файле указаны каталоги и файлы, которые не должны быть архивированы:

log/httpd/*

log/httpd2/*

log/httpd2-ssl/*

log/httpsd/*

log/maillog*

tmp/*

*.tmp

*.temp

Обращаем внимание, что элементы списка должны быть записаны от начала каталога из disklist. Для примера, если у вас есть /var из disklist, и если вы укажете /var/log/httpd в файле excludeamanda, то Amanda решит, что каталог /var/var/log/httpd должен быть исключен, что неверно.

Разбивка данных

К сожалению, одним из недостатков Amanda является невозможность размещения одного каталога на нескольких кассетах, таким образом, архивирование каталогов, превышающих 200 Гб (после сжатия), невозможно. Конечно, можно указать список подкаталогов из сверхбольших каталогов, но проявляется одна проблема, которую я поясню на основе следующего примера:

/home/mysql/

/home/www/

/home/users/user1

/home/users/user2

Для того чтобы исключить ошибки и ручной труд, можно воспользоваться следующей командой для поиска подкаталогов типа /home/users/user***:

find /home -t d -mindepth 2 -maxdepth 2

Таким образом, будут найдены все подкаталоги, которые нужно описывать отдельно в disklist. Но нам еще необходимо найти каталоги с меньшей глубиной:

find /home -t d -mindepth 1 -maxdepth 1

Если результаты обеих команд включить в disklist, то он будет выглядеть следующим образом:

/home/mysql/

/home/www/

/home/users/

/home/users/user1

/home/users/user2

Таким образом, в список каталогов попадает сверхбольшой каталог /home/users, и в результате задача по разбиению данных остается нерешенной.

Для решения этой проблемы достаточно включить каталоги из /home/users в список для исключения директории /home как показано:

server1.domain.com /home

{

default2

exclude append /home/users/user1

exclude append /home/users/user2

}

server1.domain.com /home/users/user1

{

default

}

server1.domain.com /home/users/user2

{

default

}

Замечание: используется новая стратегия «default2», которая не имеет опции «exclude», иначе она перекроет опцию «exclude append».

Восстановление с Amanda

Теперь самое главное – восстановление данных из архива. Сейчас мы разберем, как восстанавливать данные на стороне архивного сервера. Как восстанавливать данные на стороне клиента – тема следующей статьи. Итак, сперва необходимо найти кассету, на которой находятся интересующие нас данные.

Например, если нужно восстановить данные каталога /home с клиента server1.domain.com, то на стороне архивного сервера нужно выполнить команду:

amadmin DailySet1 info server1.domain.com /home

Если система успешно работала и данные присутствуют на ленте, то вы должны увидеть приблизительно такую картинку:

Current info for server1.domain.com /home:

Stats: dump rates (kps), Full: 2186.8, -1.0, -1.0

Incremental: 1413.2, -1.0, -1.0

compressed size, Full: 88.2%,-100.0%,-100.0%

Incremental: 66.0%,-100.0%,-100.0%

 

Dumps: lev datestmp tape file origK compK secs

0 20070403 DailySet1-10 7 34495940 30409476 13906

1 20070517 DailySet1-59 124 3532300 2330312 1649

Оказывается, что у нас есть две копии каталога /home но с различным уровнем сохранения. Уровень «0» означает полную копию каталога /home и уровень «1» означает инкрементальный архив данных, которые были изменены с момента создания полной копии.

Для получения наиболее свежих данных необходимо извлечь и распаковать оба архива, что включает в себя два шага.

Загрузка нужной кассеты в привод:

amtape DailySet1 label DailySet1-1

Извлечение архива с ленты с помощью команды amrestore:

amrestore /dev/nst0 server1.domain.com /home

где:

  • /dev/nst0 – накопитель на ленте;
  • server1.domain.com – имя клиента;
  • /home – каталог, который был определен в disklist.

Если архив успешно был извлечен с ленты, то в текущем каталоге вы обнаружите файл server1.domain.com._home.20070403xxxxx.0.1, что является tar-архивом сжатым с помощью gzip.

Следующим этапом необходимо достать копию инкрементального архива:

amtape DailySet1 label DailySet1-59

amrestore /dev/nst0 server1.domain.com /home

И как результат этого действия, вы должны получить файл server1.domain.com._home.20070517, который также является tar-архивом, сжатым с помощью gzip. Далее, раскрыв оба архива с помощью tar, вы получите наиболее свежую копию данных, доступную в архиве.

Заключение

Я не стремился изложить полное руководство по созданию системы резервного копирования, а лишь рассмотрел основные понятия и базовые принципы, необходимые для создания собственной системы, которая более года успешно используется в нашей компании.

Многие расширенные компоненты остались за рамками статьи, такие как:

  • Планирование расписания задач.
  • Проверка целостности архивов.
  • Использование нескольких ленточных накопителей.
  • Обслуживание и мониторинг ленточных библиотек.
  • Аппаратное сжатие.
  • Дамп файловых систем и остановка серверов баз данных перед архивированием.

Но сегодняшнего материала уже достаточно для понимания, как устроена и работает система резервного копирования, и в будущем мы постараемся осветить другие аспекты, возникающие в процессе эксплуатации системы.

Ни автор, ни редакция не несут ответственности за возможные последствия при использовании информации из данной статьи.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru