We backup all of our VMs each night to an on campus ReFS repository. This repository sits on a Nimble hybrid array and is presented to our physical proxy server as a drive mapping. Our physical proxy server is brand new, plenty of CPU horsepower and RAM. Once a week we do a synthetic full and this past Saturday this fast clone operation took 21 minutes.
We run a second backup job that also backs up all of our VMs to an offsite Exagrid box. Once a week we run a synthetic full on the Exagrid. Since we use the Exagrid data mover service, my understanding is the synthetic full happens on the Exagrid, no data is moved across our WAN connection. This synthetic full took 9.5 hours
Why such a big difference in how long it takes for a synthetic full, 21 minutes versus 9.5 hours? I realize this is a bit of an apple and orange comparison but I am trying to understand how there can be this big a difference
-
- Expert
- Posts: 158
- Liked: 8 times
- Joined: Jul 23, 2011 12:35 am
-
- Veeam Legend
- Posts: 1203
- Liked: 417 times
- Joined: Dec 17, 2015 7:17 am
- Contact:
Re: Exagrid vs ReFS synthetic full, huge difference in time
REFS does not really move any data it just points references to the data blocks in the filesystem - thats the genius thing about REFS (if it works )!
https://www.veeam.com/blog/advanced-ref ... suite.html
https://www.veeam.com/blog/advanced-ref ... suite.html
-
- Technology Partner
- Posts: 126
- Liked: 18 times
- Joined: Feb 28, 2011 5:20 pm
- Full Name: Chris Snell
- Contact:
Re: Exagrid vs ReFS synthetic full, huge difference in time
As mkretzer points out - ReFS isn't really doing any real work in terms of moving the data around to create a synthetic image.
From an ExaGrid point of view, the process should be remarkably quicker than if you are carrying out the task on normal disk - as stated, it all occurs on the appliance and avoids using the network and proxy. This is on the understanding that the ExaGrid landing zone is large enough to store the previous full image and provide space to synthesize the new full image. Normally ExaGrid units are sized to keep one week's worth of backups (so a full and a bunch of incrementals), and may not be large enough to carry out the work as well. In this case, the data will be read from the deduped space, and this would be slower than reading it from the landing zone. I'd suggest talking to the support rep aligned to your account to see if there's enough space to carry out synthetic jobs, they can resize the landing zone to help.
From an ExaGrid point of view, the process should be remarkably quicker than if you are carrying out the task on normal disk - as stated, it all occurs on the appliance and avoids using the network and proxy. This is on the understanding that the ExaGrid landing zone is large enough to store the previous full image and provide space to synthesize the new full image. Normally ExaGrid units are sized to keep one week's worth of backups (so a full and a bunch of incrementals), and may not be large enough to carry out the work as well. In this case, the data will be read from the deduped space, and this would be slower than reading it from the landing zone. I'd suggest talking to the support rep aligned to your account to see if there's enough space to carry out synthetic jobs, they can resize the landing zone to help.
Who is online
Users browsing this forum: Bing [Bot], Semrush [Bot] and 106 guests