Re: VLDB RTO issue

You're running RAC, so I assume this is all on-prem.

What is your storage solution? If it's EMC, for example, you could do BCV backups and easily restore from BCV in less than two hours. I'm on AWS, and our largest database is over 12 TB, quickly approaching 13 TB. We take AMI snapshots daily, and if necessary, I can restore from AMI backup in about 15 minutes.

It really depends on your storage technology.

If you're strictly relying on RMAN (or traditional non-RMAN) backups, copying files, I'm not sure you can restore 13 TB in two hours. I guess there's a chance, if you have the CPU and I/O resources and run recovery in parallel.

I just saw Tim's comment come and ,and he, of course, offers an excellent suggestion, and probably far cheaper than my suggestion about storage snapshots, unless you already own the technology.

-Mark

On Fri, Feb 21, 2020 at 2:42 PM Harinderpal Singh <harinderpsingh_at_gmail.com> wrote:

> Hi there,
>
> The database for our critical Banking application is 13 TB, and our RTO
> (Recovery Time objective) is 2 hours. We are running on 12C and have 3
> nodes RAC clusters in both Prod & DR and have Active Data Guard set up too.
>
> But our company's Audit & Risk compliance team has flagged us with VLDB
> break asking us how would you restore your large DB from the backup in 2
> hours if there will be any Cyber Attack and corruption gets propagated to
> DR. I know this kind of restore/recovery may not be required ever, but we
> still have to prove that we have a strategy in place to meet our RTO of 2
> hours in case we have to restore from backup. I would like to mention that
> we have to keep at least 8-10 years of data in our DB for compliance
> purposes.
>
> I know there might be lots of DBAs on this forum who could be supporting
> VLDBs, can you please share how have you implemented VLDB recovery
> solutions for your DBs?
>
> Thanks,
> Harinder Singh
>
>
>
>
>

--
http://www.freelists.org/webpage/oracle-l