WinServer: какие проблемы может вызывать взаимодействие дедупликии, vss и wbadmin?

Question

[Ziptar]

Решил тут поиграться с дедупликацией данных и немножко охренел. Архив, накопившийся за 7 лет, "похудел" почти в 8 раз, а он составляет всего лишь пятую часть от общего объёма данных. Всё прочее пока не трогал. Но это лирика.

Вопрос в следующем: чем грозит взаимодействие штатной дедупликации winsrv2012r2 и vss, в условиях хранения снимков vss на отдельном томе? В худшем случае потерей части vss снимков? Как с дедупликацией работает windows backup? На сколько я понял, восстановление оптимизированных архивов с дедуплицированными данными возможно только на winsrv2012r2 (в данном случае) - это все возможные проблемы. Я правильно понимаю этот момент?

Answer 1

[АртемЪ]

Архив, накопившийся за 7 лет, "похудел" почти в 8 раз,

Это нормально, бывает и в 20.

чем грозит взаимодействие штатной дедупликации winsrv2012r2 и vss, в условиях хранения снимков vss на отдельном томе?

Ничем, теневые копии не дедуплицируются.
Потеря VSS снимка возникает только при нехватке места, на томе хранения снимка.

Кстати зачем вам теневые копии на дедуплицируемом томе? Это же архив насколько я понял.

На сколько я понял, восстановление оптимизированных архивов с дедуплицированными данными возможно только на winsrv2012r2 (в данном случае) - это все возможные проблемы.

Примерно так.
Подключить диск вы можете к любому компьютеру, но прочитать дедулицированные файлы он не сможет.
Нужно чтобы служба дедупликации обязательно была запущена.
Она есть в Win Server от 2012 и выше, так же ее можно вкорячить при некотором желании и на десктопные версии винды от 8ки и выше.

По поводу VB ADMIN - он хранит данные в образе диска, на этом образе диска все изменения пишутся как теневые копии, это если речь про бэкап целых томов.
А если бэкап папок - банальные зипы.

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

Так же дедупликация имеет общие механизмы с BranchCache, и отлично работает в паре.

Comments

[Ziptar]

Кстати зачем вам теневые копии на дедуплицируемом томе? Это же архив насколько я понял.

Ну, это всё же про рабочие данные вопрос. Архив был сдедуплицирован именно потому, что на томе с ним vss не выполняется [заведомо безопасно], и просто в качестве эксперимента - посмотреть сколько места сие действо сэкономит.

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

А оно там и не требуется, это ж не БД. В данном случае это типичная файлопомойка - .doc/x .xls/x .dwg .dxf - и тому подобное, раскиданное по папочкам.

[АртемЪ]

Константин Антонов, Ну фрагментация будет в любом случае.
Если у вас не сильно нагруженная файлопомойка - отлично.
А если там сотни пользователей одновременно тягают кучу файлов и диски еле справляются - могут быть проблемы с быстродействием.
Опыт нормальной работы дедуплицированной файловой шары с включенным VSS есть, проблем не наблюдаю.

[АртемЪ]

Дедупликация не дружит с шифрованием, и с многоярусным томами.

[Ziptar]

АртемЪ,

Если у вас не сильно нагруженная файлопомойка - отлично.

Именно так.

А если там сотни пользователей одновременно тягают кучу файлов и диски еле справляются - могут быть проблемы с быстродействием.

Мне кажется были бы у меня сотни пользователей - то я бы уже был обязан знать про взаимодействие дедупликации и vss =)

[АртемЪ]

Очень неплохо работают виртуальные машины - но есть тонкости.
Если речь про постоянно работающую и сильнонагруженную ВМ, то удовольствия мало.
А вот когда есть пара десятков однотипных VM, которые преимущественно выключены, и запускаются нечасто - существенно экономится дисковое пространство, в результате вся пачка умещается на небольшом SSD.

[АртемЪ]

Мне кажется были бы у меня сотни пользователей - то я бы уже был обязан знать про взаимодействие дедупликации и vss =)

Ха, нередко такие сети админят люди не знающие таких страшных слов как VSS.