Scale-out repository architecture with multi site

[archvector]

Hi,

Could you please confirm me the current backup architecture is feasible?

I have 3 sites. Site A is active site. Site B is DR site. Site C is a witness site that also include a S3 on prem solution.

A single VBR server is managing the whole environment. This VBR is located on DR as recommended in best practices.
I would like to know if it's possible to have a scale-out repository composed of 2 performance tier and 1 capacity tier:

1 performance tier is a local repo located on site A
1 performance tier is a local repo located on site B
1 capacity tier (S3) is located on site C

1) I can perform by RMAN backups in active site (A) that will go on performance tier of site A
2) Backups will be replicated to site C (S3)
3) I download backups from capacity tier to performance tier repo on site B (since it's empty)
4) In case of switchover, i can run my backups on site B seamlessly
5) Those backups will go in performance tier of site B
6) those backups will be replicated to capacity tier on site C
7) if i switch back, i can download backup from capacity tier (C) to performance tier on site A and restart production

Is that correct?

[tyler.jurgens]

I wouldn't go this route at all. The SOBR may and will create backups to whatever extent that exists in that SOBR based on a few factors (capacity, free space, etc). You can't control backups from Site A to only land on the extent in Site A, nor can you force the SOBR to download backups from the capacity tier to only download to extent B.

You'd be better off creating two SOBRs. One performance tier in Site A with Capacity tier in Site C, and one SOBR with a performance tier in Site B (no capacity tier).

In the event of a disaster, you import backups from Site C's capacity tier into site B's SOBR extent. You may still see a new backup chain created on your capacity tier because of the MoRef changes, but you'll at least have backups.

[chris.childerhose]

I agree with Tyler on this one, as he has outlined. It would make more sense to have the layout Tyler suggested or another possibility is to have a SOBR in Site A with the Capacity Tier in Site C as laid out, but for Site B (DR) you could have just a standard repository where you send Backup Copy Jobs from site A. There are many ways to accomplish this, but it will all be dependent on what your SLAs and RPO/RTO are within your organization.

[archvector]

Thanks for your quick replies. I have updated the pattern according to your proposals:




So I understand it's possible to push backups from the capacity tier of SOBR#1 to a perfo tier SOBR#2 (even if it's 2 differents SOBR), that's it ?

@Chris, i'm not sure i can do backup copy jobs here because the backups are mainly oracle backups generated by the Veeam oracle plugin(RMAN+ SBT API). I guess VBR doesn't consider those backups as "backups" but more as basic files stored in a VBR repo.

So the procedure will become:

1) RMAN backups to SOBR 1 Performance tier (Site A)
2) Backups are replicated to SOBR 1 capacity tier (site C)
3) I download backups from SOBR 1 capacity tier (Site C) to SOBR 2 performance tier (site B)
4) In case of switchover, i can run my backups on site B seamlessly because backups will be present in performance tier (site B)
5) Those backups will go in SOBR performance tier of site B
6) those backups won't be replicated to capacity tier on site C (since no capacity tier)
7) if i switch back active prod to site A, i won't find the latest backup done on site B since it's in SOBR#2 which is not pushing data to site C
8 ) i will redo a full backup as soon as i switch PROD to site A to have a complete restore point

My main concern is that RMAN backups must be seen the same way on both site (Site A/B) to avoid expiring files when doing the backups crosschecks.

[chris.childerhose]

Thanks for the clarity on that. You can still do a copy job, but it would be a File Copy job instead of a backup now that I know about the plugin. If it is storing files on your repo, that is another way to configure things, but doing what is best for your environment is key. Best of luck with the new set up.

[PetrM]

Hello,

The algorithm above looks a bit unusual at first sight but I can't give any reason why it would not work but I wouldn't go this way. Also, don't forget that you need to reconfigure a plug-in to use SOBR 2 and map a backup.

The main problem that I see with this approach is that you make 2 hops to get backups in site B: copy from site A to site C AND download from site C to site B. Instead, you can use a backup copy job to transfer data from site A to site B (copy to the Capacity Tier on site C stays in place) directly. In case of a failure of site A, you can promote your backup copy to a primary job and continue using site B seamlessly.

Thanks!

[archvector]

Hi,

I didn't know that a backup copy job was possible with RMAN backups done throught veeam oracle plugin. I will definitively go with this achitecture in the case i can get an appropriate bandwidth between sites A and B

Thanks

[chris.harvey]

Morning,
Can I ask what is your intersite available bandwidth and latencies between sites a/b/c ?

Chris

[archvector]

Hi

Sorry i didn't noticed your question. I don''t know the latency
The banwidth is 10GB, we are reaching around 750MB/sec (no dedup/no compression) between the site B and site C during the offsite copy