Posts tagged ‘snapshots’

SnapVault

Продолжим наш курс Back to basics. Кроме репликации SnapMirror у NetApp есть еще один Snap-что-то продукт – SnapVault. Давайте посмотрим, что это и для чего может в жизни сгодиться.

SnapVault, как можно догадаться из названия, это средство, позволяющее сложить снэпшоты (Snap) на долговременое хранилище (Vault), то есть это такое средство бэкапа данных с системы хранения, например главной, рабочей, или, в терминах NetApp – Primary, на резервную, или Secondary.

Зачем? Ну, зачем вообще используется резервное копирование на другой сторадж? Чтобы обезопаситься и обезопасить данные от физического отказа системы хранения. Почму бы для этого не использовать SnapMirror? Очень просто. Потому же, почему RAID это не бэкап. Репликация никак не поможет в случае повреждения непосредственно данных. Поврежденные данные, например испорченные на уровне приложения, точно также отреплицируются на резервную систему, и вы будете иметь два комплекта плохих данных. Тут выручили бы снэпшоты. Но снэпшоты, как вы помните, хранятся на самой системе хранения, непосредственно на исходном томе, такова их принциппиальная конструкция, и если мы вдобавок ко всему, имеем поврежденную или физически потерянную primary систему хранения, то вместе с ней погибнут и данные снэпшотов. Хорошо бы эти снэпшоты уметь выносить куда-то наружу, чтобы потом иметь возможность из них исходные данные не любой сохраненный момент восстанавливать. Вот как раз этим и занимается SnapVault.

Continue reading ‘SnapVault’ »

Как вы делаете бэкапы?

Думаю, что все мои читатели уже относятся к категории “уже делающих бэкапы”. Однако остается вопрос: как именно он их делают? Какой метод создания резервных копий данных вы выбрали для вашей системы хранения NetApp?

[poll id="6"]

Опрос, как и всегда, анонимен.
Возможны множественные ответы.
Если у вас есть вариант, не перечисленный выше, и который вы хотите указать - не стесняйтесь привести его в комментариях.

Все предшествующие опросы в блоге можно посмотреть в рубрике Опрос

Снэпшоты в DOT8.x Cluster-mode

Также как и в Data ONTAP 7-mode, в Cluster-mode с версии 8.1 есть снэпшоты. Сохранились все привычные пользователям NetApp команды snap reserve, snap sched, snap list, но добавилось несколько новых команд и возможностей.

Также добавились некоторые дополнительные опции в некоторых командах

Также есть изменения и в способе задания распсания снэпшотов. Если раньше это делалось командой snap sched, указывалост имя тома и задавались интервалы в формате cron, то новый механизм использует политики (policy), которые управляются командами add-schedule, modify-schedule и remove-schedule. Для создания же новой политики взятия снэпшотов воспользуйтесь командой snap policy create.

Что такое SnapVault и куда это применить?

В новых Software Bundles, которые приходят новым покупателям систем NetApp часто включены лицензии на SnapVault (пример – Windows Bundle для распродажных FAS2020, о которых я писал ранее). Однако, к сожалению, всё еще не все хорошо представляют себе как это работает, как может применяться, и чем может быть полезно.

SnapVault это средство D2D Backup для систем хранения NetApp (а в случае использования Open Systems SnapVault – OSSV – и для обычных серверов), использующее их возможности по созданию и удаленному хранению снэпшотов.

Как вы знаете, в отличие от всех прочих систем хранения, использующих то, что у них также называется “снэпшоты”, NetApp не только не возражает, но даже поощряет хранить снэпшоты долговременно, непосредственно на дисках. Дело в том, что хранение снэпшотов на дисках, как своеобразной локальной “резервной копии”, вместе с собственно данными, не приводит к падению производительности всей системы хранения, как это происходит с COW (Copy-On-Write) “снэпшотами”. Поэтому на всех системах, кроме NetApp, снэпшоты используются лишь как “временное хранилище” состояния данных. Создали снэпшот в ночной тиши слабозагруженного датацентра, быстро слили на ленты или другое архивное хранилище, и скорее удалить.

NetApp-EMC-snapshots

Не все йогурты снэпшоты одинаково полезны. :)

