Зато нагружается процессор хоста _в момент бэкапа_, что снижает его производительность, и, как следствие, скорость записи. От чего ушли - к тому пришли.

> Это особенно актуально для VMWare, где сетевой ресурс часто ограничивает коэффициент консолидации.

Если датасторы VMware хранятся на NetApp FAS, то они обычно уже дедуплицированы на момент бэкапа (и весьма эффективно, обычно, по практическому опыту, 70-90%. Если использовать нетапповское же решение репликации Volume SnapMirror, то трафик оказывается дедуплицированным.

> Низкий коэффициент дедупликации (fixed-length block алгоритм)

На VTL есть и variable block.

> обычно не удаётся добиться больше, чем 10-20% дедупликации

У NetApp на этот счет есть другие сведения.

> Дедупликация делается по расписанию ПОСЛЕ того, как данные записаны на диск.

Да, и это не минус, повторюсь, это огромный плюс! Процесс дедупликации никак не влияет на производительность системы, так как асинхронен с процессами. А место… Что место? Это просто диски. Диски купить куда как проще и дешевле, чем производительность и время сохранния/восстановления. Как я уже говорил по другому поводу: получить производительность по цене дисков это весьма неплохой deal по нынешним временам.

> Для бэкапов эта функция почти бесполезна именно по причинам перечисленным выше.

Я ответил?

- Если делать дедупликацию на хосте, то запись идёт быстрее, так как данные по сети передаются в уже дедуплицированном виде и сеть загружается намного меньше. Это особенно актуально для VMWare, где сетевой ресурс часто ограничивает коэффициент консолидации. Чаще всего при миграции с физических на виртуальные хосты приходится переделывать всю схему бэкапа и дисковая дедупликация здесь к сожалению никак не помогает.
- Низкий коэффициент дедупликации (fixed-length block алгоритм), обычно не удаётся добиться больше, чем 10-20% дедупликации, в интернете полно материала на эту тему. Решения специально заточенные под эту задачу дают намного лучший результат.
- Дедупликация делается по расписанию ПОСЛЕ того, как данные записаны на диск. Даже если можно 100Гб дедуплицировать до 90Гб, первоначально всё равно нужно будет 100Гб свободного места.

Вообще моё личное субъективное мнение - самое лучшее место для такой дедупликации - “файловые шары”. “Включил и забыл” и место экономится.

Для бэкапов эта функция почти бесполезна именно по причинам перечисленным выше.

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

> чтобы снизить нагрузку на сеть, особенно при бэкапах на расстоянии.

В решении NetApp “на расстояние” ( на вторичное, удаленное хранилище) передаются уже дедуплицированные на первичном хранилище данные. То есть сперва оно бэкапится локально (не слишком разумно сразу бэкапить удаленно, помним про неободимость быстрого рестора оперативного бэкапа “только что”), дедуплицируется в процессе жизни, после чего реплицируется уже дедуплицированным.

??нтересно, на основании чего вы думаете, что дедуплицировать лучше на сторадже? Понятно что у NetApp выбора особенно не было, но в зависимости от задачи будут разные аргументы “за” и “против”. Раз уж мы взялись за бэкап, то здесь всё совсем неоднозначно. Традиционно бэкап - это самые большие потоки данных и логично их дедуплицировать на стороне хоста, чтобы снизить нагрузку на сеть, особенно при бэкапах на расстоянии. DataDomain, вот, придумал DD Boost, который дедуплицирует данные на стороне бэкап сервера, хотя на сторадже уже давно это умеют делать, как с этим дела у НетАппа?

Ну тут я могу лишь сказать, что считаю возложение задачи дедупликации на сторадж, выбранный NetApp абсолютно правильным.

> иначе бы NetApp не предлагал за них $ 1.9 миллиарда. :)

Мое мнение (которое может не совпадать с мнением NetApp) что в истории с покупкой DDUP NetApp покупал в первую очередь клиентскую базу.

> NetApp VTL, как отдельный продукт, вообще собираются прибить

Там вообще запутанная история какая-то. Официально это звучт так: прекращена дальнейшая разработка VTL как продукта. Продолжается его продажа по состоянию на сентябрь прошлого года. Почему-отчего - комментариев получить не удалось, увы.

