Entire VM restore for virtual server with Windows Data Deduplication enabled on the it's drive feel a bit slower than other virtual server restore without OS Data Dedup.
Does enabling Windows Data Deduplication on server being backed up affect Veeam backup/restore operation?
I know guest file restore operation for this option will require Veeam Mount Server with Data Deduplication as well, but cant recall limitation on the Entire VM restore process.
-
- Influencer
- Posts: 16
- Liked: 3 times
- Joined: Oct 02, 2023 3:34 am
- Full Name: Nas
- Contact:
-
- Veeam Software
- Posts: 2110
- Liked: 509 times
- Joined: Jun 28, 2016 12:12 pm
- Contact:
Re: Entire VM restore for virtual server with Windows Data Deduplication enabled
Hi Nas,
The contents of the disks should not be a major factor beyond just how much data there is. While perhaps there is some difference on low level write operations I'm just not familiar enough with to comment on, at first blush I have trouble imagining that this would cause a significant increase.
Can you share a few more details on what you were observing?
1. How big is the VM with WinDedup enabled? And how big is the VM without WinDedup you're using for comparison?
2. What was the total processing time and reported transfer speed for both VMs?
3. You did entire VM restore or a different restore operation? Was Quick Rollback used?
The main difference I can think of where WinDedup may come into play is the total data being backed up/restored. With Windows Deduplication, you end up with high amounts of CBT data as even though the files on the volume are not changing in terms of content, the way Windows Deduplication works will result in tons of small changes which CBT will return as changed blocks.
So a Windows Dedup server will have more changed blocks in the backup by nature of how Windows Deduplication works, and this might be what you're observing -- bigger backup = more time to restore.
The contents of the disks should not be a major factor beyond just how much data there is. While perhaps there is some difference on low level write operations I'm just not familiar enough with to comment on, at first blush I have trouble imagining that this would cause a significant increase.
Can you share a few more details on what you were observing?
1. How big is the VM with WinDedup enabled? And how big is the VM without WinDedup you're using for comparison?
2. What was the total processing time and reported transfer speed for both VMs?
3. You did entire VM restore or a different restore operation? Was Quick Rollback used?
The main difference I can think of where WinDedup may come into play is the total data being backed up/restored. With Windows Deduplication, you end up with high amounts of CBT data as even though the files on the volume are not changing in terms of content, the way Windows Deduplication works will result in tons of small changes which CBT will return as changed blocks.
So a Windows Dedup server will have more changed blocks in the backup by nature of how Windows Deduplication works, and this might be what you're observing -- bigger backup = more time to restore.
David Domask | Product Management: Principal Analyst
-
- VP, Product Management
- Posts: 7057
- Liked: 1502 times
- Joined: May 04, 2011 8:36 am
- Full Name: Andreas Neufert
- Location: Germany
- Contact:
Re: Entire VM restore for virtual server with Windows Data Deduplication enabled
Major difference is the compression factor.
Normally you read like 100% of the data and have to transport and store only 50% of it on the backup target because of the compression.
Already deduplicated data end up in unique data blocks and our compression is limited, which means much more data (nearly 90-100%) need to be transported over the network and the backup target has to write it as well (on view of the backup target it is 2x more data because of the already deduplicated data).
Now depending on where the bottleneck is in your environment, a restore can take longer.
Normally you read like 100% of the data and have to transport and store only 50% of it on the backup target because of the compression.
Already deduplicated data end up in unique data blocks and our compression is limited, which means much more data (nearly 90-100%) need to be transported over the network and the backup target has to write it as well (on view of the backup target it is 2x more data because of the already deduplicated data).
Now depending on where the bottleneck is in your environment, a restore can take longer.
Who is online
Users browsing this forum: Baidu [Spider], sleti and 2 guests