Но в случае NetApp вы можете локально хранить десятки, если не сотни снэпшотов, и почти мгновенно с них восстановиться в случае сбоя. Однако разумные требования безопасности рекомендуют не хранить резервную копию вместе с оригинальными данными, во избежание ее повреждения вместе с оригинальным датасетом (например при физическом повреждении системы хранения).
Это не означает, что ее нельзя там хранить совсем, но локально сохраненная копия по крайней мере не должна быть единственной резервной копией ваших данных!

Было бы разумно если и хранить копию локально, для максимально быстрого восстановления данных, то отдельный набор – удаленно, на тот нечастый, но возможный случай, когда локальная копия будет повреждена, например вместе со всем хранилищем.

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

Было бы неплохо и копировать снэпшоты наружу как-то “по-снэпшотному”, сохраняя эту их эффективность использования места.
??менно это и делает SnapVault.
SnapVault – это способ хранить снэпшоты рабочих данных на внешнем хранилище, но “по-снэпшотному”, экономя пространство хранения.

Лицензии на SnapVault существуют в двух “ролях”. Одна называется SnapVault Primary, а вторая – SnapVault Secondary.

SnapVault Primary – это лицензия, которая нужна для системы, служащей источником данных, это та система хранения, на которой хранятся непосредственно “боевые” данные, копию которых мы хотим сохранить.

SnapVault Secondary – это лицензия, устанавливаемая на получателя резервных копий. На систему, которая хранит резервные копии от одной или нескольких SnapVault Primary систем.

В качестве SnapVault Primary может также работать так называемый Open Systems SnapVault (OSSV) – программный продукт (его для NetАpp написала компания Syncsort), устанавливаемый непосредственно на сервера под управлением Windows/Linux/etc и позволяющий им играть роль SnapVault Primary систем, делать на них снэпшоты (разумеется с определенными ограничениями, присущими то или иной OS), передавать их на хранение на систему SnapVault Secondary (В роли SV-Sec может быть только NetApp, нет OSSV Secondary), и восстанавливать их с таких снэпшотов, при необходимости.

Как и для чего можно применить SnapVault?

Например можно централизованно хранить резервные копии данных от множества отделений основного бизнеса, где, очень часто, нет достаточного бюджета и ресурсов для организации полноценного бэкап-решения. В случае использования SnapVault вам нужно только раз настроить расписание на удаленных системах и политики хранения резервных копий на центральном хранилище (это может быть выделенная система, или же пространство на основной системе хранения NetApp головной компании, с лицензией SV-Secondary на ней. А с использованием OSSV это можно делать и без систем NetApp в качестве Primary. ?? в дальнейшем резервные копии от всех систем будут автоматически, по расписанию, приходить на ваше хранилище с ролью SV-Secondary в главном датацентре.

SnapVault1

При этом только в первый раз будет передан полный объем хранения (так называемая baseline copy) для создания первоначального “снимка”, в дальнейшем через каналы передачи данных будет передаваться уже только “разностная” информация, например только измененные за день работы блоки данных.
Допустим, что общий объем данных на вашей удаленной системе хранения равен 100GB. Но в течении суток меняется только около гигабайта.
Тогда при первом, baseline transfer, будет передано все 100GB (это можно сделать, например, локально, перед тем, как отвезти систему хранения в удаленный офис), а затем, при ежедневном копировании, будет передаваться всего 1GB. ?? целый месяц ежедневных резервных копирований полной системы на Secondary-системе в центральном офисе займет всего около 130GB.

Также можно использовать SnapVault и для организации удаленной копии данных для Primary-системы для “квази-DR” решения. При этом в качестве резервного хранилища для мощной SnapVault Primary может служить недорогая и с невысокой производительностью, достаточной только для приема и хранения реплики данных, система с лицензией SnapVault Secondary.

SnapVault2

Совместно и интегрированно с NetApp SnapVault могут работать такие программные продукты, как CommVault Sympana Suite и Syncsort Backup Express.

Настраивать и управлять работой SnapVault можно как из командной строки, так и с помощью отдельного программного продукта NetApp – Protection Manager, который также сейчас поставляется в составе многих бандлов, например в ONTAP Essential для FAS3200/6200.

Наилучший способ углубиться в тему – прочесть TR-3487 SnapVault Best Practices Guide,
и TR-3466 Open Systems SnapVault Best Practices Guide.

Я помню, что обещал вам “исследование” по истории фрагментации в файловых системах, но что-то у меня пока куражу нет его дописать на нужном уровне, придется подождать. Читайте пока про SnapVault, а на следущих две недели у меня спланирована большая программа по углубленному “полосканию косточек” EMC VNX/VNXe. Не переключайте ваши браузеры, будет интересно. :)

