Posts on

Автоматическое монтирование FTP каталога

Fri, 09 Mar 2018 02:51:15 +0300

Использую proxmox в качестве гипервизора для размещения виртуальных машин. Провайдер у которого я арендую выделенные серверы даёт возможность использовать ftp сервер для резервного копирования. Гипервизор встроенных возможностей записи резервных копий на ftp не имеет. Так как proxmox основан на Debian, то можно использовать curlftpfs для монтирования ftp в локальный каталог и выполнять туда резервное копирование, но в процессе эксплуатации выяснилось, что при длительном простое соединение периодически отваливается. Поэтому оптимальным вариантом оказалось автоматическое монтирование ftp каталога средствами systemd при обращении к точке монтирования. Автоматическое размонтирование происходит через 30 секунд простоя.

curlftpfs

Устанавливаем curlftpfs

apt-get install curlftpfs

Создаем файл паролей

cat<<EOF>>/root/.netrc
machine ftp-server.com
login ftp-user
password ftp-password
EOF

Тестируем монтирование файловой системы

mkdir /mnt/backup
curlftpfs ftp-server.com /mnt/backup -o rw,allow_root
ls /mnt/backup
fusermount -u /mnt/backup

Настраиваем автомонтирование

Создаем файл с точкой монтирования для systemd:

cat<<EOF>>/etc/systemd/system/mnt-backup.mount
[Unit]
Description=ftp share
[Mount]
What=curlftpfs#ftp-server.com
Where=/mnt/backup
Options=rw,allow_root,direct_io,hard_remove,big_writes
Type=fuse
[Install]
WantedBy=multi-user.target
EOF

Создаем сервис для автомонтирования:

 cat<<EOF>>/etc/systemd/system/mnt-backup.automount
[Unit]
Description=ftp share
Requires=network-online.target
After=network-online.service
[Automount]
Where=/mnt/backup
TimeoutIdleSec=30
[Install]
WantedBy=multi-user.target
EOF

Включаем и проверяем автомонтирование

systemctl daemon-reload
systemctl enable mnt-backup.mount
systemctl enable mnt-backup.automount --now
ls /mnt/backup
mount | grep /mnt/backup

Запуск сессий Data Protector в режиме отладки

Sun, 18 Jun 2017 02:51:15 +0300

В этой статье я приведу примеры методов сбора отладочной информации для HPE Data Protector.

Куда собираются отладочные данные

Начнем с определения того, куда складываются отладочные данные. Это очень важный вопрос, т.к. при использовании высокого уровня отладки их объем может запросто переполнить файловую систему. К тому же по умолчанию они не сжимаются и я на практике видел как для одной сессии резервного копирования их накапливается более 100 Гбайт за пару часов при уровне отладки равным пятиста.

То, куда будут складываться файлы отладки определяется переменной OB2DBGDIR, которая находится в файле конфигурации omnirc. Сам файл omnirc (или его шаблон, если никто ещё не менял значения системных переменных) находится вот здесь:

Тип ОС	Расположение omnirc
Linux / UNIX	/opt/omni/.omnirc
Windows	C:\ProgramData\OmniBack\omnirc

Итак, если в файле omnirc никто не менял значение переменной OB2DBGDIR, то отладочные файлы будут собираться сюда:

Тип ОС	Расположение отладочных файлов	Пример
Linux / UNIX	/tmp	/tmp/OB2DBG_*
Windows	C:\ProgramData\OmniBack\tmp\	C:\ProgramData\OmniBack\tmp\OB2DBG_*

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

Методы сбора отладочных данных

Существует как минимум три способа сбора отладочных данных в HPE Data Protector. Каждый из них по-своему удобен в различных ситуациях.

С использование Data Protector Manager (GUI).
Запуск сессии через консоль с указанием дополнительных опций отладки.
Добавление отладочных параметров в расписание резервного копирования.

Data Protector Manager (GUI)

Это самый известный и простой метод. К тому же инструкцию с этим методом каждый раз высылает поддержка, когда требует от Вас собрать логи. Этот метод хорош тем, что он позволяет собрать отладочные данные практически по любому компоненту Data Protector — включая сам GUI и сессии которые инициируются без использования планировщика DP. Огромный минус этого метода заключается в том же — он собирает отладочные данные по всем сессиям, которые работают параллельно с GUI в режиме отладки. То есть если Вам надо было собрать отладочные данные по одной сессии, но в процессе их сбора Data Protector запустил несколько сессий через планировщик, то Вы получите пачку ненужных Вам файлов с отладочными данными, разбросанными ещё по нескольким клиентам и медиа серверам.

