-
- Influencer
- Posts: 13
- Liked: 4 times
- Joined: Jul 13, 2010 12:14 am
- Full Name: Justin Grote
- Contact:
Resizing VMDKs requires resync?
Greetings,
I've noticed that if I resize a VMDK, the next time a backup or replica job runs, it has to transfer the entire VM all over again. Why is this? Is this something that is being actively addressed? Is there a workaround like temporarily turning off CBT so that Veeam does the comparison work?
This gives me pause because I have a customer with a particular file server that is very low change rate but high capacity, and they prefer to expand the disk often without downtime instead of reserving a ton of space ahead of time. Unfortunately their WAN link is kind of anemic so the initial sync had to be done out-of-band, and I worry that a VMDK resize would trigger all the data being resent on the next backup or replica job.
I've noticed that if I resize a VMDK, the next time a backup or replica job runs, it has to transfer the entire VM all over again. Why is this? Is this something that is being actively addressed? Is there a workaround like temporarily turning off CBT so that Veeam does the comparison work?
This gives me pause because I have a customer with a particular file server that is very low change rate but high capacity, and they prefer to expand the disk often without downtime instead of reserving a ton of space ahead of time. Unfortunately their WAN link is kind of anemic so the initial sync had to be done out-of-band, and I worry that a VMDK resize would trigger all the data being resent on the next backup or replica job.
-
- VP, Product Management
- Posts: 27377
- Liked: 2800 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Resizing VMDKs requires resync?
Hello Justin,
This behavior is documented in the Release Notes under Backup and Replication section. Moreover, as far as I know disk re-sizing would invalidate the changed blocks, meaning that the full run will be required anyway.
Not sure that turning off CBT would help either.
Could you please elaborate why your customer doesn't want to use thin disks?
Thanks.
This behavior is documented in the Release Notes under Backup and Replication section. Moreover, as far as I know disk re-sizing would invalidate the changed blocks, meaning that the full run will be required anyway.
Not sure that turning off CBT would help either.
Could you please elaborate why your customer doesn't want to use thin disks?
Thanks.
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Resizing VMDKs requires resync?
Why would not they use thin-provisioned VMDK for this file server? This exactly how thin-provisioning works... but in automated fashion (not a manual process), and without affecting our product. Thanks!jgrote wrote:This gives me pause because I have a customer with a particular file server that is very low change rate but high capacity, and they prefer to expand the disk often without downtime instead of reserving a ton of space ahead of time.
-
- VP, Product Management
- Posts: 6035
- Liked: 2860 times
- Joined: Jun 05, 2009 12:57 pm
- Full Name: Tom Sightler
- Contact:
Re: Resizing VMDKs requires resync?
Many companies refuse to use thin provisioning because of the potential management headaches that it causes. Thin provisioning is a cool feature, but it appears to be designed largely to sell more disks (exactly the opposite of what they describe). Instead of intelligently allocating space as required, admins now just allocate huge thin provisioned space because "we might need it one day". Of course, they just automatically assured that "one day" will be much sooner than expected since everyone knows the storage versions of Parkinson's Law, "Data expands to fill the space available for storage".
Storage execs seem to understand this better than storage customers. Of course, if your a large customer that adds storage every few weeks, well thin provisioning might be for you, since you're always growing your storage anyway, however, for those of us who are a little smaller, and by big storage only every few years, thin provisioning is a curse that means making emergency budget requests for more storage (exactly what the storage vendors want) because you "thin provisioned" what should have been 3 years worth of capacity, only to find it used in 90 days because "it was there".
Storage execs seem to understand this better than storage customers. Of course, if your a large customer that adds storage every few weeks, well thin provisioning might be for you, since you're always growing your storage anyway, however, for those of us who are a little smaller, and by big storage only every few years, thin provisioning is a curse that means making emergency budget requests for more storage (exactly what the storage vendors want) because you "thin provisioned" what should have been 3 years worth of capacity, only to find it used in 90 days because "it was there".
-
- Chief Product Officer
- Posts: 31814
- Liked: 7302 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: Resizing VMDKs requires resync?
This made me smiletsightler wrote:"Data expands to fill the space available for storage".
Who is online
Users browsing this forum: Baidu [Spider], Majestic-12 [Bot], Semrush [Bot] and 76 guests