VEB windows 2012 dedup optimized ?

[Hariseldon1]

Greetings!

Here is a scenario:
-- A machine running server 2012 r2 already has a volume drive letter "Z:\"
-- On said server, the volume drive letter "Z:\" is 930 GB in size
-- On said server, the volume drive letter "Z:\" is already regularly deduplicated/scrubbed/garbagecleaned according MS recommendations
-- On said server, the volume drive letter "Z:\" (930 GB physical) holds a reyhdrated storage usage of 1.9 TB
-- On said server, the volume drive letter "Z:\" (930 GB physical) dedup optimized has saved space of 617 GB... free space of 244 GB

According to MS:
-- A backup that is NOT "server 2012 dedupe optimized" will require a full rehydration of chunkstore and 1.9 TB of space on destination.
-- A backup that IS "server 2012 dedupe optimized" will NOT require a full rehydration of chunkstore and ONLY require 762 GB of space on destination.

My Question:
-- If VEB is used to backup the volume in scenario above (where said volume is already "server 2012 deduped")
-- Will VEB require full rehydration or will VEB recognize the existing data deduplication?

VEB does a fabulous job already, although I didn't read anywhere if it is "server 2012 dedup optimized". Granted VEB will not likely require 1:1 destination storage the way wbadmin does, this makes it hard for me to ascertain if VEB is/not "server 2012 dedup optimize".

(FYI I am *not* asking if VEB backup files will dedupe -they do, nicely- I *am* asking if VEB backup technology will recognize the existing server 2012 deduped volume in it's existing optimized state.)

Thank you!

P.S.: Intellectually curious, a follow up question: If VEB is "2012 dedup optimized" does this change anything in VEB approach to incremental methodology? Perhaps it is merely incremental backups of changes to the chunkstore + files.

[Dima P.]

Hi Hari,

I do remember that we had several issues while backing up the deduplicated volumes. Need some time to check this with QA team, so stay tuned – I’ll update this thread.

[Anguel]

Hari,

You will probably face the deduplication problem with FOREVER forward incrementals in VEB as described in my feature request here:
veeam-endpoint-backup-f33/feature-reque ... 33017.html

[Hariseldon1]

Dima: Thanks, I an looking forward for the official Veeam software answer.... in the mean time... is it at least ~_safe_~ to rely upon VEB to perform Volume Level backups of deduplicated volumes? (safe = reliable for restore in worse case scenario)

I have resources to test lots of things in my private professional development lab, unfortunately I cannot always perform a full-restore-and-verify test of worse case scenario of everything. Of course, I always budget for this 'verification' in production environments. (I only take calculated liberties in my safe-to-start-over development lab environment due to resource limitations.)

Anguel: Thanks, I will read your thread.

Thank you everyone!

[Anguel]

Hari: Sorry, I did not realize you are backing up a deduped volume, my thread is about backing up TO a dedupe volume.

[Dima P.]

Hi Hari,

Sorry for the delay. Yes, we can call a volume level backup dedup optimized since rehydration is not required. Some things to keep in mind while performing a recovery:

- To restore the deduplicated volume you must have an identical deduplication driver in the OS, to properly handle the restore of the deduplicated blocks (both for volume level recovery and Bare Metal Restore)
- For Entire PC Bare Metal Recovery you should already have the needed driver, so it should work without any issues

The only place where you may face problems is file level backup: the backup storage is allocated based on the size of the deduplicated volume, while files are backed up in raw size (non deduplicated) and as a result you may face backup job failures.

[Hariseldon1]

Hi Dima,

Thanks for replying! Good to know VEB is "2012 Dedup Optimized". Some thoughts about potential for human error regarding using VEB and the important points you mentioned:
-- "must have an identical deduplication driver in the OS" Would it be possible to offload the responsibility of backing-up and restoring this driver automatically within VEB?
-- ergo: any "2012 dedup optimized" backups that VEB takes... we can trust-in-veeam that VEB has handled its own requirements to restore said backup jobs
-- Would it be possible, in "configure backup" wizard, that VEB could acknowledge the source-to-be-backed-up is "deduplicated volume".... and give the end user the choice to do a "dedup optimized backup" or "rehydrated backup"?

Admittedly: (imho) as long as VEB automatically handles it's backup/restore requirements needed to take advantage of "2012 dedup optimized" backup....... I think I would always opt for a "optimized backup" due to the increased time/storage requirements of a "rehydrated backup". So I cannot envision why someone might elect to perform a non-optimized backup.

The only reason **I** might elect to perform a non-optimized backup: if there are potential gotchas preventing access to optimized data in older backups. (along the lines you mentioned)

WRT file-level-backup: I have always had problems (even with VSS) performing file-level-backups. As a result of my experiences, I have almost totally moved towards "volume only" oriented thinking:
-- Easy to create small volumes [except windows runs out of drive letters fast]
-- Easy to expand volumes on fly
-- VSS volume snapshots required to guarantee access to files in use, why not incremental backup snapshot anyways

Thanks!