Включается отладка следующим образом:

В GUI Data protector Manager выбираем пункт меню File > Preferences…
В окне настроек переходим на вкладку Debugging
Указываем уровни отладочных сообщений (например 1-500), указываем суффикс имен отладочных файлов.
Выбираем до какого момента данные опции должна действовать — постоянно или только на время работы следующей GUI сессии.

Данные изменения вступят в силу только с момента действия следующей GUI сессии, поэтому нажимаем кнопку «Relaunch GUI now…» и выполняем процедуру во время которой происходит нечто, требующее сбора отладочных данных.

Запуск сессии из консоли с указанием дополнительных опций

С подавляющем большинством консольных команд Data Protector, которые описаны в CLI Reference Guide можно использовать дополнительную опцию «-debug». Синтаксис этой опции следующий:

-debug 1-999[,gz][,C:n][,T:s][,U] postfix [host]

Параметр	Обязательный параметр	Описание
1-999	да	Уровень отладочных сообщений. По умолчанию в GUI используется значение “1-99”.
gz	нет	Использовать компрессию для файлов отладки. Каждый файл отладки будет упакован в отдельный архив. По умолчанию отключено.
С:n	нет	Ограничить размер отладочных файлов n килобайтами. Минимальное значание - 4 KiB.
T:s	нет	Точность при выводе временных меток в отладочных сообщениях. Измеряется в долях от секунды. По умолчанию равна 1, что значит, что временные метки выводятся с точностью до одной секунды. Значение 1000 означает, что временные метки выводятся с точностью до одной миллисекунды.
U	да	Имя каждого отладочного файла формируется определенным стандартным способом. Имя файла начинается с символов OB2DBG_, затем следует название компонента DP и куча другой информации. Пользователь может указать окончание для файла, чтобы иметь возможность различать разные отладочные сессии.
host	нет	При помощи этого параметра можно ограничить перечень клиентов для которых необходимо включить отладку. Чтобы указать перечень клиентов, необходимо заключить список в двойные кавычки и в качестве разделителя использовать пробел. Например: “win-prod-10.demo.local win-prod-14.demo.local”.

Приведу несколько примеров использования этой опции для запуска различных сессий резервного копирования:

Пример 1. Internal Database

Необходимо запустить в режиме отладки сессию полного резервного копирования (full) внутренней базы данных Data Protector. Спецификация сессии называется dpcm.demo.local_idb. Требуемый уровень отладки 1-500, максимальный размер одного файла отладки — сто мегабайт (102400 KiB). Для файлов отладки необходимо включить компрессию (gzip). Суффикс файлов отладки — idb_case_0.

omnib -idb_list "dpcm.demo.local_idb" -barmode full -debug 1-500,C:102400 idb_case_0.txt

Пример 2. СУБД Oracle

Необходимо запустить в режиме отладки сессию полного резервного копирования (full) внутренней базы данных СУБД Oracle. Спецификация сессии называется de-onec-db_ora. Требуемый уровень отладки 1-500, максимальный размер одного файла отладки — сто мегабайт (102400 KiB). Для файлов отладки необходимо включить компрессию (gzip). Суффикс файлов отладки — idb_case_0.

omnib -oracle8_list de-onec-db-ora -barmode=full -debug 1-500,gz oracle_case_0.txt "de-onec-db.demo.local dpma-de.demo.local"

Пример 3. Файловая система Windows

Необходимо запустить в режиме отладки сессию инкрементального резервного копирования файловой системы windows сервера. Имя сервера: win-prod-15, том с данными D:, метка тома «Data». Резервное копирование выполнить на устройство «FLN1_W2». Уровень отладочных сообщений «1-200», размер каждого отладочного файла до 10 MiB, точность временных метод выводить до миллисекунд. Отладочные данные собирать только на сервере win-prod-15.

omnib -winfs win-prod-15.local:"/D" "D: [Data]" -device "FLN1_W2" -mode incremental -protect none -debug 1-200,C:10240,T:1000 winfs_debug_0.txt win-prod-15

Добавление отладочных параметров в расписание

При большом желании опции отладки можно добавить в параметры планировщика заданий резервного копирования. Этот способ работает только для старого классического планировщика задач (legacy scheduler), он не работает для advanced scheduler и для нового планировщика, который появился в версии 10.0. Формат тот же, что и при использовании консольных утилит, поэтому сложностей возникнуть не должно. Достаточно добавить строку с отладочной опцией в качестве первой строки в файл с расписанием. Например так:

