Maintaining backups whilst in DR

[joespirit88]

Hi,

I have had a browsed around the forums and can't seem to find anything related.

For this scenario we have the below setup


Site One(Prod)
1 x Standalone Hyper-V
1 x VM
1 x Veeam Repository(Primary)

Site Two(DR)
1 x Standalone Hyper-V
1 x Veeam Repository(Secondary)

The VM is replicated using native Hyper replication to the DR Hyper-V Host.
It is backed up using Veeam each night to the Primary repository.
A backup copy job is then used to send the backup to the Secondary

If we were to lose our Primary Site we would bring the VM up from its replica on the DR side, or failing that restore it from our backup copy.

How would we then perform a backup against the VM in the DR Site without having to reseed?

From what I can tell you can't re map the backup job to use the backup copy files even though they contain the same VM data?

If you scale up the above scenario it could take a while to reseed all that data leaving you in an extended DR event with no new backups.

[HannesK]

Hello,

From what I can tell you can't re map the backup job to use the backup copy files even though they contain the same VM data?

well, the failed over VM is not the same VM

How would we then perform a backup against the VM in the DR Site without having to reseed?

I'm not sure whether I understand what you try to do. If the primary site fails, you need to create a new backup job on the DR site because there is no primary site at that time (the backup server is running on the DR site?)

Best regards,
Hannes

[ejenner]

The way around that problem would be to eliminate the backup-copy aspect of it. Define a new job on the Backup and Replication console for the secondary DR VM. So you run two separate backups.

Assuming the backup and replication server will be unavailable in the DR scenario you would have to make sure you have the ability to stand up a Backup and Replication server at your DR site which means you should be doing a regular configuration backup to your DR site in case you have to restore the B&R server.

[joespirit88]

Hannes,

well, the failed over VM is not the same VM

As a replica, it is an exact copy of the production VM though? If the Backup copy job is good enough to restore the entire VM from it should also be good enough to be a seed for the data if we have to set up the backups again?

In A DR Situation we would have to ensure we have enough overhead storage to backup the entire environment as well as maintain our GFS backup copies.

ejenner,

Eliminating the backup copy aspect is the only solution we can see currently too but this also has it's drawbacks. If we backup the replicas we lose application aware backups as the VM's are turned off at the DR site during normal running. Backing up from the primary site hosts to the DR repo has bandwidth implications hence the benefits of using the backup copy function.

Maybe a potential for a feature request?
The data is all there in the form of a the backup copy files, why not be able to perform incrementals to the backup copy files in case of DR running?

[HannesK]

Hello,

As a replica, it is an exact copy of the production VM though?

in the first place it looks like that. At least the UUID should be different (we don't use names as identifier because a user could rename VMs in an "unexpected" way) be we also don't have internals on the Hyper-V replication.

The next thing is, that you cannot map a backup copy job to a backup. A similar question came up some time ago

Best regards,
Hannes

[joespirit88]

After some more thought we think we may have found a better solution.

Instead of using the Backup copy function we will use the File Copy function or Robocopy to replicate our primary repository to additional storage on the secondary site.

In the event of running in DR all we would have to do is map the backup job to the file copies on the secondary site and backups should continue to run as normal. We can also reverse the file copy process back to the production site and remap it back once the production site is back up to full capacity.

Do you foresee any issues with doing it this way?

Thanks

[foggy]

This will work to the same extent as with backup copy jobs, due to the fact Hanness has mentioned - replica VMs have different IDs and will be backed up in full during the first job run after mapping.