Server 2012 Dedupe and iSCSI Volumes
-
After attending Rick Vanover's session on Server 2012 deduplication at Spiceworld, I am excited to give it a try on my Veeam backup repository. But I need to make sure I have this straight in my head before running down that path.
I am running my Veeam backups to a Drobo B800i SAN each night and have 3 LUNs on the Drobo attached to the Veeam server (VM running on my ESXi box). The Drobo connects directly to the Veeam server via iSCSI Initiator, so these LUNs on the Drobo are not VMWare datastores like they might be if the storage were first connected to a VMWare host and then presented to a VM. Is the way the Drobo presents the storage to the VM the equivalent of a raw device mapping?
So, if I activate deduplication on these three volumes containing Veeam backups, will it work as expected to decrease storage usage and allow more backups to be saved to disk (the Drobo) since these are NTFS volumes? If so, what kind of system resource hit do you think that VM will end up taking to run deduplication jobs if I am keeping about 30 days of backups on the Drobo (forward incrementals with synthetic fulls on weekends)?
Furthermore, if you do have a deduplicated volume, what happens when you copy files on it to a volume somewhere else that is not deduplicated? The Veeam backup files on these volumes get copied to an external hard drive that goes offsite each day.
Thanks in advance.
-
@NetworkNerd said:
After attending Rick Vanover's session on Server 2012 deduplication at Spiceworld, I am excited to give it a try on my Veeam backup repository. But I need to make sure I have this straight in my head before running down that path.
...
Furthermore, if you do have a deduplicated volume, what happens when you copy files on it to a volume somewhere else that is not deduplicated? The Veeam backup files on these volumes get copied to an external hard drive that goes offsite each day.From what he has saying in the session if you copy off the deduped drive you are going to take a resource hit as it is being re-saturated (That isn't the right term but that is what I picture in my mind when the data goes through this process).
The recommendation at the breakout session, and from some dedupe vendors was to use that feature on the final resting place for these backed-up or archived files.
Although depending on the amount of data you have and the deduplication ratio the resource hit may not be that much.
-
I was just reading the following article: http://blogs.technet.com/b/filecab/archive/2012/05/21/introduction-to-data-deduplication-in-windows-server-2012.aspx.
This point in particular stood out to me:
Portability: A volume that is under deduplication control is an atomic unit. You can back up the volume and restore it to another server. You can rip it out of one Windows 2012 server and move it to another. Everything that is required to access your data is located on the drive. All of the deduplication settings are maintained on the volume and will be picked up by the deduplication filter when the volume is mounted. The only thing that is not retained on the volume are the schedule settings that are part of the task-scheduler engine. If you move the volume to a server that is not running the Data Deduplication feature, you will only be able to access the files that have not been deduplicated. -
A LUN is a "disk." What Windows sees is literally just another drive sitting out there like any normal hard drive.
-
I was just reading the following article: http://blogs.technet.com/b/filecab/archive/2012/05/21/introduction-to-data-deduplication-in-windows-server-2012.aspx.
This point in particular stood out to me:
Portability: A volume that is under deduplication control is an atomic unit. You can back up the volume and restore it to another server. You can rip it out of one Windows 2012 server and move it to another. Everything that is required to access your data is located on the drive. All of the deduplication settings are maintained on the volume and will be picked up by the deduplication filter when the volume is mounted. The only thing that is not retained on the volume are the schedule settings that are part of the task-scheduler engine. If you move the volume to a server that is not running the Data Deduplication feature, you will only be able to access the files that have not been deduplicated. -
Yes, of course. Deduplication is at the filesystem layer. If you move a file system to a different machine that can't read that filesystem, it can't read it. This is an inherent property of dedupe and has nothing to do with Windows.
-
The limitations of dedupe in portability are no different than encryption or compression.
-
What about block-level deduplication? I guess that doesn't apply to the Windows model.
-
@art_of_shred said:
What about block-level deduplication? I guess that doesn't apply to the Windows model.
Normally you just do one or the other.
-
one or the other what?
-
-
@Dashrender said:
@art_of_shred said:
one or the other what?
Block Level or File level, not both.
Exactly
-
@art_of_shred said:
What about block-level deduplication? I guess that doesn't apply to the Windows model.
The block level data is on a Drobo, so that is not an option in this case. If it were NetApp or something like that, it might be a different story.
