Hi
I'd go with incrementally updated backup. You can find some examples on the
web0
https://www.google.com/search?q=rman+%22for+recover+of%22+%22incrementally+updated+backups%22
In order to reduce RTO, I'd use cumulative incremental backups rather than
the default (differential) incremental backups
To recover from logical corruption and user errors, I'd keep the image copy
not up-to-date to allow faster point-in-time restore
I mean, I'd run something like this each hour:
RUN {
RECOVER COPY OF DATABASE WITH TAG 'MY_DB_IMAGE_COPY' UNTIL TIME
'SYSDATE-1';
BACKUP INCREMENTAL LEVEL 1 CUMULATIVE FOR RECOVER OF COPY WITH TAG
'MY_DB_IMAGE_COPY' DATABASE;
BACKUP DEVICE TYPE DISK TAG 'MY_DB_ARCHIVELOGS' ARCHIVELOG ALL DELETE ALL
INPUT;
DELETE NOPROMPT OBSOLETE DEVICE TYPE DISK;
}
regards,
Andrea
Il giorno ven 21 feb 2020 alle ore 20:42 Harinderpal Singh <
harinderpsingh@xxxxxxxxx> ha scritto:
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