Что такое aggregate snapshot reserve и зачем он нужен?

Я уже несколько раз упоминал в этом блоге о aggregate snap reserve, пришла пора  подробнее рассказать о том, что это, зачем использутся, и нужно ли это вам.

Вы уже наверняка знаете, что такое и зачем используется Snapshot reserve на уровне тома. Это некий зарезервированный объем общего пространства соответствующего тома, используемый для того, чтобы обеспечить доступность пространства на дисках при создании снэпшотов состояния тома. Это некая условная “граница”, которую может превысить снэпшот, но не может превысить содержимое тома, пользователю тома доступно для записи место, равное объем тома минус резервация на снэпшоты. Это резервирование гарантирует доступность места для хранения данных снэпшотов, а также упрошает администрирование тома, так как пока снэпшоты не вышли за пределы отведенного резерва, свободное пространство, доступное для записи на томе, стабильно и предсказуемо.

Подробнее и с поясняющими картинками про принцип работы Snap Reserve я писал в посте ранее.

Отмечу также, что величина резерва, заданная по умолчанию в 20% от объема тома может быть изменена, и 20% это не hardcoded value, а просто такая вот эмпирически выбранная когда-то величина “по умолчанию”. Можно сделать 50, 15, 10, и даже 0%. Например 0% сегодня рекомендованная величина Snapshot Reserve в случае использования тома для хранения SAN LUN-ов (вместо Snapshot Reserve используется Fractional (или LUN Overwrite) Reserve, о смысле которого я уже также ранее писал).

С Volume Snap Reserve мы более-менее разобрались, но что же такое и зачем нужен Aggregate Snap Reservation, равный, по умолчанию, 5% от объема aggregate?

Aggregate, по сути, представляет собой свообразный мета-volume, просто такой своеобразный том, находящийся в иерархии уровнем ниже обычного FlexVol-тома. Соответственно, задача у этой резервации точно такая же – хранить блоки, использованные в снэпшоте уровня aggregate.

Что же такое “снэпшот уровня aggregate”, кто его делает и зачем он используется?

Снэпшоты на aggregate использует, например, средство SyncMirror, это средство синхронной репликации, используемое, например, в решении MetroCluster.
Кроме того, такие снэпшоты используются для работы средства контроля целостности файловой структуры WAFL, аналога UNIX-ного fsck, ооочень редко на практике применяемого средства WAFL_check (я знаю немало админов NetApp, которые вообще не в курсе, что такое средство у NetApp есть).

WAFL как “файловая система”, вследствие своей архитектуры, поразительно устойчива, 99% админов NetApp действительно никогда не сталкиваются с необходимостью “лечить” WAFL. “Уронить” WAFL в принципе возможно (“Если один человек чего сделал, то другой завсегда сломать может”(с)) но это, как показывает моя практика, довольно нетривиальная задача.

Если вы “уронили” WAFL настолько, что потребовалось использование WAFL_check, то очень сильно сократить этот процесс может наличие автоматически создаваемых снэпшотов аггрегейта. Впрочем, как я знаю, он заработает и без них, однако, на большой системе, починка может занять на пару порядков больше времени, вместо десятков минут – несколько дней.

Также, с использованием снэпшотов уровня aggregate вы можете сделать SnapRestore для aggregate целиком, вместе со всеми томами и LUN-ами на нем, если зачем-то это вам понадобилось.