ОК, просто ваша серия постов прочиталась иманно так. Раз посты называются часть 1,2,3,4, я за вас додумал, что вы рассматриваете вариант замены снэпшотами традиционной связки “бэкап софт-лента”. “Бэкап софт-диск” - более равнозначная замена, это всё, что я хотел сказать.

Если я вас не так понял, то беру свои слова обратно, мир-дружба-жевачка.

>Самое смешное, что в недавнем посте в параллельном треде (про VTL) меня чуть
>не на британский флаг порвали, оспаривая необходимость эмуляции ленты на
>VTL, “ведь все давно умеют писать на диски”. Строго говоря все это действительно
>так. Например популярный Backup Exec 10d (и далее), появившийся в 2006, если
>не ошибаюсь, году, именно потому и “d”, что умеет использовать диски нативно.
>NetBackup 6.5 умеет это точно, про 6.0 не помню, 5.0 умел работать с дисками как
>с “псевдолентами”.
>Так кто из современного бэкап-софта не умеет писать на диски нативно или через
>“псевдоленту” (без эмуляции) хотя бы?

??мелось в виду, что если использовать традиционные политики типа “полный бэкап раз в неделю/инкрементальный раз в день” с дисками, то дисковое решение быстро становится слишком дорогим, вы сами об этом писали. Только сейчас вендоры начали добовлять фичи в бэкап-софт типа той же дедупликации, которые делают задачу бекапа на диск экономомически оправданной.

>Ну насчет “не получилось” это еще вопрос, кому больше хотелось. У NetApp есть
>уже лет пять как есть и продается вполне неплохой свой собственный продукт этого
>класса - NetApp VTL.

Ну NetApp VTL с DataDomain я сравнивать не стал бы, это разного класса продукты, иначе бы NetApp не предлагал за них $ 1.9 миллиарда. :)

Знаете что самое сложное в “общении с читателями”?
Разгорваривать с “вчитывающими”. Так я называю тех, которые вместо прочтения того, что написано автором, то есть мной, начинают читать (и спорить следом) то, что автор не писал, а то, что их самих “беспокоит” в даный момент.
За прошедшие полторы недели меня успели обвинить (по порядку):
1. В том, что я предлагаю выкинуть все ленты, и использовать только диски
2. В том что я пиарю NetApp и пощу проплаченне посты (на тот момент даже слово NetApp ни в одном посте из трех еще даже не упоминалось).
4. В том, что приведенные мной описания “наполнены однобокими расчетами” (при том что я вообще никаких ценовых расчетов кроме цены отдельного устрйства “по прайсру” не привел).

Может что и пропустил, лень бегать по комментам.

Можете смело добавить к этому ваше: “что снэпшоты - это самый правильный метод решения задачи бэкапа на диски”.

Возможно вы будете шокированы внимательно прочитав пост, но то, что вы там “прочитали” родилось в вашей голове, и я этого не говорил. Спасибо за доверие, конечно, но если вы хотите говорить со мной, то давайте говорить о том, что я на самом деле утверждал, а не о том, что вы мне приписали. Благодарю за внимание :)

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

Самое смешное, что в недавнем посте в параллельном треде (про VTL) меня чуть не на британский флаг порвали, оспаривая необходимость эмуляции ленты на VTL, “ведь все давно умеют писать на диски”. Строго говоря все это действительно так. Например популярный Backup Exec 10d (и далее), появившийся в 2006, если не ошибаюсь, году, именно потому и “d”, что умеет использовать диски нативно. NetBackup 6.5 умеет это точно, про 6.0 не помню, 5.0 умел работать с дисками как с “псевдолентами”.
Так кто из современного бэкап-софта не умеет писать на диски нативно или через “псевдоленту” (без эмуляции) хотя бы?

> Ну и про DataDomain с которым у НетАппа не получилось

Ну насчет “не получилось” это еще вопрос, кому больше хотелось. У NetApp есть уже лет пять как есть и продается вполне неплохой свой собственный продукт этого класса - NetApp VTL.