Title says it all
Got a customer who advises they are running Windows dedupe on the local OS, and I can see the backup copy job is getting really poor compression on the VM. Anyone else have customers doing this and seeing similar results?
Example
Source VM data size = 868 GB
Source VM VBK file = 863 GB
-
- Veeam Vanguard
- Posts: 629
- Liked: 251 times
- Joined: Sep 27, 2011 12:17 pm
- Full Name: Craig Dalrymple
- Location: Scotland
- Contact:
-
- Veeam Software
- Posts: 2363
- Liked: 558 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Does Windows Data Deduplication role on the source VM, impact Veeam compression?
Hi Craig,
Yes, this can impact the backup file size, but it's not directly because dedup/compression is affected, but instead because Windows Dedup will make a lot of "changes" from the hypervisor perspective, meaning more blocks returned by CBT, which means bigger backups, even though the actual data on the GuestOS has not changed much at all.
Windows Dedupe uses the Chunkstore to store reference blocks, and the Optimization Job for Windows Dedup periodically scans files on the dedup volume and moves blocks to the chunkstore and/or updates blocks on the original files to a reparse point that points to the unique block: https://learn.microsoft.com/en-us/windo ... dedup-work
From the GuestOS perspective, nothing has changed and your users are none-the-wiser. CBT however sees this as tons of changes, even if it's only a single byte changing, and as a result you get big incrementals because there is so much CBT data and the blocks are truly "unique" from the hypervisor perspective, despite the actual files not really changing their contents.
Usually it's best to handle the space savings at a "higher" level than the GuestOS, but there's nothing inherently wrong with it, just it will not place as nicely with backups and CBT.
Yes, this can impact the backup file size, but it's not directly because dedup/compression is affected, but instead because Windows Dedup will make a lot of "changes" from the hypervisor perspective, meaning more blocks returned by CBT, which means bigger backups, even though the actual data on the GuestOS has not changed much at all.
Windows Dedupe uses the Chunkstore to store reference blocks, and the Optimization Job for Windows Dedup periodically scans files on the dedup volume and moves blocks to the chunkstore and/or updates blocks on the original files to a reparse point that points to the unique block: https://learn.microsoft.com/en-us/windo ... dedup-work
From the GuestOS perspective, nothing has changed and your users are none-the-wiser. CBT however sees this as tons of changes, even if it's only a single byte changing, and as a result you get big incrementals because there is so much CBT data and the blocks are truly "unique" from the hypervisor perspective, despite the actual files not really changing their contents.
Usually it's best to handle the space savings at a "higher" level than the GuestOS, but there's nothing inherently wrong with it, just it will not place as nicely with backups and CBT.
David Domask | Product Management: Principal Analyst
Who is online
Users browsing this forum: Ahrefs [Bot], Baidu [Spider], Bing [Bot], dasfliege and 105 guests