Страница 1 из 1

Performance of Backup/Restore in ARCserve

СообщениеДобавлено: 20 сен 2004, 10:55
Dmitry Slepchenko
Доброго времени суток!

Недавно мной проводился эксперимент по восстановлению инф-ции с ленты на Novell Netware 5.1. Результатами я немного озадачен :-(

Итак, дано:

Novell Netware 5.1 sp 5 (с трад.файл.системой)
Несколько томов, один из них - 70 Гигабайт.
BrightStor ARCserve Backup Agent v.9.0

В качестве бэкапера:
Win2000 Server sp 4
BrightStor ARCserve for Windows Release 11.0 build 2674
HP LTO Ultrium-1

Вобщем...
В среднем, 66 Гигабайт "ложатся" на ленту со скоростью 700 MB/min (~ 90 минут).
А вот восстановление с ленты идет со скоростью 250 MB/min (~260 минут).

Вопрос: это нормально или что-то не так?

Restore проводилось на разные тома (в том числе на разные дисковые массивы и на одиночные винты). Ессно, под Netware, и ессно SCSI. Скорость во всех вариантах приблизительно одинаковая :-(
Так как в случае форсмажора придется восстанавливать критически важные данные, то за "восстановление в течение ~ 4 часов", мягко говоря, намекнут на что-то нехорошее...
Можно ли с этим бороться и как?
У соконфуциев такие же скорости восстановления или другие? Если не трудно, то приведите Ваши скорости для сравнения. Заранее спасибо.

С ув.,
Дмитрий

СообщениеДобавлено: 20 сен 2004, 12:51
Владимир_Степанов
Да, у меня были почти те же скорости на той же конфигурации. Но полсе добавки оперативки сокорсть слегка возросла
BrightStor ARCserve for Windows еще довольно шустро работает
BrightStor ARCserve for Linux просто тормоз при восстановлении.

СообщениеДобавлено: 20 сен 2004, 13:01
Dmitry Slepchenko
Владимир_Степанов писал(а):Да, у меня были почти те же скорости на той же конфигурации. Но полсе добавки оперативки сокорсть слегка возросла
BrightStor ARCserve for Windows еще довольно шустро работает
BrightStor ARCserve for Linux просто тормоз при восстановлении.

Возросла скорость восстановления или бэкапа? Интересует именно "восстановление".
ARCserve работает на Win2000 с 512 Mb RAM с гипертрейдингом. Мало?
Сеть - гигабит.

СообщениеДобавлено: 20 сен 2004, 16:03
Музалёв Николай
Есть у меня ИМНО сл. порядка:
при копировании система АС использует агент копирования. Одно из его свойств - ужатие информации перед передачей на хост. Т.е. сжатие происходит "по месту", с использованием ресурсов сервера-источника.
А при восстановлении расжимать данные будет уже сам хост. Затраты времени как и при обычном архивировании - от 2 до 4 раз.
Думаю, ничего необычного в таком положении вещей нет.

Теперь по поводу нехороших намеков. Копирование файлов на МЛ вобще и в Арксерве в частности не предусматривает восстановления потоком. (Мне помнится, что его изначально позиционировали как "систему управления архивированием" ) Так что АС как то изначально предполагался для восстановления одиночных файлов/каталогов. (имеетися в виду в контексте данного вопроса) Или без спешки, по крайней мере....
Если же есть необходимость быстрого восстановления всех данных, то следует обратиться к программам образо-ориентированным, посекторным или пораздельным.
Например тот же ПОРТЛОК (чудо, кстати говоря, а не программка!!)

PortLock Storage Manager

СообщениеДобавлено: 20 сен 2004, 16:46
Игорь Костюшко
Здравствуйте, Николай!
Не праздно интересует вышеозначенная тема.
С полгода назад пытались ее официально приобрести, но не смогли найти поставщика на территории РБ.
Если Вы нашли такую компанию - не могли бы Вы поделится адресом сей.
С Уважением , Игорь Костюшко.

СообщениеДобавлено: 20 сен 2004, 18:05
Музалёв Николай
Ну конечно жеСОФТЛАЙН .
2325281 , info@softline.by
Телнфонируйте подтверждение.

СообщениеДобавлено: 21 сен 2004, 10:33
Dmitry Slepchenko
Музалёв Николай писал(а):при копировании система АС использует агент копирования. Одно из его свойств - ужатие информации перед передачей на хост. Т.е. сжатие происходит "по месту", с использованием ресурсов сервера-источника.

Немного не согласен.
Ну... для копирования, я думаю, агент не нужен... а вот для бэкапа нужен, поэтому он и называется Backup Agent.
И на мой взгляд нужен для правильного "переноса в архив" всех аттрибутов файлов и NDS, управления потоком и вычислением CRC файлов до и после передачи. Об этом факте, кстати, говорит использование FPSM.NLM - для операций с плавающей запятой.
Думаю, также агент согласуется с другими агентами (например, DataBase Agent, Open File Agent). Плюс к этому, агент адаптивно настраивается под среду передачи (размер буферов и т.п.).
Если бы происходило "ужатие", то неизбежно тратилось бы процессорное время... и как следствие, время "уноса" на ленту увеличилось... что противоречит показаниям скорости (почти максимальные для Ultrium 230).
Косвенное доказательство: если "почитать" NLM-ку, то там даже намека нет на какое-либо архивирование "на лету". Названия параметров есть всякие разные... но они у меня никак не ассоциируются с архивированием.

Изначально у меня была мысль о том, что на скорость восстановления влияет избыточная запись на пятый рейд. После восстановления на отдельный HDD (быстрый) с прибл. таким же временем - мысль ушла и не сказала когда вернется...

Вместе с HP Ultrium 230 шел диск TapeWare XE Backup. Может кто-нибудь что сказать про этот софт? Подходит ли он под понятие "имидж-партиция-сектор-кластер-BackUp" ?

(голосом диктора) А теперь внимание вопрос:
давно ли Вы проверяли аварийный план восстановления критически важной (объёмной!) информации? Время хорошее?

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

Портлок - да... текут уже давно не только слюни, но и слезы...

С ув.,
Дмитрий