Сами файлы с расписанием для «старого» планировщика заданий находятся здесь:

Операционная система	Путь к каталогу с расписаниями РК
Windows	\Config\server\Schedules; \Config\server\Barschedules
Linux / UNIX	/etc/opt/omni/server/schedules; /etc/opt/omni/server/barschedules

Резервное копирование SAP HANA

Sun, 22 Nov 2015 02:51:15 +0300

Эта статья — пошаговое руководство по настройке резервного копирования СУБД SAP HANA с помощью HP Data Protector.

Исходные данные

При написании данного руководства использовались следующее программное обеспечение и настройки:

Параметр	Значение
FQDN клиента резервного копирования	hana.demo.net
Версия ОС клиента	SUSE Linux Enterprise Server 11.3
Версия SAP HANA	1.00.097
Instance ID резервируемой базы данных	sid
SAP HANA shared installation path	/hana/shared
Версия HP Data Protector	9.04

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

Включение xinetd

Для корректной работы агента Data Protector требуется демон inetd. Как правило он присутствует даже в минимальной установке операционной системы, но далеко не всегда прописан в автозапуск при старте операционной системы. Поэтому запускаем его и добавляем в автозапуск:

systemctl enable xinetd
systemctl start xinetd

Установка агентов.

Во-первых необходимо установить на хост с HANA DB агентов резервного копирования. Это можно сделать как при помощи Data Protector Installation server, так и вручную. Устанавливаем следующие агенты:

SAP HANA integration
Disk agent (опционально)

Линкуем библиотеку backint

На клиенте резервного копирования выполняем следующие команды:

cd /hana/shared/SID/global/hdb
mkdir -p opt/hdbconfig
cd opt
ln -s /opt/omni/lbin/saphana_backint hdbbackint

Файлы параметров

Создаём на HANA DB хосте для каждого SID два файла параметров — один для полной резервной копии, второй — для резервного копирования журналов транзакций. Значение параметра OB2BARLIST должно совпадать с названием политики резервного копирования в HP Data Protector (см. пункт 7). Параметр OB2BARHOSTNAME содержит FQDN клиента.

cd /hana/shared/SID/global/hdb/opt/hdbconfig

cat<<EOF>>sid_full.par
OB2BARLIST='hana_sid_full';
OB2BARHOSTNAME='hana.demo.net';
EOF

cat<<EOF>>sid_log.par
OB2BARLIST='hana_sid_log';
OB2BARHOSTNAME='hana.demo.net';
EOF

Режим архивирования журналов транзакций

Необходимо проверить через HANA Studio, что параметр «log_mode» установлен в значение «normal».

Настройка backint в HANA Studio

Указать в HANA Studio пути к файлам параметров, которые были созданы в третьем пункте.

Пользователь Data Protector

Через консоль управления Data Protector Manager создать нового пользователя со следующими параметрами:

Параметр	Значение
Group	admin
Type	UNIX
Name	sidadm
UNIX group	sapsys
Description	SAP HANA user for SID database
Client	hana.demo.net

Запуск сессии резервного копирования

Интеграция HP Data Protector и SAP HANA через интерфейс backint устроена так, что инициировать любые сессии резервного копирования и восстановления возможно только со стороны SAP HANA и никак иначе. Есть два способа запуска сессии резервного копирования — через GUI (HANA Studio) и через консольную утилиту hdbsql. Настройка расписания резервного копирования должна производиться также с помощью инструментов SAP.

Запуск резервного копирования через HANA Studio

Запуск резервного копирования через hdbsql

/hana/shared/hdbclient/hdbsql

Welcome to the SAP HANA Database interactive terminal.

Type:	\h for help with commands
	\q to quit

hdbsql=> \c -i 00 -n hana.demo.net:30115 -u SYSTEM -p password
Connected to SID@hana:30115

hdbsql SID=> BACKUP DATA USING BACKINT ('/hana/shared/SID/SYS/global/hdb/backint/COMPLETE_DATA_BACKUP')
0 rows affected (overal time 54.342744 sec; server time 54.341548 sec)

hdbsql SID=>

VTL и Data Protector — рекомендации по настройке

Mon, 05 Oct 2015 02:51:15 +0300

В этой статье я постараюсь консолидировать информацию с лучшими практиками по настройке виртуальных ленточных библиотек (VTL, Virtual Type Libraries) на устройствах HP StoreOnce совместно с ПО резервного копирования HP Data Protector. Нижепреведенный подход в целом может быть использован для любых других устройств с VTL доступом и программного обеспечения резервного копирования, т.к. логика их работы обычно очень похожа, хотя все детали реализации и конкретные параметры всё же будут отличаться.

