"active full backup" option for replication

[Guido]

Why doesn't have replication jobs some sort of an option like "Active full backup"? To do a one to one replication of the complete VM like you do in the first replication job.

[Vitaliy S.]

Hi Guido,

Could you please tell me where would you place this new VM image? Since full run produces the same set of VM files (vmx, virtual disks etc.), you will need to remove exiting VM replica which will leave you without a backup for quite some time.

I bet this is not what you're looking for, right?

Thanks!

[J1mbo]

Instead of what is effectively forever incremental, presumably. To be fair this has crossed my mind too. If there were some error in the CBT system it could remain hidden (until it's needed, no doubt).

[Guido]

Hi J1mbo,
You discribed my concern better than I did.

[tsightler]

I don't think you'd have to send all the data again, basically just perform the equivalent of "mapping a backup", i.e. scan the target to recalculate the hashes, and scan the source completely rather than use CBT, sending only blocks where the hashes don't match. Sort of a "verify" for replicas.

[Gostev]

That's exactly where I was heading to with my question that I posted here earlier, but then decided to delete to let you speak your real need first. I said that while active full is quite pointless functionality (because it will take a few days over WAN, plus what Vitaly said) - replica "health check" might be useful on the other hand. And just as Tom noted, we already have the code that does exactly that during replica seeding, mapping and failback anyway

[J1mbo]

So is this feature already implemented?

[tsightler]

The code is there, effectively that's what replica mapping does. Basically we'd just need a GUI function that triggered the same behavior as replica mapping.

[J1mbo]

IMHO it would be a good feature to have and something that could be scheduled for example once a week or whatever. By hashing up blocks of hashes of blocks or just using large hash blocks, WAN bandwidth requirements could be pretty minimal even for large VMs (at the expense of broadly sequential IO at both ends, of course).