Кроме этого следует обратить внимание, что какой-то объем пространства на уровне aggregate (то есть не распределенного в volumes, а непосредственно в aggregate) используют следующие средства:

  1. Deduplication  начиная с версии 7.3 хранит свою базу fingerprints непосредственно на уровне aggregate, таким образом, при использовании deduplication вам понадобится какое-то небольшое пространство на aggregate не занятое томами, обычно в зарезервированные 5% эта база помещается
  2. Синхронная версия репликации SnapMirror до версии 7.2.2 записывала данные, попадающие в NVRAM, в специальный файл на root volume по пути /etc/sync_snapmirror_nvlog/<dstfsid>.log[0|1]. Начиная с 7.2.7 эти данные пишутся также на уровне aggregate. Руководство Data ONTAP Online Data Backup and Recovery Guide рекомендует, в случае использования Sync SnapMirror иметь на aggregate место в объеме 20x емкости NVRAM на системе-получателе (destination).
    (обратите внимание, что у NetApp есть два различных средства synchronous replication – SyncMirror и SnapMirror Synchronous mode)
  3. Наконец, не стоит забывать, что запас незанятого места на aggregate довольно значительно снижает величину фрагментации, а правильнее “non-contiguous block factor”. Напомню, что файловая система (любая, NTFS, ext3, WAFL, почти любая современная файловая система), когда ей необходимо записать файл, сперва ищет у себя фрагмент непрерывно свободного пространства, куда и пишет содержимое этого файла. Если, как это обычно бывает при сильно заполненной файловой системе, такого места отдельным, непрерывным куском нет, то файловая система начинает дробить записываемые данные файла на более мелкие фрагменты, которые уже могут располагаться непоследовательно. В наихудшем случае, файловая система располагает свободным местом только в виде отдельных, непоследовательных блоков, разбросанных по файловой системе. Наличие запаса свободного места с точки зрения файловой системы резко улучшает эту ситуацию, и позволяет не накапливать фрагментацию.

Таким образом, как вы видите, идея держать гарантированно небольшое свободное пространство на уровне aggregate имеет определенные основания на системном уровне. Если вы уверены, что ничем из перечисленного вы не пользуетесь, а 5% зарезервированных на aggregate вам жалко, то вы можете уменьшить эту величину, аналогично ситуации с volume snap reservation, , например до 2-3%, практика показывает, что этого достаточно. Можно, хотя это и не рекомендуется, и вовсе отключить эту резервацию. Обратите также внимание, что, как и в случае с volume snap reserve, отключение reservation не отключает возможность использования snapshots, если на структуре (volume или aggregate, соответственно) есть свободное место. Это просто средство некоторого упрощения жизни и работы админа, и только.
Помните, тем не менее о том, что у NetApp за каждым default value стоит какая-то причина, и прежде чем вы не уясните эту причину, я бы не рекомендовал “твикать” не глядя, это все же не “реестр венды” ;).

Посмотреть текущее состояние резервирования и назначенное расписание создания снэпшотов на aggregate:

fas1> snap sched –A
Aggregate aggr0: 0 1 4@9,14,19
- установлено расписание создания снэпшота aggregate в 9, 14 и 19 часов, и хранение с ротацией одного дневного и 4 таких "почасовых" снэпшота.

fas1> snap sched –A aggr0 0 0 0 - создание снэпшотов aggregate aggr0 отключено.

Для изменения величины или отключения резервирования на aggregate вам нужно использовать команду:

fas1> snap reserve –A aggr0 3 – устанавливаем величину резервирования для aggr0 равную 3%

Что есть что в выводе команды snap list?

??ногда приходится сталкиваться с неполным пониманием того, что именно и как выводится в команде snap list.

Давайте на примерах разберем “что есть что”, где и как.

У нас есть том vol1 на 100G, практически пустой.

fas3020a> df -h vol1
Filesystem               total       used      avail capacity  Mounted on
/vol/vol1/               80GB       17MB       79GB       0%  /vol/vol1/
/vol/vol1/.snapshot      20GB       61MB       19GB       0%  /vol/vol1/.snapshot
 
fas3020a> snap list vol1
Volume vol1
working…
 
  %/used       %/total  date          name
———-  ———-  ————  ——–
31% (31%)    0% ( 0%)  Mar 08 00:00  nightly.0
47% (29%)    0% ( 0%)  Mar 07 20:00  hourly.0
57% (32%)    0% ( 0%)  Mar 07 16:00  hourly.1
64% (29%)    0% ( 0%)  Mar 07 12:00  hourly.2
69% (32%)    0% ( 0%)  Mar 07 08:00  hourly.3
73% (29%)    0% ( 0%)  Mar 07 00:01  nightly.1
76% (30%)    0% ( 0%)  Mar 06 20:00  hourly.4
78% (31%)    0% ( 0%)  Mar 06 16:00  hourly.5

