Сегодня я хочу рассказать две вещи про Вим.
1) В этом году компания Veeam обещает выпустить девятую версию своего флагманского продукта – Backup and Replication. Больше всего из заявленного функционала мне нравится запись на ленты в несколько приводов и консоль администрирования сервера. Я тестировал запись на свои ленты в v7 и v8 – скорость записи на один привод удручает. 🙁
А если бы Вим научился работать с лентами напрямую, минуя жесткий диск, то и мечтать о большем было бы не нужно. Я, конечно, понимаю, что у всех разные ситуации, но у меня ситуация такая, что есть много терабайт в VTL или MSL и немного терабайт на СХД. И мне как раз актуальнее система резервного копирования, которая умеет работать с лентами напрямую. Прямо сейчас это освободило бы мне десяток терабайт…
2) А еще я протестировал работу механизма Backup Copy в Veeam Backup and Replication v8, призванного реализовать схему GFS (дед, отец, сын) для резервного копирования.
Смысл этого механизма в том, чтобы на регулярной основе “откладывать” в сторону недельные, месячные, квартальные и годовые резервные копии на другое хранилище.
В отличие от обычного бэкапа на ленту (Backup to Tape) – это обыкновенный бэкап, который вы спокойно можете использовать для восстановления данных.
Мне интересно было проверить работу этой схемы, после постановки задачи по наличию месячных резервных копий за последние полгода. Чтобы не заниматься долгим процессом восстановления (бэкапа с ленты -> почтовых баз Exchange из бэкапа -> Clean Shutdown -> восстановления информации из базы в пользовательский ящик) я решил посмотреть – получится ли у меня отложить месячную резервную копию и использовать ее в Veeam Explorer for Exchange.
В качестве репозитория была подключена сетевая папка с системы HP StoreOnce 4500 с функционалом дедупликации.
Для повышения эффективности “аппаратной” дедупликации Veeam складывает на папку бэкап в несжатом состоянии. Такой функционал есть при архивации на HP StoreOnce и EMC Data Domain. Это можно заметить, сравнив размер полной резервной копии на StoreOnce и на обычном хранилище. Я же хочу поделиться цифрами по двум месячным резервным копиям для почты и виртуальных машин.
– два бэкапа Exchange. На StoreOnce лежат два файла: 5,7Тб и 4,5Тб. Полная резервная копия и инкремент до следующей месячной копии. Согласно данным в консоли StoreOnce: User Data – 11,3Тб; Data on Disk = 5,2Tb. Одна полная копия Exchange на обычном хранилище (то есть с сжатием и дедупликацией от Veeam) – 5Тб.
– два бэкапа виртуальной инфраструктуры. На StoreOnce лежат два файла: 3,9Тб и 1,5Тб. Аналогично – Full+Incr. Согласно данным в консоли StoreOnce: User Data – 5,9Тб; Data on Disk = 1,7Tb. Одна полная копия инфраструктуры на обычном хранилище – 2,2Тб.
Я считаю, цифры просто фантастичны. HP StoreOnce круче дедуплицирует, чем Veeam 🙂
Хоть в чем-то TSM лучше Veeam 🙂
А про дедупликацию не удивительно, с DD и на большем количестве копий результат может быть ещё круче..
Veeam дедуплицирует в пределах джоба + можно указать размер блока дедупликации, а сторванс все, что на нем лежит
Если я правильно понял – то нет.
Не знаю, как с сетевыми каталогами, но в формате VTL дедупликация StoreOnce идет на библиотеку.
Соответственно, есть рекомендация делать разные библиотеки на разные типы файлов. У нас сейчас три
Да, про разные библиотеки не подумал.
А в veeam из скольких job состоят бекапы?
Из двух: одна под Exchange, вторая – под остальные ВМ.
Точнее в veeam даже не джоба, а единовременного создания бекапа машин.
Хранилище с дедупликацией и в пределах джоба бекапы за разные моменты между собой хорошо дедуплицирует, плюс между разными джобами в пределах библиотеки. Отсюда и такая разница
А в чем преимущество TSM над Veeam?
Он умеет писать/читать напрямую на ленты, в том числе в несколько потоков или копий. Но метаданные всё равно приходится хранить на дисковом пуле из-за чего полностью перенести бекапы VMware на ленты можно только для DR.
Что такое TSM?
>В качестве репозитория была подключена сетевая папка с системы HP >StoreOnce 4500 с функционалом дедупликации.
Почему как сетевая папка? 4500 ведь может подключаться по FC…
Может как привод.
Но v8 пишет только на один привод, скорость у меня была порядка 70 мб/с.
А на сетевую папку по гигабиту давала 100-110мб/с.
TSM – IBM Tivoli Storage Manager (вроде бы). Средство резервного копирования IBM.
Верно, но с одним приводом у TSM тоже скорость не фонтан.
В случае с Veeam и использовании HP StoreOnce как VTL есть два косяка (если сравнивать с TSM):
1) Veeam не умеет бэкапить на ленты ВМ. Только уже существующие бэкапы;
2) Veeam не умеет восстанавливать с лент ВМ. Восстанавливаются только бэкапы.
3) Скорость записи на один “привод” – не фонтан.
С другой стороны, если использовать HP StoreOnce как сетевую папку, это вполне нормальный репозиторий. То есть туда можно бэкапить ВМ и восстанавливать их оттуда.
Использование FC на текущий момент неоправданно.
В v9 некоторый смысл в нем будет, но все равно удобства работы с лентами нет.
В Veeam ленты – это исключительно инструмент архивации и создания выносного бэкапа.
В TSM – ленты – это вполне рабочий механизм создания резервных копий.
Попробовал делать бэкап на StoreOnce 4420 работающего в режиме VTL с помощью интеграции HP DataProtector и Exchange. Коэффициент дедупликации 1,15. Обьем данных около 900ГБ
Как то совсем грустно 🙁 .
Может так плохо из-за того что в режиме VTL или Exchange принципиально плохо дедуплицируется?
А сколько бэкапов на сторванс вы уже сделали?
Они все полные или дифференциальные?
В эффективности дедупликации разницы нет: делать на шару или на VTL.
Главное при этом – использовать одну библиотеку или одну шару.
Пока выполнил только один полный бэкап. Учитывая то что часто одни и те же письма отправляются многим пользователям коэффициент дедупликации должен был быть поболее. Сейчас идёт ещё один полный бэкап. По его прохождению завтра отпишусь. Насчёт того что VTL может отличаться по эффективности от режима шары: у VTL как у всякого драйва есть поняти размер блока и по умолчанию в DataProtector 7 этот размер равен 64kb. Возможно при дедупликации для режима VTL берётся также 64kb блок.
С письмами у Exchange не все так однозначно.
Письма-то отправляются, но саму базу Exchange как-то поджимает, чтобы она не занимала тонну места…
В результате, вы дедуплицируете уже не набор мелких файлов, а, грубо говоря, некий архив.
Думаю, с двумя-тремя полными копиями вы выйдете на коэффициент дедупликации 2:0. У меня, до того как я начал перетряхивать ящики между базами, было еще побольше.
У меня бэкапятся два кластерных пакета. Сегодня утром на StoreOnce лежало два бэкапа первого пакета (860GB каждый)и один второго(985GB). Всё это заняло на StoreOnce 1756GB. Коэффициент 1,62. Получилось чот вторая копия первого пакета добавила примерно 100GB.
Ну нормально 🙂
Но надо еще исследовать сторванс.
Я на него Backup Copy складываю в инкрементальном режиме.
Так скорость восстановления из последнего инкремента 12 Мб/с 🙁
>Так скорость восстановления из последнего инкремента 12 Мб/с 🙁
Это в связке Veem 8 + StoreOnce в виде сетевой папки?
Угу, причем с парой допущений:
1) Storeonce подключен как CIFS-шара. При этом Виэм подключает эту шару как StoreOnce и отрубает свою архивацию. Согласно опытам коллег из другого региона, NFS с Veeam работает получше (хотя якобы в последней прошивке их уравняли).
2) Backup Copy делает копию бэкапа на сторванс. Вместо хранения кучи полных бэкапов он создает инкременты.
Соответственно, при восстановлении из самого свежего бэкапа вам необходимо собрать F+i+i+i+i+i+i (например). Вот производительность “сборки” из этого набора бэкапов и составила у меня 12Мб/с.
С другой стороны, есть полезный опыт восстановления баз SQL:
Мы делали “офлайн” копию на ленты – 1,83 Тб баз SQL слилось за 2,5 часа (VTL->MSL).
Правда, я не знаю, сколько приводов VTL участвовало в чтении кассет.
Воюю с интеграцией Veeam 9 + StoreOnce Catalyst по FC. Не выходит каменный цветок 🙁 Устройство видится, видно сколько на нем свободного пространства, а писать не получается. Может кто сталкивался с таким?
OSCLT_ERR_SERVER_OFFLINE. Err: -1404
Failed to open file [COFC-CZJ03305GY01] Store1:/srv1_vm-125_/srv1.vmx
Failed to create file [[COFC-CZJ03305GY01] Store1:/srv1_vm-125_/srv1.vmx]
https://www.veeam.com/wp-hpe-storeonce-catalyst-configuration-guide.html
По гайду настраивали?
Ага, в нем же и нашел в чем была проблема, хоть и не сразу:
Note: The number of StoreOnce Catalyst over Fibre Channel devices available must be at least one more than the number of streams if the backup application or plug-in can open command sessions during a backup or restore.
Добавил Devices per Initiator Port и все заработало.
Ну и как? :))
Какие скорости рисует?
300МБ/с при бэкапе(full)
С инкрементом ясно поменьше.
Смутило то что instant recovery стартовал довольно бодро, а вот сторадж вмоушен на СХД шел больше часа. и это VM в 40ГБ.
Ого 🙂