Let’s face it, DR – the business of disaster recovery planning – is not the most glamorous of topics in the I.T “universe”, and is oftentimes treated as a poor cousin. But its reticence in speaking up for itself doesn’t make it any less important! There are forces at work ‘out there’ that threaten to jeopardize the carefully crafted structure and order of your business. So we need to be cognizant of this threat.
When thinking about disasters (if we think about them at all) we usually don’t imagine they will happen to us. These events happen to other people, in other countries. We naively expect that everything will be fine, and on this thread of hope carry on with business as if it will be.
Hope is not a strategy.
Your data is a critical asset and ongoing, uninterrupted access to it is essential for business continuity. Yet all too often – even today – we hear of situations where businesses fail to protect their data. But with cost-effective solutions such as Dbvisit Standby and cheap cloud infrastructure available, there really is no excuse.
When we see significant weather events or natural disasters on the news, it may jolt us into thinking about putting a disaster recovery plan of some sort into place – or dusting off the legacy one we have. But natural disasters are only one cause of unscheduled downtime. There are at least 4 other common causes of business outages to fortify against, and reasons to be afraid if we are unprepared:
1. Human error
2. Server failure
3. Storage failure
4. Power outages
To ensure you are covered, whatever the cause of the outage, you need to have a thorough disaster recovery plan in place. This is a mandatory operational business practice. So how do we go about this?
1. Understanding the business requirements, both during and after a DR event. The finer detail of this must be discussed, and nothing simply assumed.
2. Determine the RPO (Recovery Point Objective - data loss threshold) and RTO (Recovery Time Objective - downtime tolerance)
3. Change control – determine who has authority and responsibility for actions during a disaster "event"
4. Documentation - getting this down on paper in as much detail as possible helps refine the plan. This step takes it from the abstract, establishing it as a living, evolving entity.
5. Testing
Arguably, the most consistently overlooked of these points is testing. It is not enough to have developed a DR plan and ticked the box some time ago. It is imperative that you schedule and conduct regular reviews every 6-12 months, or as dictated by business changes. Having confidence that this strategy will hold your business in good stead should a disaster occur is priceless. BAU activities that trigger this review include staff changes, upgrades, software implementations, and new databases.
We are seeing more governments and authorities require organizations to regularly test their DR strategies. Often this means switching over to the DR location and even running business operations from there for a period of time. In view of this, it helps to have tools that can assist with the work of DR testing, enabling you to conduct this work efficiently.
In the Oracle Database Standard Edition world, Dbvisit Standby is one such example. Not only does it protect your valuable data and enable business continuity. But it also boasts a suite of integrated functions that can aid in DR testing activities. These include Graceful Switchover (role reversal) and creating standby databases (CSD).
For further information on Dbvisit Standby as a disaster recovery solution, you can contact us here. Or simply download a free trial and put it through its paces.