Включать ли дедупликацию для бэкапов?

Question

[vitalyrline]

Здравствуйте!
Имеется виртуальная машина Windows Server 2019 Standart. Внутри Veeam Backup & Replication CE, который будет снимать бэкапы с других ВМ и складывать их на отдельный раздел, который отформатирован в REFS. Включать ли дедупликацию на этом разделе? С одной стороны экономится место. Но с другой стороны, если вдруг будут повреждены общие блоки для нескольких резервных копий, то они все станут нерабочими? Или не стоит заморачиваться по этому поводу?

Comments

[RStarun]

Периодически задаюсь тем же вопросом.
Вероятно лучшего решения здесь нет. Просто берем калькулятор и считаем расходы на емкость.
В разных системах копирования, с разными механизмами дедупа сталкивался с невозможностью восстановления. Где-то не во время отключилось питание, где-то странное поведение дисков. Хорошо что это было не критично. Понятно что это частный случай, но вероятность потерять данные в любом случае возрастает. С одной стороны это не основные данные, а лишь бэкапы. С другой стороны - когда бекапы нужны, они являются единственным источником и ценность их резко возрастает.

Answer 1

[rPman]

Veeam Backup не хранит файлы как они были в оригинале, а создает что то типа архива в своем формате, со своими технологиями сжатия и дедупликации, поэтому файловая система не найдет в них копий.

Дедупликация это в принципе очень слабый механизм сжатия данных, который срабатывает в ограниченном количестве случаев (пофайлово, а точнее поблочно), когда ты делаешь копию файла и чуть чуть его редактируешь (меняя только его часть, вот например текстовые, если ты вставишь/удалишь символ в начале, это сдвинет содержимое всего файла и он будет считаться полностью изменившимся, но замена одного символа в начале позволит хранить только тот блок, в котором было это изменение, а остальное содержимое будет ссылаться на оригинальный файл)

Comments

[Ziptar]

Veeam Backup не хранит файлы как они были в оригинале, а создает что то типа архива в своем формате, со своими технологиями сжатия и дедупликации, поэтому файловая система не найдет в них копий.

В вин сервер реализована блочная дедупликация

Дедупликация это в принципе очень слабый механизм сжатия данных

Файловая - да, блочная - нет. Для бэкапов вообще великолепна. Тем более, в Veeam есть параметр для создания архивов с учётом использования блочной дедупликации. Еженедельный архив виртуалок за последние 5 лет в пространстве, не сильно отличающимся от исходного размера? Да легко.

Единственная проблема, что если вдруг придёт пушной зверёк и придётся такой бэкап собирать по кускам - не соберёшь.

[rPman]

автор говорит про включение дедупликации на разделе а не в настройках veeam

[Ziptar]

rPman, а теперь ещё раз прочитай внимательно то, что я написал.

[rPman]

Ziptar,

создания архивов с учётом использования блочной дедупликации

чьей?
ReFS использует блочную, а как это сделано в Veeam backup? или они как то используют дедупликацию файловой системы?

p.s. про великолепие бакапов, мне понравились файловые бакапы с использованием rеflink и simlink, когда на одном разделе создается полная копия указанных каталогов, с указанием предыдущего каталога (rsync --rеflink=auto --link-dest=предыдущий бакап), и вместо копирования уже существующих файлов будет сделан его rеflink, это та же дедупликация, но не автоматическая (она проще и поддерживается почти везде), как бонус, для чтения бакапа не нужен никакой другой софт, файлы в нем доступны как есть.

[Ziptar]

rPman,

чьей?

Вин сервер, в данном случае

ReFS использует блочную, а как это сделано в Veeam backup? или они как то используют дедупликацию файловой системы?

ReFS тут вообще ни при чём. Вин сервер и ntfs дедуплицирует прекрасно.
Параметр указывает виму не использовать собственные методы сжатия.

p.s. про великолепие бакапов, мне понравились файловые бакапы с использованием rеflink и simlink, когда на одном разделе создается полная копия указанных каталогов, с указанием предыдущего каталога (rsync --rеflink=auto --link-dest=предыдущий бакап), и вместо копирования уже существующих файлов будет сделан его rеflink, это та же дедупликация, но не автоматическая (она проще и поддерживается почти везде), как бонус, для чтения бакапа не нужен никакой другой софт, файлы в нем доступны как есть.

Не путай блочную дедупликацию с теневыми копиями или инкрементными/разностными копиями

[vitalyrline]

Ziptar, Ну т.е. для бэкапов не самое надёжное решение?

[rPman]

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

[vitalyrline]

rPman, Тут вопрос надо ставить по другому. Не понизит ли дедупликация надёжность хранения?

[rPman]

vitalyrline,

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

и кстати, если бакап делать пофайловый, не в архиве, то в случае повреждения, нужно будет чинить только файловую систему, и инструментов сделано миллион и главное, шансы восстановить часть - высокие

Если же сломается файл архива veeam, то не представляю, как его вообще чинить, какими инструментами и сколько специалисты за это потребуют денег

p.s. про дедупликацию - у тебя в архиве без дедупликации 10 одинаковых файлов, физически лежат 10 раз, половина файлов умерло, но ты все равно получишь этот файл

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

[vitalyrline]

rPman,

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

Это как раз то, что я и хотел услышать. Спасибо!

[rPman]

vitalyrline, и что? то же самое будет и при штатной дедупликации veeam и при инкрементальном бакапе и при любой другой технологии сжатия данных

риски смерти данных (от бадблоков или из-за смерти железа) уменьшают рейдами 1/5/6, общие риски уменьшают количеством резервных копий, разнесенных по разным местам, риски вирусов и кривых рук - регламентами и регулярными тестирования бакапов на восстанавливаемость и т.п.

логически форматы как способ что то там улучшить находятся далеко в в конце списка и актуальны из-за удобства использования и принципиальных возможностей

[Ziptar]

vitalyrline, сложно сказать, бэкапы надо проверять регулярно в любом случае, и тогда имея на руках мертвый прод будем иметь живой бэкап, а имея на руках мертвый бэкап и живой прод будем иметь возможность создать ещё один бэкап
Я в своей мелкой конторе завел двойную схему - один еженедельный бэкап на дедуплицируемом iscsi томе, другой обычный полный еженедельный бэкап с глубиной в две недели (+ теневые копии файлопомойки каждый час, если кто что потрет случайно, а бывает это периодически); но у меня данных немного, можно такое позволить

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

[vitalyrline]

Ziptar,

Я в своей мелкой конторе завел двойную схему

Это о копировании ВМ?

[Ziptar]

vitalyrline, да

Answer 2

[CityCat4]

А что, veeam сам в дедупликацию не умеет? Вообще дедупликация очень полезна - та, которая в бэкапере. Но у Вас неверный подход.

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

Сервер бэкапов - самый последний рубеж обороны. Если он пал - суши весла

Comments

[vitalyrline]

Я может быть что-то упустил... Разве существует Veeam B&R под линукс?

[RStarun]

При большом желании можно размещать тома V B&R на отдельной машинке умеющей в снепшоты. Хранилка как раз может быть под линуксом, с отдельными учетными данными и вообще живущая почти отдельно. Но это усложнение.

[Ziptar]

В два-точка-первых - в другой географической локации