Комментарии 10
Очень жаль, что в Veeam дедупликация реализована на уровне непрерывных архивов в WinRAR.
В то время как конкуренты используют полноценную блочную дедупликацию всего хранилища резервных копий.
В то время как конкуренты используют полноценную блочную дедупликацию всего хранилища резервных копий.
Возьмём конкурентов с самой достойной дедупликацией, к примеру VMware VDP и EMC Avamar. У VDP дедупликация «для всего хранилища», но размер хранилища ограничен 2TB. У Avamar тоже дедупликация «для всего хранилища», но размер хранилища ограничен 8TB. И сравним это с Veeam: маркетингово Вы правы, дедупликация у нас не для всего хранилища резервных копий, а только внутри одной задачи резервного копирования (одного архива). Но в тоже время, размер задачи не ограничен (то есть может быть к примеру 64TB, и даже 128TB – что сильно больше 8TB). То есть можно весь ЦОД при желании в одну задачу положить, и дедуплицировать между всем вообще. Вывод о реальной глобальности дедупликации напрашивается сам?
Почему не сравнить с CommVault, IBM или Unitrends (ваш прямой конкурент)?
Какой в этом случае будет RTO? И как разделять сервисы с разным RPO?
То есть можно весь ЦОД при желании в одну задачу положить, и дедуплицировать между всем вообще.
Какой в этом случае будет RTO? И как разделять сервисы с разным RPO?
Собственно, не имею ничего против Veeam.
У вас отличное решение для резервного копирования, но оно не идеально и в некоторых аспектах уступает конкурентам.
У вас отличное решение для резервного копирования, но оно не идеально и в некоторых аспектах уступает конкурентам.
Насчёт идеала, он не возможен. Для каждой проблемы есть только одно наилучшее решение, при этом разные поставщики решают разные проблемы, наиболее актуальные для их рыночного сегмента. Соответственно принимаются некие архитектурные решения, у каждого из которых есть свои плюсы и минусы.
Например, мы изначально решили, что бакап должен быть файлом, который можно легко скопировать и унести. А не дедупликационным хранилищем, «пришитым» к СХД намертво. Для нас плюсы этого подхода (мобильность, portability) перевешивают минусы. А глобальность дедупликации всегда можно при желании добиться, храня все резервные копии на железке со встроенной дедупликацией. Например, тот же Windows Server 2012 со включенной дедупликацией вполне пойдёт, если размеры данных не слишком большие.
Например, мы изначально решили, что бакап должен быть файлом, который можно легко скопировать и унести. А не дедупликационным хранилищем, «пришитым» к СХД намертво. Для нас плюсы этого подхода (мобильность, portability) перевешивают минусы. А глобальность дедупликации всегда можно при желании добиться, храня все резервные копии на железке со встроенной дедупликацией. Например, тот же Windows Server 2012 со включенной дедупликацией вполне пойдёт, если размеры данных не слишком большие.
Просто потому, что я не в курсе ограничений у названных вами решений. У них похуже дедупликация, поэтому плотно ими не интересовался, так что боюсь наврать. Хотел лишь подчеркнуть, что у многих голова замылена маркетинговом «глобальности», когда в реальности она вообще не глобальна (как говорится, те же яйца, вид сбоку). 8 хранилищ по 8TB равняется 8 задач по 8 TB.
По Вашим вопросам:
1. На RTO никак не (в случае Veeam, по-крайней мере).
2. Насчёт RPO Вы теоретически правы, вот только серьёзных инфраструктурах с десятками TB чаще чем раз в сутки VMware сложно бакапить из-за проблем коммита снапшотов в бизнес часы.
3. Unitrends не конкурент, это только они так считают. В реальности же, у них менее 5000 клиентов за 25 лет — у нас больше 80000 за 6 лет. Мы их не встречаем в шорт листах никогда.
По Вашим вопросам:
1. На RTO никак не (в случае Veeam, по-крайней мере).
2. Насчёт RPO Вы теоретически правы, вот только серьёзных инфраструктурах с десятками TB чаще чем раз в сутки VMware сложно бакапить из-за проблем коммита снапшотов в бизнес часы.
3. Unitrends не конкурент, это только они так считают. В реальности же, у них менее 5000 клиентов за 25 лет — у нас больше 80000 за 6 лет. Мы их не встречаем в шорт листах никогда.
На Computerworld недавно был цикл стате про дедупликацию:
Data deduplication in the cloud explained, part one
Data deduplication in the cloud explained, part two: The deep dive
Data deduplication in the cloud explained, part three: Implementation methods
Data deduplication in the cloud explained, part one
Data deduplication in the cloud explained, part two: The deep dive
Data deduplication in the cloud explained, part three: Implementation methods
Как я понимаю, все механизмы дедубликации предполагают, что сравниваемые данные выравнены на границу блока (сектора блочного устройства например или больше) или даже целого файла.
А еще поступающие данные могут содержать упакованные, это сводит дедупликацию на нет, пока их не распакуешь.
В принципе дедупликация, это частный случай упаковки файлов, соответственно перед этим лучше бы эти файлы распаковать и хранить 'максимально комфортно для их сжатия'.
p.s. какие есть решения для дедупликации данных в сетевом трафике? грубо говоря передавать bzdiff от данных, которые ранее уже были переданы. Особенно это весело когда каждый пакет данных отличается на доли процента.
А еще поступающие данные могут содержать упакованные, это сводит дедупликацию на нет, пока их не распакуешь.
В принципе дедупликация, это частный случай упаковки файлов, соответственно перед этим лучше бы эти файлы распаковать и хранить 'максимально комфортно для их сжатия'.
p.s. какие есть решения для дедупликации данных в сетевом трафике? грубо говоря передавать bzdiff от данных, которые ранее уже были переданы. Особенно это весело когда каждый пакет данных отличается на доли процента.
Про дедупликацию сжатых данных — если речь идет скажем о сжатом системном разделе диска (где есть сжатые системные файлы, которые почти все одинаковые на одной ОС на разных машинах), то в принципе такие сжатые данные будут дедуплицироваться не хуже оригинальных данных, так как они и в сжатом виде одинаковые.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Введение в дедупликацию данных