Параметры VTL

Перед тем как создать виртуальную ленточную библиотеку на устройстве HP StoreOnce Вам предстоит определиться с параметрами VTL, в частности с типом эмулируемой библиотеки, типом ленточных приводов и их количеством, типом и количеством картриджей.

Тип эмулируемой библиотеки (Library Emulation)

В зависимости от модели HP StoreOnce и свежести его микрокода Вам могут быть доступны различные типы эмуляции виртуальной ленточной библиотеки. В таблице приведенной ниже перечислен перечень актуальных режимов эмуляции для HP StoreOnce 6500.

Тип эмуляции	Приводов	Лент	Комментарии
D2DBS Generic	500	16384	Не эмулирует какую-либо ленточную библиотеку.
EML E Series	500	16384
MSL G3 Series (2x24)	2	24	Эмуляция HP StoreEver MSL2024
MSL G3 Series (4x48)	4	48	Эмуляция HP StoreEver MSL4048
MSL G3 Series (8x96)	8	96	Эмуляция HP StoreEver MSL8096
IBM-TS3500	500	16384	Эмуляция IBM TS3500. Позволяет использовать стандартные драйверы устройств от IBM. Рекомендуется для IBM Tivoli Storage Manager.
IBM-TS3500 IBM i			Только для IBM iSeries. Появилась в StoreOnce 6500 в версии 3.13.0.

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

Если Вы будете использовать HP Data Protector, Symantec Backup Exec или Symantec NetBackup, то можете не задумываясь всегда выбирать режим «D2DBS Generic».

Выбор этого режима, означает, что StoreOnce не будет пытаться прикидываться настоящей ленточной библиотекой. Также сильными сторонами «D2DBS Generic» является то, что это один из самых масштабируемых вариантов, а также не нужно устанавливать драйверы для ленточной библиотеки. Минус в том, что некоторый сторонний софт резервного копирования может не поддерживать работу с такой VTL (о совместимости необходимо узнавать у производителя ПО резервного копирования).

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

Тип эмуляции библиотеки можно изменить после того, как она уже была создана, то есть в процессе её работы.

Тип ленточного привода (Default Drive Emulation)

Для HP Data Protector всегда используйте UltriumVT, который доступен для библиотеки «D2DBS Generic».

Для другого ПО резервного копирования необходимо проконсультироваться с разработчиком на тему совместимости с различными типами приводов. Если с UltriumVT совместимости нет, то можете выбрать любой из стандартов Ultrium LTO начиная с LTO-2 и заканчивая LTO-6. Никакой разницы с точки зрения накладных расходов на StoreOnce для них нет. Единственный критерий — совместимость с ПО резервного копирования.

Прямой связи между типом эмуляции привода и возможным размером картриджа нет. То есть Вы можете выбрать эмуляцию древнего привода LTO-2 и указать размер картриджа 3200 GB или наоборот, использовать LTO-6 с картриджем 100 GB.

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

Размер картриджа (Cartridge size)

Стандартная рекомендация из Best Practice гласит, что размер картриджа должен быть больше чем максимальный размер резервной копии. То есть, если вы подготавливаете VTL для бекапа файловой системы объемом 500 гигабайт, то нужно выбрать размер картриджа превышающий 500 гигабайт (например 800 GB).

Однако с учетом того, что объем резервируемых метаданных для картриджей разного размера на StoreOnce одинаковый, данные имеют свойство расти, а количество слотов в виртуальной библиотеке не бесконечно, то очевидно что

лучше использовать максимальный размер картриджа (3200 GB на данный момент).

Не использовать максимальный размер картриджа имело смысл на устройствах с «tape offload», когда VTL сама сбрасывает содержимое определенных картриджей на ленточную библиотеку, как это было например в HP VLS. В этом случае было бы неплохо иметь одинаковые размеры картриджей на обоих устройствах.

Количество слотов (Number of Cartridge Slots)

Тут всё довольно просто, если у Вас утверждена политика резервного копирования. Предположим, VTL используется для бекапа файловой системы объемом 500 GB. Вы каждую субботу делаете full backup, который хранится 30 дней и каждый день инкремент с тем же сроком хранения. Размер картриджа — 3200 GB. Также Вы используете правильные настройки пулов лент в Data Protector (см. ниже) при которых на одной виртуальной ленте всегда лежит только одна сессия резервного копирования. В этом случае Вам необходим 31 картридж. С учетом возможных внеплановых «ручных» бекапов и некоторого округления в большую сторону, понадобится 50 слотов.

