Comprehensive data protection for all workloads
- SVP, Product Management
- Posts: 24092
- Liked: 3278 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
danieln wrote:Nevertheless, I see no explanation why the digests does nothing other than wasting time. To be honest I do not know what digests is.
Oh, I did not realize you don't know what the digest calculation process is. Digest is essentially table with hashes of all virtual disk blocks. To create this, the proxy need to read the whole disk. Digest is then sent over to the source site to compare replica VM disks with the source VM disks, and make sure the seeded VM disks are exactly identical and not corrupted. As soon as replica disks are validated, CBT kicks in and the following runs are incremental only.
danieln wrote:Hot add has caused me a few times to have vmdks and snapshots left opened and locked and growing. Quite a headache it has been a few rare occasions requiring me to reboot ESX servers as I could not find a way to unlock the files. I know there is a howto in this forum about this but I couldn't find a way to identify what process was locking the files.
This was in early days of hot add, currently we have the code in place that prevents this from happening. Anyway, using hot add would definitely speed up the data retrieval, and thus all the operations including digests calculation.
- Posts: 12
- Liked: never
- Joined: Aug 10, 2011 3:19 pm
- Full Name: Daniel Negru
I've done the test: re-seeding the a small machine. Well: it helps. Unfortunately my disk speeds keeps it still slow.
Anyways: re-seeding the same small machine results in same speeds over LAN or over WAN if changes are close to 0.
I have a question though: is there any particular reason on re-seeding, the hashes on local and remote are not run in parallel.
As I see it now:
- remote proxy reads remote seed (entirely), compute the hash = quite some time
- after this, local proxy reads source (entirely) and computes the hash = quite some time.
- hashes are probably compared somewhere after by either source proxy or veeam server and therefore only changed block are sent over WAN = tiny amounts, depending on changes.
Wondering why the step 1 and 2 does not go in parallel. In my case, large machines, would take 4 hours + 4 hours + peanuts. It could take 4 hours + peanuts. Maybe in SP1 this parallel processing can be implemented. So far the replication seems to be a linear path: Step 1 to 2 to 3 ... and therefore it wastes time.
Other than that: replica seems way faster than in V5: exchange use to take 7 hours +. Now is done in 3 hours.
All the best. Daniel.