This guide on OpenStack backup and recovery options is intended for Instances running on HP Cloud as client. This guide is not intended for the backup of OpenStack installation itself. Maybe this can be named as OpenStack Instance Recovery instead of OpenStack Backup and Recovery. There are many methods to take backup on OpenStack for many variable components of OpenStack powering the websites which not only limited to OpenStack Nova, that is why broadly the word OpenStack has been used. Datacenter backup and server backup are different bigger stories.
OpenStack Backup and Recovery Options For Raksha
Previously, we have talked about backup and recovery using OpenStack Raksha and Floating IP. Possibly Raksha and Snapshot is most commonly used backup tool. However if OpenStack itself fails or the snapshot get corrupted or the private key is lost, this backup will frankly proved to be useless. The reason broadly for this kind of failure of back is due to non-OpenStack related issues.
In other words, we must take another backup of this OpenStack snapshot on different datacenter of different provider. There is a feature to share image on OpenStack at client level. That is great for sharing images for infrastructural builds across the members. But that is not the way for taking backup of the snapshot as the instance will reside on same datacenter. There is option to download the whole server snapshot image – that can be done with wget from another server. Private keys must be kept along with it and instance deployed and tested before any disaster actually take place.
OpenStack Backup and Recovery Options For Object Storage/Swift
We often use the URLs of Object Storage/Swift directly as the only source of content. If the infrastructure fails, then these data will be lost. So, there is a genuine need of using OpenStack Python Swift Client to sync the files to local computer. Then, they should be compressed and encrypted for the purpose of upload to some other provider.
File Level Backup, Database Backup on OpenStack For Backup and Recovery
File level backup, database backup are very important for usability. If the whole backup of the public directory and database exists for a given WordPress installation, at least the website can be made to run on different provider in the face of a disaster. These backups are better to be kept on local computer, tested on local computer’s virtual machine and then written to optical disk. Database unlikely to cross the capacity of modern optical disks and there are lot of manufactures available for archival level backup.
Advertisement---
It must be ensured that alternative backups are taken – like for WordPress, we can take XML based backup, Database backup and obviously the server snapshot. More wider there will be options to switch back to restore the websites, more it will be easier and faster to restore the servers.
A security flaw on the server can create the disaster. File level backup can help in these cases.
Brief Description of Restoration Strategy
Disaster recovery and restoration is a big story. However, these should be planned beforehand to decrease the human thought process related delays. Multiple teams should use different methods at the same time to proceed for the recovery process – one team can proceed with XML and FTP file backup; another database and FTP file backup, another will create the platform freshly, restore the setup from web server settings backups, another should proceed with snapshot. Lack of manpower, lack of technical skill can delay the restoration process.
These Backups are agentless. Traditional agent-based backup are complex and not required for the usual clients. Backup strategies should be reviewed by academically certified experts.