В случае необходимости дополнительные слоты всегда можно добавить. Удалить — гораздо сложнее.

Количество ленточных приводов (Number of Drives)

Тут Вам придется воспользоваться своей логичкой и здравым смыслом, т.к. вывести какую-то универсальную формулу довольно сложно.

Я обычно использую количество приводов которое вдвое превышает максимальное возможное количество потоков резервного копирования для возможности обеспечения параллельного восстановления. То есть, если VTL предназначена для резервного копирования файловой системы и планируется бекап в четыре потока, то я обычно выделяю для этого 8 приводов. Кстати, никогда не используйте мультиплексирование на дисковых библиотеках с дедупликацией! Никакого мультиплексинга, только многопоточность!

Учтите, что у каждого устройства HP StoreOnce есть ограничение на количество виртуальных ленточных приводов, обслуживаемых одним узлом. Имеется ввиду не количество приводов на библиотеку, а именно совокупное количество приводов с различных библиотек, которые обслуживаются одним узлом HP StoreOnce. Например, для StoreOnce 6200 и 6500 это ограничение равно 500 приводам. Это означает, что для двух-узловой системы можно на каждом из узлов наделать VTL с совокупным количеством приводов в 500 штук (1000 приводов на один куплет). Настройки Data Protector

Следующие настройки ПО резервного копирования HP Data Protector необходимы для того, чтобы:

Увеличить эффективность housekeeping на VTL.
Минимизировать объем данных на backend библиотеки за счет отказа от предварительной инициализации лент.

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

Настройки Media Pool

Во первых, ещё раз напомню, что после того как вы создали media pool для VTL, никогда не форматируйте ленты вручную!

На вкладке Allocation Policies установите следующие параметры:

Параметр	Значение
Usage	Non appendable
Allocation	Loose

Настройки на этой вкладке должны выглядеть так:

Настройки в Global Settings

Включение опции InitOnLoose из раздела Media Management разрешает HP Data Protector самостоятельно инициализировать неформатированные ленты при использовании политики размещения Loose. Если не включить данный параметр, то при отсутствии форматированной ленты Вы каждый раз будете получать запрос на установку новой ленты (mount request) и задание резервного копирования не будет выполняться пока Вы его не выполните.

Изменения данного параметра вступает в силу только после перезапуска сервисов HP Data Protector (по крайней мере в версии 9.04). Поэтому после его изменения перезапустим сервис:

# omnisv -stop
# omnisv -start

Fillword на FC коммутаторе

Thu, 24 Sep 2015 02:51:15 +0300

При подключении любых FC устройств в сеть SAN на коммутаторах Brocade недостаточно просто воткнуть устройства, добавить алиасы и зонирование. Правильные парни всегда делают как минимум одну вещь — смотрят статистику подключенных портов. А если позволяет оборудование и версии микрокода ещё и тестируют соединение при помощи функционала Diagnostic Port (D_Port). И то и другое нужно чтобы убедиться в том, что все SFP, FC кабели работоспособны, совместимы и линк устойчив.

Но сейчас я хочу рассказать не о том, как тестировать FC соединения, а о крайне распространенной ошибке, которая очень часто не связана с аппаратными проблемами — это быстрое увеличение значения счетчика er_bad_os (Invalid ordered set).

Проблема

Предположим вы скоммутировали новое оборудование в порт 10/1 коммутатора. Далее Вы по привычке выполняете следующие действия:

Активировали порт, если он вдруг был выключен.
# portenable 10/1

Посмотрели статус порта.
# portshow 10/1

Сбросили счетчики статистики для порта.
# portstatsclear 10/1

Проверили статистику порта.
# portstatsshow 10/1

Иногда можно обнаружить, что сразу после сброса статистики счетчик er_bad_os не нулевой и крайне быстро увеличивает своё значение. Периодически это сопровождается тем, что из-за этого порт не инициализируется нормально. Вы с разницей в несколько секунд делаете portstatsshow и видите, что этот параметр постоянно увеличивается.

Решение

Самое время поменять параметр fillword для порта. Дело в том, что в стандарте на 8G сменился кадр-заполнитель, который посылают друг другу устройства в случае простоя линка. В стандартах 1G, 2G, 4G Fibre Channel использовалась комбинация Idle/Idle, но в более современных имплементациях она сменилась на Idle/ARBFF. На восьмигигабитных коммутаторах Brocade по умолчанию fillword так и остался Idle/Idle. Поэтому меняем его следующей командой:

# portcfgfillword <port number> <fillword value>

Например:

# portcfgfillword 10/1 3

Всего режимов fillword четыре о чем Вы можете узнать из мануала.

Catalyst over FC

Sat, 15 Aug 2015 02:51:15 +0300

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

Catalyst over FC
Federated Catalyst

В данном опусе я расскажу о том, что такое CoFC (Catalyst over FC) и как это заставить работать в связке с HP Data Protector.

Типы доступа

Устройства HP StoreOnce можно использовать в виде трёх типов объектов:

VTL (Virtual Tape Library) поверх Fibre Channel либо iSCSI.
NAS по протоколам CIFS и NFS v3.
StoreOnce Catalyst с использованием сети 1G Ethernet либо 10G Ethernet.

Из всех трёх типов подключения, последний всегда имел явные преимущества, описание которых не входит в цель данной статьи. Поэтому best practice guide всегда гласил, что лучше использовать Catalyst Store, когда есть такая возможность. Теперь третий пункт данного списка пополнился возможностью доступа к Catalyst Store по протоколу Fibre Channel.

Зачем нужен

Итак, Catalyst over FC, позволяет получить доступ к хранилищу Catalyst Store используя инфраструктуру Fibre Channel. Это довольно полезный функционал для заказчика у которого нет инфраструктуры 10G Ethernet, но эксплуатируется FC SAN. Также встречаются ситуации, когда 10G Ethernet покрывает не всю сеть компании, а только какие-то её сегменты (например только ядро сети). В этих ситуациях может быть очень уместным использование функционала CoFC.

В перспективе CoFC и обычный Catalyst over Ethernet смогут использовать одно и то же хранилище. Т.е. бекап, сделанный через CoFC может быть восстановлен через Catalyst over Ethernet и наоборот, бекап сделанный через Catalyst over Ethernet может быть восстановлен с использованием CoFC. На данный момент в версии 9.04 этот функционал не реализован.

Функция Catalyst Copy в данный момент работает пока только поверх IP сети.

Совместимость

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

На сервере выполняющим роль Cell Manager установлена версии HP Data Protector не ниже 9.02.
На CoFC клиенте установлена версии агентов не ниже 9.02.
Версия прошивки StoreOnce не ниже 3.12.0.
Версия ОС клиента: Windows Server 2008 R2, Windows Sever 2012, Red Hat Enterprise Linux 6.x, SuSE Linux 11, HP-UX 11.31.

Также в качестве ПО резервного копирования поддерживается Symantec NetBackup, существуют подключаемые модули для резервного копирования для Oracle RMAN и Microsoft SQL сервера, но это отдельная тема.

Как настроить

В Web GUI StoreOnce найти список WWPN адресов FC портов. Заодно с той же вкладки скопировать идентификатор CoFС, который понадобится во время настройки устройства со стороны софта резервного копирования.
Сделать зонирование на коммутаторах SAN. Здесь всё стандартно и никаких особенностей именно по конфигурированию зонинга для StoreOnce нет. Если у Вас восьмигигабитный коммутатор Brocade, то не забываем про fillword
После применения новой конфигурации зонирования, хост должен увидеть новые устройства. В Windows это должно выглядеть как на картинке снизу (кроме количества устройств). Также в Web GUI StoreOnce можно заметить, что количество логинов увеличится (поле “number of logins”).Менеджер устройств Windows со списком CoFC устройств
Чтобы софт резервного копирования (в нашем случае HP Data Protector) понял, что нужно использовать CoFC вместо Catalyst через Ethernet, нужно вместо IP адреса либо DNS имени в поле “Deduplication System” устройства StoreOnce использовать идентификатор либо alias, который мы получили в пункте 1. Идентификатор отличается от alias лишь тем, что alias можно редактировать нажав кнокку “Edit”, хотя первые пять символов в любом случае должны быть «COFC-», т.к. именно эти символы являются своеобразным тегом, который дает знать Data Protector, что это не имя, которое нужно искать в DNS, а устройство CoFC.Настройка CoFC устройства в Data Protector
После этого можно выбрать в списке шлюзов (gataways) одну из систем и нажать кнопку “check”. Если всё в порядке, то статус должен смениться на “ОК”. После этого, все политики резервного копирования у которых в качестве цели указано данное устройство, будут использовать CoFC.