В этом выводе, колонка %/used показывает объем, занятый снэпшотами, деленный на количество использованных в настоящий момент блоков на томе, независимо от того, заняты ли они в активной файловой системе, или снэпшотах. Первое число – накопительная сумма для всех показанных снэпшотов. Второе число (в скобках) – только для конкретного снэпшота.

Снэпшоты тома vol1 занимают 78% всех занятых на томе блоков, каждый из снэпшотов занимает примерно 29-32% занятых блоков.

Колонка %/total показывает объем занятый снэпшотами, деленный на общий объем диска. Он включает в себя пространство для данных, плюс snapshot reserve, то есть все использованные и свободные блоки тома. На томе 100GB занято примерно 61MB в снэпшотах, что составляет менее 1% общего объема (поэтому значение – 0).
Значение (в скобках) вычисляется аналогично вышеприведенному для %/used.

Давайте посмотрим, как все изменится, если мы уменьшим размер тома vol1 со 100GB до 1GB.

fas3020a> df -h vol1
Filesystem               total       used      avail capacity  Mounted on
/vol/vol1/              819MB       17MB      801MB       2%  /vol/vol1/
/vol/vol1/.snapshot     204MB       61MB      143MB      30%  /vol/vol1/.snapshot

fas3020a> snap list vol1
Volume vol1
working…
 
  %/used       %/total  date          name
———-  ———-  ————  ——–
31% (31%)    1% ( 1%)  Mar 08 00:00  nightly.0
47% (29%)    1% ( 1%)  Mar 07 20:00  hourly.0
57% (32%)    2% ( 1%)  Mar 07 16:00  hourly.1
64% (29%)    3% ( 1%)  Mar 07 12:00  hourly.2
69% (32%)    4% ( 1%)  Mar 07 08:00  hourly.3
73% (29%)    4% ( 1%)  Mar 07 00:01  nightly.1
76% (30%)    5% ( 1%)  Mar 06 20:00  hourly.4
78% (31%)    6% ( 1%)  Mar 06 16:00  hourly.5

Теперь мы видим, что снэпшоты заняли большее относительное пространство на томе в целом (%/total), то есть занятых ?? пустых, но процент блоков в снэпшотах, относительно всех только занятых блоков на томе (%/used) остался неизменным.

Как всем этим полагается правильно пользоваться?

Величины %/used и %/total полезны при оценке того, насколько правильно выбрана величина snapshot reserve. Нехватка резерва приводит к тому, что снэпшоты “вылезают” за пределы резерва, и начинают занимать место в пространстве данных. Когда команда df показывает величину заняости диска больше 100% – это как раз такой случай: снэпшоты переполнили пространство резерва и начали заполнять пространство собственно данных. Это не страшно, особенно если для тома работает autogrow (и есть место на aggregate) или autodelete (и вы можете безболезненно удалить некоторые старые снэпшоты), но, тем не менее, этого следует избегать для более однозначной организации данных.

Когда вы решаете удалить тот или иной снэпшот, рекомендуется пользоваться командой snap delta или snap reclaimable, чтобы выбрать наиболее эффективный с точки зрения освобождения места снэпшот.
Число после точки в имени снэпшота увеличивается со взятием нового снэпшота. Например, сли вы берете снэпшот каждый час, то hourly.1 взятый в 9 утра, станет hourly.5 в 13:00. Также это работает и в случае daily- или weekly-снэпшотов.
Обратите внимание, что снэпшоты с явно заданным именем (то есть не те, что создаются по расписанию), а также снэпшоты, созданные SnapMirror и SnapVault не изменяют своего имени при создании новых.

SnapVault

SnapVault это “двухкомпонентная” система резервного копирования данных D2D, “с диска на диск”, основнанная на технологии снэпшотов.

Система SnapVault состоит из двух участников: системы хранения с лицензией SnapVault Primary, работающая “источником” данных, и системы с лицензией SnapVault Secondary, “получатель и хранитель” данных, в качестве которой может выступать как система NetApp FAS, так и специально разработанная для подобных применений, система Nearstore - емкое дисковое хранилище на недорогих SATA-дисках.

