Now let's discuss the disaster recovery strategies and ideas and the strategies are important and essential
to ensure business continuity despite unexpected failures or any outage events.
Now with ideas, we do have multiple assets, but multi-asset by itself is not enough because it can't
protect from logical debris, corruption or from malicious attacks.
For example, save the data in your master instance gets corrupted.
The stand by instance data is also going to get corrupted so they will not be able to protect you from
logical, deep corruption issues are from the malicious attack issues.
So Malda easy by itself is not enough.
We have to have a disaster recovery plan and there are two key metrics that are part of any D-R plan,
the RTA and RPA.
So what are these terms?
RTA stands for Recovery Time Objective and RPA stands for Recovery Point objective.
All right, so first, let's look at the RTA.
Now, RTA is recovery time objectives.
So you have a disaster and then there will be some downtime before your database becomes operational
again.
So the amount of downtime you have is the RTA.
So RTA measures your downtime to how long it takes to recover from a disaster is your RTA and is generally
expressed in Arbour's OK and the RPO or the recovery point objective is used to measure the amount of
data loss.
So RPA is the amount of data loss you experience because of a disaster.
So how much data you're likely to lose if there is a disaster is the indication of your RPO.
So RPO indicates how much data you could lose after a disaster.
It's also expressed in others.
For example, RPO one hour means you could lose an hour worth of data.
All right.
So these are the two key metrics in any D-R plan.
And all is Petare.
That is point in time.
Recovery offers you with an RPO of five minutes because Arnie is right log's to three every five minutes.
The maximum amount of data loss you could have is about five minutes.
So it adds Vitara.
You get an RPA of five minutes.
All right.
Now let's compare the D.R strategies available in A.D.s.
So here are three strategies.
You can have automated backups, you can use manual snapshots, and you can also have read replicas
for the purposes when it comes to recovery time objective.
That is, the amount of downtime replicas provide you with the best RTA.
That is the least downtime, and they also provide you with best RPA.
That is, there is a minimal data loss because they use asynchronous replication.
So you're hardly going to lose any data in case of a disaster.
At the same time, the cost of red replicas is going to be high because for each replica you pay the
same price that you pay for any database instance.
So if you use two replicas and one last, for instance, you're going to pay for three instances.
So that is 3x the cost.
And Republicans support cross region disaster recovery manual snapshots also support across region recovery,
while automated snapshots can only be used in a single region.
Of course, you can copy the automated snapshots into a manual snapshot and then do across region recovery.
All right.
So you can go through this table and understand the audio and RPO implications of different D-R strategies.
And remember, when you use replicas, there is certain replica LACHSA.
That is the amount of time that the replica is behind the source database that is going to indicate
your RPO are the amount of data lost.
So that's going to be in milliseconds, I believe, most of the times.
And replica lag can impact your recovery.
And another important thing that you have to remember is that flail away to an idea, read replica is
a manual process.
It's not an automated process, so you have to manually wheel or to the arduous read replicas if your
master instead goes down, a replica is not going to be automatically promoted.
And a good PR plan should always include a combination of all these options.
You should have backups, replicas, as well as multiple azn multiregional deployments.
So that's how a good PR plan is created.