Properly encrypting and storing backups is essential for recovery from a system failure or massive data loss.
While they have some similarities, data backup and disaster recovery planning require different tools and processes. The primary purpose of data backup is to make it possible to restore your information to use should the original copies become corrupted, lost, or otherwise unusable. Mainframes have an incredible track record of up-time, but they are typically a centralized system, meaning if the mainframe goes down or loses connection to the rest of the network, it can bring down the whole system and allow technical operations to grind to a halt.
Disks fail. Accidents happen. Data is deleted by one party when another party still needs it. Organizations have to be ready for the inevitability of those scenarios and be prepared to recover from them. This requires a backup and disaster recovery strategy. And it is critical to have this strategy in place before disaster strikes, before it is too late.
Encryption keys need to be backed up and accessible in case of a disaster. Businesses cannot afford to have their backups be inaccessible because they cannot be decrypted. Backed up data is useless if there is no way to restore it.
Your tech team should be able to rebuild databases from encrypted backups, but they will also need backups of the encryption keys. Those should be stored separately from the data they decrypt, but should also be protected off-site and on another system so they are not compromised if the main production system fails. However, to keep those backed up keys safe, they should also be protected with multi-factor authentication, so ensure only authorized staff are able to access them.
However, disaster recovery requires more than just having working copies of databases and file systems. It also means having a plan in place to get the backed-up data onto new production systems should the hardware it was originally running on becomes unusable. All the data necessary to rebuild the system and get it running again on different hardware should be part of the backup. And all that data should be backed up from the same point in time to ensure consistency.
Your disaster recovery plan has to take into account situations where you will not be able to restore backed up data to the original hardware. Therefore, in addition to having backups of the data, you also have to have copies of the applications that data runs on, and access to hardware on which it can be installed.
Backups used for disaster recovery must be stored at a remote location. It is a good idea to keep a local backup to quickly restore parts of a system, or to quickly recover from an error. However, keeping backed up data on the same hardware or even in the same facility is a risky choice. Having a comprehensive off-site backup is necessary for disaster recovery.
If you are not sure your backups can be restored they are not really backups. To make sure you are ready for disaster recovery, you should test restoring your backups to an offsite fail-over system. Ensuring your backups are actually usable should be a regular part of the backup process.
Most critical data should be encrypted, but off-site backups, in particular, should be protected with strong encryption. Also, when moving data from an off-site backup to disaster recovery hardware, files and databases should be encrypted. By encrypting data on the mainframe with MegaCryption, users can securely move encrypted data directly from the z/OS platform into the cloud, to remote sites, business partners, and disaster recovery centers via FTP or other transfer protocols.
If you’re looking for solutions for backing up and protecting the data on your mainframe, check out some of our data security software for corporations and other organizations. ASPG has solutions for encrypting and compressing backups, preparing them for transfer to off site disaster recovery systems.
