The Mainframe's Role in Disaster Recovery Planning
When it comes to disaster recovery, no piece of the IT infrastructure gets more attention than the 'big iron'. This being true, it makes sense to make your mainframe the center of your DR strategy.
We have all heard the statistics: when disaster strikes, 30 % of the companies affected went straight out of business and another 29 % closed shop within the next two years. With today's geographical distribution of companies, remote locations and, accordingly, remotely located business critical data, disastrous events and their impact are not just limited to corporate headquarters. Now, disaster can happen anywhere, and even if the systems are physically away from headquarters data center, the overall business can be affected in the worst possible way.
"But we do backup of all our servers", you may say --- and that's good. However, it may not be good enough.
My theory is that you need to consolidate backup data at the most safe and secure point in the enterprise. The S/390 mainframe, where available in a corporate IT infrastructure, is that safe and secure point. Backup of all open systems data to this machine allows for sophisticated, efficient recovery strategies. It concentrates all business data at the one location which is most likely to go back on-line first, even in worst-case scenarios.
It's like back in school, where this one kid in your class had a big brother who would always be there in times of trouble. It is the same with the mainframe --- it will likely be the last system to go down and the first one to go on-line again.
The corporate data center and mainframe typically have the most elaborate disaster recovery plans which are tried and proven. Integrating open systems data into that platform integrates all open systems with the mainframe data center's DR.
Business continuity planning is more than IT's plan for disaster recovery, and certainly more than a schedule for nightly backups. Business processes rely on applications and data, and open systems applications on departmental servers are essential to the business. Many backup/recovery solutions create discrete islands of data, one per department or, even worse, one per server.
In disaster situations, those islands of data, dozens, if not hundreds or thousands of them, all need to be managed. Then, decisions must be made on what to recover first - which systems to rebuild and which to let go.
If your company runs a S/390 mainframe, consider making it the hub for all enterprise backup --- and the central point for managing all recovery. Here's how it works. Day-to-day, all open systems data from applications, file servers and, potentially, workstations, is backed up to the mainframe. From there, according to set policy, all or a subset is replicated to a disaster recovery site.
In a disaster situation, the mainframe operations get switched over to the secondary site, and the open systems backup data goes along with it. At the secondary site, all open systems data is now available and can be recovered according to policy. The number of people involved is kept at a minimum due to centralized management and automation. This ties in with the volume of data storage administrators can manage on open systems (roughly 750 GB per admin on average, according to sources like Horison Information Strategies) and the order of magnitude difference to S/390 (around seven to ten TB per administrator on average per Horison Information Strategies).
For clarity, let's look at an example. Consider an insurance company with a sprawling campus at their corporate headquarters. In addition to the data center with its S/390 mainframe, the company has departments with their own 'little' server rooms. Each department with a server infrastructure of its own relies on the applications and data on those servers. At the corporate data center, a number of the most critical departmental servers are co-located; however, not all departmental systems can be kept there.