DR Testing / SureBackup vs. Replication Failovers....

[jlockie]

I searched around and did not see this directly answered.

I am curious about traditional backups vs. replications vs. surebackup jobs for DR testing.

Everything is vSphere. I have replication jobs running across WAN to storage on target backup repository (with a proxy in DR site). I also have ran backup jobs to target repository (as a testing of backup jobs vs. replication job times). I am able to restore VMs from both backup jobs and replication jobs.

Restoring replication copy is much faster than restoring from backup. Therefore, I would like to use replication jobs to backup to DR and then use traditional backup jobs to backup locally.

That leaves me with the question of the best way to test DR plan? When I restore from a replication job, it actually shuts down the production server, and I haven't found a way to prevent this yet. That is no big deal so far, but when we do full blown DR testing I need to recover the VMs in DR.

I do not necessarily need SureBackup / vLab to do this, since our DR site is segmented and I can always re-IP with replication jobs....

Any advice here, before I get deeper into the design?

I am currently watching this video: https://www.youtube.com/watch?v=jXevvMMQHkA

I have experience with Veeam since about 2013, so the core concepts are somewhat there (when I first deployed years ago I read every page of the admin guides). We did not use Veeam for DR, but only for localized backups. We used storage replication for DR and then use SRM. Now, I am trying to move away from SRM and leverage Veeam....hope that makes sense!

[jmmarton]

I know you say you don't need SureBackup, but why not go ahead and leverage SureBackup/SureReplica? That would probably make your testing easier for now. And coming later this year, Veeam Availability Orchestrator could further help you test your DR plan.

https://go.veeam.com/orchestration

Joe

[Vitaliy S.]

When I restore from a replication job, it actually shuts down the production server, and I haven't found a way to prevent this yet. That is no big deal so far, but when we do full blown DR testing I need to recover the VMs in DR.

Do you use VM failover options or something else to test your replicas?

Generally, we recommend to have two backup servers, one is doing backups (located in the production site) and the second server is managing replication jobs (located in the DR site). In this case you're fully protected from losing your production site and production backup server.

The DR design heavily depends on the RPO/RTO requirements and available resources in both sites.

[jlockie]

Generally, we recommend to have two backup servers, one is doing backups (located in the production site) and the second server is managing replication jobs (located in the DR site). In this case you're fully protected from losing your production site and production backup server.

I thought of this yesterday.....because the replica "recovery" would have to be done from DR and would require a backup server in DR, duh. Obviously, not so much for testing, but for real world failover I'd be building a new backup server in order to recovery replicas. So this makes total sense....and I will work on this ASAP.

[jlockie]

I know you say you don't need SureBackup, but why not go ahead and leverage SureBackup/SureReplica? That would probably make your testing easier for now. And coming later this year, Veeam Availability Orchestrator could further help you test your DR plan.

https://go.veeam.com/orchestration

Joe

Thx Joe, this is where I am leaning after doing more reading/research yesterday.

Basically, at this point I plan to manage the replica jobs from a backup server in DR. While backup server in prod will manage traditional backup jobs. I will then run surebackup to test DR recovery of replicas! This should work nicely.

[Vitaliy S.]

Just one more tip before you go ahead with your plan - when you start building a DR backup server and setting replication jobs, make sure they do not overlap with backup jobs running on the production backup server. Thanks!

[lando_uk]

Hi

I have a couple of questions about this 2 server solution.
Licensing, are we ok to use the same VBR license on both servers?
CBT, can there be two CBT logs (primary backups and replication) on each VM without any issues?
With v9, I understand you can replicate from backups rather than live, can you access the backup repositories using the secondary replication server, or will this 2 server solution only replication live VM's (ie. v8 functionality)

cheers

[Vitaliy S.]

Licensing, are we ok to use the same VBR license on both servers?

Yes, as long as you have enough sockets for all source hosts you're backing up replicating VMs from.

CBT, can there be two CBT logs (primary backups and replication) on each VM without any issues?

Yes, as CBT data is stored per each job.

With v9, I understand you can replicate from backups rather than live, can you access the backup repositories using the secondary replication server, or will this 2 server solution only replication live VM's (ie. v8 functionality)

In case of replicating VMs from backups it has to be controlled by a single backup server, as the second one will not be "aware" about backups stored in this repository.

[jlockie]

I am kind of a dork....the replicas can be fired up on the target host at any time?!?!!? This is fantastic. Piece of cake to test backups and run through a DR test using replicas. Huge win.

[Vitaliy S.]

the replicas can be fired up on the target host at any time?!?!!?

Yes, you can either do that through Veeam backup console or through connecting to the target host directly and powering these VMs on. In the second case you lose an ability to do automated re-IP, failback and other options though.

[lando_uk]

In case of replicating VMs from backups it has to be controlled by a single backup server, as the second one will not be "aware" about backups stored in this repository.

Maybe in the future, it would be good if the same server/repository can be used for multiple installs of B&R - So proxy and repository transport drivers can be aware of separate instances of B&R. Then we could for example import `live` offsite repository folders into restore/replication only instances of B&R for DR.

Or even have it like VMware with vCenters, allow multiple B&R master servers in the same solution so they can talk to each other or mirror the SQL for DR purposes. We have Commvault setup like this.

[Vitaliy S.]

Well... the situation you describe can be achieved today, but with some manual steps (such as a repository rescan task), please review this topic for more info > Replication from Backup Copy architecture question

[lando_uk]

OK, so I'm revisiting the DR process trying to make it better.
I'm setting up a new DR VBR as cold standby server at my DR site, should I map drives to the locations on my offsite copy jobs from the Production VBR and import then before my disaster happens, or shall I include the importing of jobs as part of the documented process?

[jmmarton]

If you copy your VBR config backup to the standby server, I believe importing that config in a DR situation should take care of everything.

Joe

[lando_uk]

Even if its on different VLANS than the original and half the repositories/proxies on the site that's gone up in flames would be missing?

I was also planning to run some replicas jobs on this cold standby, or should I have another VRB instance purely for reps?

[foggy]

Even if its on different VLANS than the original and half the repositories/proxies on the site that's gone up in flames would be missing?

At least those containing backups you will be restoring from will be available. And this is all you'd need.

I was also planning to run some replicas jobs on this cold standby, or should I have another VRB instance purely for reps?

Making it responsible for replication jobs will allow you to perform immediate automatic failover right from Veeam B&R console.

[lando_uk]

I don't replicate everything, just the big VMs that take ages to restore. So in the event of DR, rather then restoring the config DB, I can use this rep only server to import the offsite jobs into, ready for restoring those VMs that I'm not replicating, So back to the original question, do I map and import during the DR and make it part of the process, or constantly have those offsites imported and ready to roll?

[foggy]

Totally up to you. Do what you're most comfortable with, I don't think a few extra mouse clicks in case of DR will cost you much. In the second case, you'd still better rescan the repository prior to restoring, since the most recent restore points might be created after the latest automatic rescan would occur.

[lando_uk]

So does it periodically scan manually imported repositories automatically? So there's no issues with 2 different instances of VRB tracking the same bunch of files?

[foggy]

Yes, there are periodic automatic rescans. Provided your second instance just reads the repository contents, there should not be any issues.

[lando_uk]

Hi

I've imported the offsite jobs into the 2nd DR instance, via the Import Backup task. But they didn't update automatically with the latest restore points and I see no option to manually refresh. Rather that importing, do I actually need to add these offsite repositories into the DR instance as new repositories?

[foggy]

You can try to create the repository for that location and rescan it. If this doesn't help, please ask support for assistance.