Главная идея, положенная в основу этого продукта - “непрерывно-дифференциальное” резервное копирование, использующее уникальные возможности снэпшотов NetApp.
Вы знаете, что системы хранения NetApp обладают уникальной для рынка особенностью. Вследствие особой, отличной от всех аналогов у конкурентов технологии снэпшотов, они могут создавать и хранить не 14-16 снэпшотов на систему, как у конкурирующих предложений, а до 256 снэпшотов на каждый том, созданный на системе, что в сумме составляет многие тысячи снэпшотов на систему.
Вдобавок, использование снэшпшотов удобно еще и тем, что ровно ничего не стоит пользователю, по сравнению с реализацией снэпшотов у конкурентов, где их использование может серьезно ухудшить производительность системы хранения в целом.

??спользование же снэпшотов в NetApp удобно в том числе и для сравнительно долговременного хранения, делая из них своеобразный “дисковый бэкап”, для мгновенного восстановления данных пользователя, в случае необходимости. Просто дайте команду snap restore [мой том] [нужный снэпшот], или же просто скопируйте из снэпшота нужные файлы, созданные в желаемый момент времени, поверх испорченных в вашем томе.

Но что же делать, если мы хотим хранить более чем 256 мгновенных снимков наших данных, или, что более важно, хранить наши “снимки”-резервные копии на отдельном, защищенном и удаленном хранилище, но при этом сохранить всю простоту и легкость реализации восстановления, характерную для оригинальных снэпшотов?
Вот для этого и был придуман SnapVault - “склад снэпшотов”.

Система с ролью Primary (она включается введением соответствующей лицензии, и не требует дополнительной инсталляции какого-либо софта) служит “источником данных”. Система с ролью Secondary, она может быть одна на много Primary, например если вы осуществляете централизованное резервное копирование из “филиалов” или удаленных офисов и храните резервные копии данных, осуществляет сбор и хранение множества “снэпшотов” от множества primary-систем в ваше централизованное хранилище.

При первой инициализации Primary SnapVault-система передает на Secondary полную копию своего содержимого, так называемую baseline. Это продолжительный и объемный процесс, сравнимый с классическим full backup. После этого, Secondary-система всегда передает только содержимое снэпшотов, “дифференциальные копии” системы, разницу между состоянием от предыдущего и нынешнего состояния и содержимого данных.

Пример:
У нас есть база данных размером 1GB. Мы делаем с нее ежечасный снэпшот, и этот снэпшот хранится на Secondary SnapVault-системе. Каждый час в системе накапливается примерно 2MB измененных данных. Это могут быть новые записи или изменения в старых.
При создании baseline copy, при первичной инициализации, Primary-система передает весь этот 1GB на вторичную систему. Когда передача завершена, первичная система начинает ежечасно передавать примерно 2MB в час. Однако, с точки зрения пользователя, на вторичной системе он видит, словно бы полную копию, созданную ежечасно. Видит, и может ее использовать и восстановить свой раздел и данные из нее, также как с обычным снэпшотом. Разница заключается только в том, что места на дисках используется всего 2MB*24h в день, не считая объема baseline copy, которая создается один раз в самом начале.

Подобная практика сейчас стала популярной и в традиционных системах резервного копирования, обычно под названием “forever incremental” и подобных ему, когда full backup создается один раз, а затем делается только incremental, а при необходимости восстановления восстанавливается Full и все необходимые Incremental с момента создания исходного Full, а для пользователя каждый бэкап представляется полной копией системы.
Удобство SnapVault в данном случае в том, что эта функция оказывается встроенной в систему хранения, и не требует использования внешних host-based систем резервного копирования.

Для не-NetApp систем хранения, возможно использование в качестве Primary и так называемой OSSV - Open Systems SnapVault, специального программного агента, стоящего на хост-сервере, к которому подключена сторонняя система хранения, или даже его локальные диски, и осуществляющего функции Primary SnapVault, как раассмотрено выше. Secondary SnapVault и в этом случае должен быть системой NetApp FAS или Nearstore. С помощью OSSV вы можете использовать возможности SnapVault и без необходимости использовать систему хранения NetApp в качестве Primary.

Любопытно, что сегодня в SnapVault интегрирована и дедупликация, так, если ваша Secondary-система имеет лицензию дедупликации, то процесс дедупликации будет запущен после окончания передачи baseline copy, и сможет, в ряде случаев заметно, уменьшить, хранимые на Secondary объемы baseline.