More background info about replication mode

[rowdy]

Hello all,

I have several installations (also at customer location) of VMWare B&R now and everything and everything is working fine with the occasional glitch of course

So, now is the first time I'm going to use the replication feature.
I have setup a replication job and it seems to be working okay, but I would like some more background info on all the files that are created.

More specifcally, I was wondering the following:
I have server A and B, and a seperate backupserver running Veeam. I have a job that replicates a VM from A to B every hour and maintains 48 rollback-points (so 2 days).
On server B, I have the following files in the target folder (besides the NVRAM, VMX, VMXF and LOG files):

• Two VBK files, one is 0,43 KB the other is 56.832 KB (and has a -s001 at the end of the filename).
• A whole lot of VRB files, in pairs, one 0,43 KB and the other (with -s001) have sizes of around 130.000 KB
• A VMDK file, the actual disk, size is 157.286.400 KB
• Another VMDK with the suffix _working, size is the same: 157.286.400 KB

Question 1: What are all these files? I know what they are in case of a backup, but not in case of replication. What is the difference between the VMDK and the VMDK_Working? Are they updated after every replica run? Why is there a VBK file? What is the relation between both VMDK, the VBK and the VRB?
Question 2: If a replication session is in progress and the source server fails completely at that time, which files would have Veeam have had open at that time, and would the backups (replica's actually) be in a consistent state, ready to be powered on?

A lot of questions but since this is very critical (we're using replication on a very critical VM obviously) I really want to understand everything there is to it before I actually need this knowledge

Thanks,
Rowdy

[Vitaliy S.]

Question 1: What are all these files? I know what they are in case of a backup, but not in case of replication. What is the difference between the VMDK and the VMDK_Working? Are they updated after every replica run? Why is there a VBK file? What is the relation between both VMDK, the VBK and the VRB?

To know the details about *working.vmdk, please check out this thread: Replication question

For the relationship info between VMDK, VBK and VRB please look through this existing topic: Archiving Replicas

Question 2: If a replication session is in progress and the source server fails completely at that time, which files would have Veeam have had open at that time, and would the backups (replica's actually) be in a consistent state, ready to be powered on?

Here is another existing discussion that should answer your question: What happens if a DR event occurs mid-replication?

Hope this helps!

[rowdy]

Thanks for all the info.
I have read everything multiple times and if I understand correctly:

-------What is what-----------------------
VBK= just a big index of what is what
Both VMDK = essentially the same, just pointers to the real file. The VMDK always contains the most current situation.
VRB = used to roll back in time

-------Continue if source server fails while replication is not in progress-----------------------
If the source server fails and replication is not in progress, I could just hit 'play' in ViClient to power on the replica. This is not the recommended way perhaps, but technically it would work and I would be online pretty quick.
I would not really need any VBK or VRB file in this case.
(Recommended way is to install Veeam in the target environment and restore the DB. Then use Veeam to perform failover - only required of course if the entire source site explodes - if it's just one server you need to fail-over, you'll still have your normale Veeam install online of course)

------Continue if source server fails while replication IS in progress----------------------
If the source server explodes during replication, the VMDK file on the target site is damaged.
Two things can be done then:
1. If the source server un-explodes and Veeam runs again, the VMDK will be repaired (reality: the WAN link just went down and came back up later)
2. If the source server is really dead, you cannot just power-on the target replica with ViClient because of the damaged VMDK. So, there are 2 ways to fix this:
I) If the original Veeam server is still working normally, just use replica failover, select an older restore point and let it do it's magic. It will repair the damaged VMDK to an earlier point in time with the info in the VRB file.
II) If the entire source site is destroyed, you need to re-install VeeAm on the backup-site. Then, you need to import the VeeAm Database in order to be able to perform the failover. If the database is too old, it cannot be used. If you don't have the database at all, there is no way ever to use the damaged VMDK, VRB and VBK's to build something working ever again.

So, it is recommended to use DB replication or have Veeam on the backup-site. If that is not possible, it is recommend to also use Veeam to make normal backups as well.




Did I get it right?
If so, then a big feature request obviously would be to make Veeam able to recover from such a damaged replica without the need for it's database. When using continuous replication, the chance is 99% the source server fails when a replica-session is in progress.
Perhaps some more info can be stored in the VBK to make this possible.
In other words: if I have the damaged VMDK (damage occured because of failed last replica-session), the VRB and VBK (and also VMX etc.), make this somehow importable into Veeam.

Thanks,
Rowdy

[Vitaliy S.]

(Recommended way is to install Veeam in the target environment and restore the DB. Then use Veeam to perform failover - only required of course if the entire source site explodes - if it's just one server you need to fail-over, you'll still have your normale Veeam install online of course)

Small correction to this procedure - no need to use Veeam if you want just to failover to DR VM in case of a disaster. SQL database is only required when you want to use any older restore point.

If so, then a big feature request obviously would be to make Veeam able to recover from such a damaged replica without the need for it's database. When using continuous replication, the chance is 99% the source server fails when a replica-session is in progress.

Already in v6 Some replication functionality changes we are going to introduce will make such replica import functionality unneeded.

[Gostev]

Yep, the new replica format in v6 allows exactly for this - recovering damaged replicas, and even failing over to any restore point, without the need of database. Thanks.

[rowdy]

Thanks for your help and clarification.

I now have all the information I need in case of a disaster. And I'm looking forward to version 6 then, because the less dependent on a (external) database a program is, the better. Especially when it's backup software and the clock is ticking when you need to restore.