lan free и vss transportable

Разбирался с возможность гонять данные при архивировании/восстановлении не по сети. Похоже здесь имеются две возможности:

1. То что в документации называется lan free. Например имеются пара серверов с данными лежащими на полке подключенной через FC, имеется также стриммер (или устройство его ) подключенный также по FC. Делаем эти сервера медиа серверами, подключаем к ним стриммер (ставим галку Fibre Channel устройств), пишем данные как локальный бэкап. Данные с полки текут на стриммер без выхода в сеть.
2. То что в документации - vss transportable. Например имеется сервер с данными на полке подключенной через FC, имеется медиа сервер с массивом локальных дисков (этот момент не принципиален) и картой FC. Нужно писать с сервера на диски медиа сервера без выхода в сеть. Ставим VSS hardware provider для имеющейся полки и на сервер и на медиа сервер. При создании задания архивирования MS Shadow Copy Writers выбираем Backup type - VSS transportable backup.

Это может быть объединено: сервер с данными на полке, медиа сервер со стриммером.

• Сервер командует полке создать снимок своего раздела
• Медиа сервер обращается к полке и получает снимок по оптике
• Медиа сервер по оптике же пишет на стриммер

Ошибка svn: Could not authenticate to server: ignored NTLM challenge

При попытке подключения к svn серверу через https (webdav) например:

svn list https://svn/svn/configs

выдает приведенную в заголовке ошибку. Имя пользователя и пароль не запрашивает.

Вот причина: http://savannah.nongnu.org/support/?108061

Вот как предлагается решить: http://lists.manyfish.co.uk/pipermail/neon/2012-May/001470.html

Вот что сделал я:

1. apt-get install libneon27
2. удалил /usr/lib/@libneon-gnutls.so.27 указывающую на libneon-gnutls.so.27.2.6
3. создал /usr/lib/@libneon-gnutls.so.27 указывающую на libneon.so.27.2.6

Ошибка исчезла. Пользователь/пароль запрашивается.

У меня авторизация через MS AD. Пробовал указавать пользователя как username и как DOMAIN\username - оба варианта были приняты.

Время ожидания устройства

По умолчанию DP ожидает устройство занятое другим заданием 60 минут. Если за это время устройство не освобождается, то сессия завершается неудачей (failed). Для изменения периода ожидания нужно изменить значение SmWaitForDevice в файле global. В win 2008 этот файл лежит в \ProgramData\OmniBack\Config\Server\Options

Ошибка mdadm: No devices listed in conf file were found

Поставил wheezy на софт raid1. Установка прошла без ошибок. Однако загрузиться после установки не удалось. Пляски вокруг:

• grub2
• /boot/grub/grub.cfg ( /etc/default/grub, /etc/grub.d/*.* -> update-grub2)

• mdadm
• /etc/mdadm/mdadm.conf (mdadm --examine --scan)

успеха не принесли. Поковырялся с разными uuid ами: blkid, mdadm. Менял все и в различных сочетаниях (напрямую из меню grub, через grub.cfg, через 09_softraid в /etc/grub.d, даже в mdadm.conf). Но все как обычно решилось одной строкой: http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg345155.html

Решение:

1. Вернул все (конфигурационные файлы mdadm.conf, grub.cfg) в состояние после установки.
2. Добавил в /usr/share/initramfs-tools/init /bin/sleep 10
   перед
   
   

   maybe_break mount
   log_begin_msg "Mounting root file system..."
   . /scripts/${BOOT}

3. Удалил и создал заново initrd:
   

   update-initramfs -k all -c

4. Пересоздал конфигурацию и переустановил grub2:
   update-grub2
   grub-install /dev/sda
   grub-install /dev/sdb
5. Перезагрузил
   

Сжатие при копировании на ленту

Хотелось бэкап для удаленного хранения сделать на одну ленту. Надеялся, что можно будет указать выполнить software compression при object copy с дисковых библиотек на ленту. Похоже это невозможно. В GUI нет ничего, в cli для omniobjcopy соответствующего ключа также нет. В документации понятно - тишина. Т.е. если нужно сжимать, то делать это нужно при бэкапе на дисковую библиотеку.

IDB Positions records

При просмотре использования IDB насторожил процент использования записей в Positions - 99% (при этом файл CDB был далек от наполнения).

Пытался снизить его: проверил выполняется ли Daily Maintenance, начал чистить базу вручную. Без видимого результата.

Оказалось зря волновался: http://h30499.www3.hp.com/t5/Data-Protector-Support-and-News/IDB-Positions/td-p/4870066

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

Удаление не существующего клиента

На cell manager редактировать файл cell_info. В windows 2008 r2 этот файл лежит по пути:

%SYSTEMDRIVE%\ProgramData\OmniBack\Config\Server\cell\