StandbyMP will revolutionize how organizations manage DR enterprise-wide by making the same Gold Standard of DR available to both Oracle SE and MS SQL Server users - all from a single common user interface.
What is Recovery Point Objective?
Recovery Point Objectives (RPO) refer to your company’s loss tolerance: the amount of data that can be lost before significant harm to the business occurs. That is, how much data can you afford to lose? This objective is defined as the time from the data loss event back to the most recent preceding backup.
If you back up all your data daily, then in the worst-case scenario you will only lose 24 hours of data (RPO = 24hrs). For some companies and applications this is acceptable but for others it is catastrophic. RPOs for business critical databases will likely be much shorter, 30 minutes or less.
It is important you align your architecture with your RPO requirements. This may mean increasing the frequency of your backups or adding a warm standby database. Your architecture should also be resilient and meet your RPO requirements across all disasters.
What is Recovery Time Objective?
Recovery Time Objective (RTO) refers to how much time an application can be down without causing substantial damage to the business. That is, the amount of time from the disaster before you can resume business as usual. Note, RTO must take into consideration the steps that must be taken to restore your data and application.
Some applications can be down for days without significant consequences. Some high priority applications can only be down for a few seconds without incurring impact on employees, customers or lost business.
Why is RTO and RPO important in Disaster Recovery?
Despite their similarities, RPO and RTO serve different purposes. The Recovery Time Objective is concerned with getting applications and systems back up and running as soon as possible within the pre-defined timeframe. The Recovery Point Objective is concerned with the amount of data (expressed as time) that could be lost following a failure event. An upset customer may be one consequence, but losing trust and thousands of dollars through lost customer transactions could be even more disastrous.
Set realistic objectives
In an ideal world, your data protection infrastructure would immediately restore all applications and data right at the moment of failure. But this is the real world, and while you can install an infrastructure where an application can immediately failover and restore data to near-zero loss, these can be very resource-consuming and expensive. Therefore, companies need to set realistic recovery objectives based on their budget, resources and business priorities. Ensure you define the RPOs and RTOs with your business teams, and discuss what they mean to the business both from a data loss and financial perspective.
How to ensure your DR solution incorporates your RTO and RPO requirements?
You must ensure your Disaster Recovery solution delivers agreed RTO and RPO timeframes within your budget. If your business and technical team have agreed your business critical database RTO is 15 minutes then the database must be recoverable within that 15 minutes, alongside any applications that must be simultaneously restored. Similarly if your RPO is 1 hour, you must ensure the solution allows data replication within that time period. When you go to market for your Disaster Recovery solution ensure you articulate both your RPO and RTO to the potential vendors, and request they confirm this is achievable with their particular solution. This way you ensure your business will be fully protected in the case of an unexpected outage or disaster.
Using a physical standby database for great RPO and RTO
A warm standby database, either on-premise or in the cloud, is a resilient way to achieve minimal dataloss (RPO) and fast recovery (RTO) that is not possible with traditional backup solutions. Dbvisit StandbyTM for Oracle Standard Edition and Oracle Dataguard for Oracle Enterprise Edition use physical replication technology to create a standby database that is continuously verified to ensure successful failover at any time.
Why use Standby™ for DR?
