In many companies, there's a distinct difference between a company's ideal business continuity strategy and how those plans play out in reality. One of the most prevalent disaster-recovery (DR) myths is the belief that tape backups are a sufficient DR solution for most companies. While some organisations can indeed rely on a tape-based system for their recovery needs, those businesses are few and far between. A corollary to this myth is some companies' belief that once they've performed tape backups, they're free and clear. But unfortunately, many organisations use tape backups ineffectively at best and improperly at worst.
Companies should use a recovery point objective (RPO) to determine how much data they can potentially lose during any given disaster. For example, if users update data in a real-time application (such as a Web-based purchasing system), your RPO should be as close to zero as possible (within the limitations of your systems). But if these systems save data infrequently (such as a file server used mostly for read-only files), your RPO can be 24 hours or more.
If your RPO really is 24 hours or more, your organisation can potentially use tape backup as its sole DR solution. However, it's imperative that you follow best practices, including moving tapes off-site on a regular basis and performing test restorations from the tapes to ensure data integrity.
If your company's RPO is less than 24 hours, don't rely on tape as your sole DR solution. It's too risky to depend on a tape backup that more than likely occurs just once a day; if a system goes down before the backup window, you could easily lose an entire day's worth of data.
Instead of tape backups, begin investigating data replication solutions. Available for a great range of prices, these tools generally offer the ability to fail over to other servers and perform additional tasks.
The closer your RPO gets to zero data loss, the more expensive your DR solution is likely to become. Keep in mind that solutions that ensure absolutely zero data loss nearly always require large-scale disk-based storage arrays and much more bandwidth than other types of data-protection systems. However, bumping up an RPO to anywhere from a few minutes to several hours can expand your options dramatically.
It's vital that your organisation recognises and understands both the benefits and the risks of using only tape backup as a DR solution. Relying solely on tape backups, particularly if you're not using them effectively, can give your business a false sense of security about its disaster recovery strategy.
Talkback
Don't forget PIT (Point in Time). Per example, it's not nice to be able to restore a database but with index files that differ an hour or so because that will result in even worse RPO (aka: maximum data loss window) because now you have to re-index and what not.
Which is something to also take into account. Your RPO should also include the time needed to become aware of the problem and get the right people to respond to it in the right way. As well as doing the actual restore and making sure (diagnostics, tests, etc) that everything that was restored is complete, in sync with other systems and thrustworthy. And also notifying the users that they can begin operations again (including making up for the lost time like figuring out what was lost and what not and what needs to be redone how).
MTTR, Mean Time To Recognize, Mean Time To Repair, Mean Time To Recover.
Another thing is inter-system dependecies. OK, you finally have a PIT Bare Metal Restore Set of your database server and other systems (that you actually regularly test if they can be restored) but how do they relate to eachother in cases of inter-system dependecies? Suppose two seperate systems with their own databases (but interchained at the business process level) get out of sync by, say, 100000 financial transactions? Would you be able to not only detect that but also recover from that in a way that would not be a problem for, say, the corporate financial year end report with a, say, SOX Approved stamp on it? Being able to inject or undo 100000 financial transactions halfway a business process at will might not be what those people would like to find out.
To name but one example.
In other words: backup and restore solutions should be done from the perspective of business processes, procedures and requirements and nothing else. And they should be discussed in detail with every business official, from high to low, that might introduce new additional business (legal?) requirements (like business risks to avoid) into the backup and restore solution the organisation as a whole is in need of.
...that many forget is that the need to be able to restore and reinstate your business systems in a third party location. i.e. offsite.
It is fine and dandy to plan to restore your backups, and to prove that you can recatalogue your databases in a short period of time - but how about that disaster that has removed your hardware platform completely? loss of your computer suite/data centre? How long to replicate the environment / source new hardware / provide the comms / source the new working environment?...oh, and don't forget the poor techies that make it all happen - how many hours can they work before they drop?
Sorry, a bit off topic (!) but it is all part of the major issue of Business Continuity which so easily gets overlooked.