Не реклама :)))))
В комментариях готов обсудить, чем данное средство лучше/хуже самосбора на базе кучи дисков с дедупликацией…
В качестве хранилища резервных копий пару лет назад мы выбрали HP StoreOnce 4700. Выбор был обусловлен тем, что наше средство резервного копирования хорошо заточено на ленты, и мы достаточно продуктивно ранее работали с HP VLS 6500. StoreOnce отличается достаточно высокой ценой, при этом обладает рядом преимуществ:
- встроенная дедупликация и неплохие показатели скорости резервного копирования (до 8 Тб/час на 8 дисковых полок или примерно 16Гбит/с – для 4700);
- дополнительно приобретаемая лицензия репликации, которая интегрируется с дедупликацией;
- дополнительная лицензия Catalyst, позволяющая осуществлять дедупликацию перед передачей данных на StoreOnce. Заявлена скорость резервного копирования до 22Тб/ч; :))
- централизованная и, вроде бы, удаленная поддержка от вендора
Помимо достаточно негуманного ценника за аппаратное решение, есть программные версии до 50Тб, в том числе и бесплатная – на 1 Тб, разворачиваемые в виде виртуальных машин vSphere, Hyper-V и KVM.
В программных решениях все дополнительные лицензии включены (репликация), но производительность значительно ниже (до 120Мб/с).
В нашей поставке StoreOnce выглядит как HP’шный сервер и две дисковые полки (2*2Тб*12). Используемой емкости внутри порядка 37Тб.
У разных вещей коэффициент дедупликации различный, к примеру, SQL дедуплицируется раз в 50, по-моему. А вот виртуальный экчендж, забэкапленный с помощью Veeam – всего в 2 раза. StoreOnce подключен к серверу B&R в качестве CIFS-шары, добавлен как HP Appliance (то есть Veeam располагает на HP бекап без своего сжатия).
Прикидываться StoreOnce умеет как VTL, так и NAS (CIFS/NFS). Чтобы прикинуться Catalyst (некий аналог NAS), нужна лицензия и софт, который умеет с Catalyst работать. К примеру, Veeam B&R8 не умеет работать с Catalyst, научится только в девятке. HP DP 8.0 умеет работать с Catalyst over ethernet, HP DP 9.02 – научился работать с Catalyst over fc.
Я скачал виртуальный апплайнс и использовал его для создания РК баз SQL. Первые же результаты были впечатляющими: 100 гб база SQL забэкапилась в четыре раза быстрее (с 2х часов на iSCSI VTL до 30 минут – Ethernet Catalyst).
Вот она магия, сказал я и поржал…
Дело в том, что виртуальный апплайнс я развернул на тонком диске, следовательно первая запись на этот диск в принципе не могла различаться в четыре раза :))
Но и Data Protector тоже не врал – он действительно закончил резервное копирование на Catalyst за 30 минут. Скорость записи на виртуальный диск была одинаковой, поэтому я решил, что HP в отчете “приукрашивает” действительность. Но с точки зрения логики все корректно – скорость “записи” действительно была в четыре раза выше :))
После этого я проверил создание первого бэкапа виртуального SQL через сеть 10Gb – скорость еще выросла – 24 минуты 🙂
После этого я запустил бэкап второй раз – и вот тут меня ждало диво дивное – 19 минут 🙂
Третий бэкап – через 1Гбит до StoreOnce VSA также прошел за 19 минут.
Как вы видите, загрузка сети не превышает 1Gb даже для первого бэкапа. Последующие вообще не нагружают сеть.
В нашей поставке Catalyst не было, мы бэкапим на железный StoreOnce либо через VTL (DP), либо через CIFS (Veeam). Я попросил аппаратную оценочную лицензию и поделал некоторые тесты.
Бэкап файлов быстрее не стал, видимо, мы упираемся в какие-то другие ограничения файл-бэкапа. А вот полный бэкап 1Тб SQL вместо 8 часов стал занимать 2 🙂
Минусом использования Catalyst, естественно, стала повышенная загрузка SQL-сервера, так как дедупликация стала выполняться на нем.
Как вариант, можно использовать выделенного агента, который будет “читать” базу SQL, сам ее дедуплицировать и передавать на StoreOnce.
Добрый день, а на каких скоростях происходит восстановление данных с StoreOnce с помощью Veeam? Известно, что проблема всех дедупов без landing zone это процесс регидрации данных, который может затянуться.
Добрый день.
Производительность восстановления ВМ так себе: 37Гб восстановились за 36 минут.
Восстановление 5Гб базы SQL из бэкапа месячной давности, сделанной через VTL – 3 минуты.
С другой стороны, восстанавливал на тест базу Exchange из оперативного бэкапа Veeam, лежащего на другом FC-хранилище.
Производительность восстановления была в районе 69Гб/час, так что, возможно, у нас не очень корректно настроена инфраструктура.
поделитесь пожалуйста ссылкой для скачки бесплатной StoreOnce VSA
http://www8.hp.com/us/en/products/data-storage/free-sovsa.html
Добрый день. Не возникало проблем при использовании backup copy на CIFS шару с помощью Veeam? У нас очень долго идет удаление старой точки.
Пока не пробовал удалять старые точки. По моим прикидкам, это произойдет через 2-3 месяца, когда наберется нужное количество точек восстановления Backup Copy.
Может ждать не приятный сюрприз. http://forums.veeam.com/veeam-backup-replication-f2/merging-oldest-incremental-backup-is-painfully-slow-with-v8-t25188-15.html
Решения насколько я понял нет до сих пор.
Печально, если так. Активной поддержки у нас уже нет, поэтому мы имеем шансы встать на “metadata handling bug”.
И на overbuild тоже (у нас много терабайт exchange не успевало за сутки пролезть пару раз – потом я стал осторожнее и начал отключать задание на время копий бэкапа).
С другой стороны, бэкап копи делается раз в месяц, причем сначала копируется актуальная информация, а потом уже слияние (если судить по обычному бэкапу).
Так что нам главное, чтобы бэкап пролез, а там пусть хоть месяц шуршит.
Добрый день. Я как то переписывался с инженером Veeam. Он утверждал, что Veeam умеет работать со StoreOnce по FC протоколу. Так ли это и как это выглядит?
Есть опыт использования связки StoreOnce и Symantec NetBackup?
Для общего развития – что такое landing zone и metadata handling bug? 🙂
1) http://forums.veeam.com/veeam-backup-replication-f2/why-is-veeam-so-terrible-with-dedupe-appliances-t21882-30.html
“Landing zone” – некая площадка, где свежие бэкапы лежат без дедупликации. Соответственно, попытка запустить FLR или Instant Recovery на них гораздо быстрее, чем на традиционном дедуп-апплайнсе.
Кстати, да: instant recovery и обычный recover виртуальной машины – прошли у меня примерно с одинаковой скоростью.
2) “metadata handling bug” – видимо, некий косяк Veeam, выражающийся в повышенном использовании метаданных при бэкапе на медленные носители. Вроде бы как должен быть исправлен в v8U2.
3) Veeam v8 умеет использовать Storeonce по FC только в виде VTL (эмулированных приводов). Подключение к шаре – по сети.
В v9 обещают научить его работать с Catalyst – это как раз технология про этот пост. Как это будет реализовано – я не знаю.
Вдогонку про п3: скорость при бэкапе veeam->vtl примерно 60-70Мб/с. Тоска. На сетевую папку писалось примерно до 100Мб/с, хотя инкременты сейчас тоже до 70 скатились 🙁
Сейчас восстанавливал виртуальную машину объемом 50Гб
Полтора часа 🙁
Видимо, Veeam Backup Copy – не для StoreOnce 🙂
Попробую на фул бэкапы переделать или NFS протестировать.
Коллеги с подобной инфраструктурой говорят, что это “фича” CIFS или thin volume 3par.
На толстых томах с NFS скорость восстановления порядка 50Мб/с (против моих 12Мб/с).
какие мысли будут про
http://www.emc.com/products-solutions/trial-software-download/vvnx.htm
?
Не знаю, надо много читать
тут первая статья про тестирование дудупликации на HP SO и Veeam
k9job.ru и вывод не в пользу хп.
Роман, а StoreOnce добавляли как шару или как Dedupe Storage в Виме?
пробовали ли Вы монтировать NFS железного StoreOnce к esxi?
у нас монтируется, но содержимое на ней не видимо.
Нет, не пробовал.