— Максимально использовать инкрементные копии. Проверку на повторяемость будут проходить не все блоки диска, а только те, что помечены, как изменённые.
— Если сервер виртуальный, то копировать его без установки агента (брать снапшот с гипервизора) и проводить дедупликацию на машине, установленной рядом.
— «Душить» скорость копирования (network throttling) встроенными средствами, «размазывая» нагрузку на процессор по времени.
Но необходимость в этом возникает нечасто. В реальной жизни инкрементные копии на уровне блоков могут проскакивать за считанные минуты глубокой ночью.
1. Принципиальное отличие в том, что встроенная в ОС дедупликация выполняется в офлайне.
То есть:
— Оставляйте свои данные, мы ими займёмся.
— А когда будут готовы?
— Мы вам позвоним.
Вы (а) не можете предсказать, когда занятое место на диске уменьшится, (б) успеет ли оно уменьшится к тому моменту, когда нужно будет делать следующую копию, следующую за следующей…, (в) не можете предсказать заранее, НАСКОЛЬКО уменьшится занятое место.
В то же время онлайн-дедупликация в Arcserve UDP сразу же выдаёт данные в дедуплицированном виде. Правда, цена за это — повышенные требования к быстрой памяти (оперативной или SSD), где должна помещаться вся таблица хэшей.
2. Дедупликация в Arcserve UDP производится на источнике, то есть ещё перед передачей по сети. Вы не только ужимаете полную копию на, например, 91%, но и сокращаете сетевой трафик на 91% (за вычетом служебных данных Ethernet/TCP/IP).
Вы можете выбрать, какой размер блока использовать при дедупликации: 4,8,16 или 32 Килобайта. На последней картинке видно, как размер блока влияет на эффективность дедупликации и потребность в быстрой памяти (оперативной или SSD).
В предыдущих версиях программы резервного копирования Arcserve UDP по умолчанию предлагали использовать блок данных в 4 Килобайта. Теперь стали рекомендовать 16 Килобайт.
Мне просто нужно время, чтобы разобраться с незнакомыми мне вопросами. А пока спорное содержимое уберу. Вот если бы Вы технические вопросы задавали, я бы постарался на них сразу ответить.
Спасибо за конструктивную критику. Расчёт спецификаций с сайта удалён. Продажи осуществляются только через партнёров.
Лицензии за сокеты и за серверы взаимоисключающие. Либо одно, либо другое.
Просто выгоднее для гипервизора взять лицензию на его физические процессоры (и копировать все его виртуальные машины), а для остальных физических серверов (не гипервизоров) — лицензию на сервер.
(правда, в эту спецификацию не войдёт модуль непрерывного резервного копирования)
Что касается сравнения с Hyper-V Replica, то, во-первых, как уже упоминали выше, всё равно нужно хранить данные в исторической перспективе, а одна лишь репликация этого не даст. Во-вторых, это решение, заточенное только для виртуальных машин Hyper-V, и если требуется что-то универсальное, например, для репликации ещё и физических машин, то оно уже не подойдёт.
Если говорить о «Veeam c переключением источника данных на саму резервную копию в процессе восстановления», то функционал очень похож на функционал Arcserve UDP, с той лишь разницей, что Arcserve UDP позволяет выполнить кроссплатформенное восстановление, например, моментально восстановить физическую машину в виртуальную среду. Или (хотя это уже экзотика) виртуальную машину из Hyper-V в среду vSphere.
Вы правы, репликация резервному копированию не замена. Но может хорошо его дополнить.
И ещё, программная репликация, о которой я лишь вскользь здесь упомянул, позволяет в некоторых случаях вести журнал, то есть позволяет при восстановлении откатиться на заданную точку во времени. Обычно не очень давнюю, например, не более, чем на неделю назад. Но это уже хороший задел, чтобы можно было использовать её в качестве средства оперативного резервного копирования.
Репликация на уровне блоков тоже не безупречна. В частности, она делает идентичными основную и резервную машины. В то время, как программная репликация может копировать лишь отдельные файлы. Например, копируя базу данных, но не трогая файлы операционной системы.
Надеюсь, что смогу более подробно описать эту технологию в отдельной статье.
— Если сервер виртуальный, то копировать его без установки агента (брать снапшот с гипервизора) и проводить дедупликацию на машине, установленной рядом.
— «Душить» скорость копирования (network throttling) встроенными средствами, «размазывая» нагрузку на процессор по времени.
Но необходимость в этом возникает нечасто. В реальной жизни инкрементные копии на уровне блоков могут проскакивать за считанные минуты глубокой ночью.
То есть:
— Оставляйте свои данные, мы ими займёмся.
— А когда будут готовы?
— Мы вам позвоним.
Вы (а) не можете предсказать, когда занятое место на диске уменьшится, (б) успеет ли оно уменьшится к тому моменту, когда нужно будет делать следующую копию, следующую за следующей…, (в) не можете предсказать заранее, НАСКОЛЬКО уменьшится занятое место.
В то же время онлайн-дедупликация в Arcserve UDP сразу же выдаёт данные в дедуплицированном виде. Правда, цена за это — повышенные требования к быстрой памяти (оперативной или SSD), где должна помещаться вся таблица хэшей.
2. Дедупликация в Arcserve UDP производится на источнике, то есть ещё перед передачей по сети. Вы не только ужимаете полную копию на, например, 91%, но и сокращаете сетевой трафик на 91% (за вычетом служебных данных Ethernet/TCP/IP).
В предыдущих версиях программы резервного копирования Arcserve UDP по умолчанию предлагали использовать блок данных в 4 Килобайта. Теперь стали рекомендовать 16 Килобайт.
Используемый хэш — SHA1.
Лицензии за сокеты и за серверы взаимоисключающие. Либо одно, либо другое.
Просто выгоднее для гипервизора взять лицензию на его физические процессоры (и копировать все его виртуальные машины), а для остальных физических серверов (не гипервизоров) — лицензию на сервер.
http://arcserve.su/skoka.php
(правда, в эту спецификацию не войдёт модуль непрерывного резервного копирования)
Что касается сравнения с Hyper-V Replica, то, во-первых, как уже упоминали выше, всё равно нужно хранить данные в исторической перспективе, а одна лишь репликация этого не даст. Во-вторых, это решение, заточенное только для виртуальных машин Hyper-V, и если требуется что-то универсальное, например, для репликации ещё и физических машин, то оно уже не подойдёт.
Если говорить о «Veeam c переключением источника данных на саму резервную копию в процессе восстановления», то функционал очень похож на функционал Arcserve UDP, с той лишь разницей, что Arcserve UDP позволяет выполнить кроссплатформенное восстановление, например, моментально восстановить физическую машину в виртуальную среду. Или (хотя это уже экзотика) виртуальную машину из Hyper-V в среду vSphere.
И ещё, программная репликация, о которой я лишь вскользь здесь упомянул, позволяет в некоторых случаях вести журнал, то есть позволяет при восстановлении откатиться на заданную точку во времени. Обычно не очень давнюю, например, не более, чем на неделю назад. Но это уже хороший задел, чтобы можно было использовать её в качестве средства оперативного резервного копирования.
Репликация на уровне блоков тоже не безупречна. В частности, она делает идентичными основную и резервную машины. В то время, как программная репликация может копировать лишь отдельные файлы. Например, копируя базу данных, но не трогая файлы операционной системы.
Надеюсь, что смогу более подробно описать эту технологию в отдельной статье.