Heirloom Backup and Restoration – Heirloom Computing

All Heirloom subscriptions come with automatic backup and the ability to restore a complete working image of your application. The Backup Calendar Portlet (https://heirloomcomputing.zendesk.com/entries/21266873-backup-calendar-portlet) of the Heirloom Dashboard is how you manage backups for your persistent data volumes (application files and databases) as well as restore new, running instances of your application from those backups. Access the Heirloom Dashboard through paas.heirloomcomputing.com > Sign In > Dashboard.

The backup and restoration subsystem uses proprietary technology to carry out scheduled and unscheduled backups in a manner similar to Enterprise IT shops that run large mainframe environments. The Heirloom Dashboard is the window in the System Operators (SysOps) operations activity you control through a browser.

The standard Heirloom paid subscription backup schedule consists of daily backups taken at approximately 2am UTC (4pm PDT, 7PM EDT). It is approximate because the time it takes to complete a backup varies depending upon the load of the underlying infrastructure. Daily backups are managed and converted to weekly (Sunday) each week. A daily backup from the first of each month is also converted to a monthly backup. All backups adhere to the following schedule:

Daily backups with retention of 7 days
Weekly backups with retention of 5 weeks
Monthly backups with retention of 7 years (72 months)

Backups are converted from one form to another as new backups are taken. For example, as shown in the following Backup Portlet taken on May 25th :

The above snapshot of the Backup Portlet on May 25th shows that a daily backups have been taken for May 18th through May 24th (the backup for May 25th has not been taken at the time of this snapshot). The May 20th backup, although tagged as a daily will be converted to a Weekly Backup within a few days. Previous daily backups on May 6th and May 13th have been converted to Weekly Backups. Clicking the left arrow in the upper left corner would reveal other Weekly Backups in April. Finally, a daily backup taken on May 1st has been converted to this month's Monthly Backup, as shown in the figure.

An entire or full backup is taken of the underlying device housing your application files and database. For Windows-based Heirloom, this is the D: and/or F: drive. For Linux-based Heirloom environments this all files residing under /data or /hcc paths. A backup is replicated in 3 physical places. Although the original data volume resides on a single device, that device uses hardware (RAID-5) redundancy.

Typically backups are taken over a period of seconds. Because these backup transactions are not synced with your application, you may experience inconsistency among database records or file records. Standard database and database and file system checking (e.g., database undo/redo log application) are required should you restore from an in-use backup. Based on your subscription and level of instance concurrency associated with it, you can restore from one or more backups at once and use (application techniques) to move data records among the backups to your live system.

The actual volume snapshots are not accessible to you directly ... you cannot download or replicate them directly. Instead you use the Backup Portlet of the Heirloom Dashboard to "restore to a running instance". From that instance you can choose to download files using the instance's File Explorer.

Restoration of a backup tape implies the starting of a new instance of your application (with a new domain name to access it) and does not affect the running system. Restored systems are not meant to become "live" as the restored systems are temporary and the volumes associated with them will be removed when the instance is shut down. Use application techniques (or the file management interface provided to Heirloom instances) to move data between the restored instance and your production instance.

When you select a backup from the list available for a particular day a dialog box will show information about that particular backup.

The dialog indicates the type of backup (e.g., daily), the time it was taken and whether the backup was taken from a live running system (in-use), the integrity of the backup (100% Complete indicates a healthy backup) and whether you have restored it at any time prior to this date. From this dialog you can,

Restore a volume by starting a new instance of your application,
Delete the backup tape associated with the volume,
Cancel out of the menu without acting on the backup tape.

Upon restore a new instance appears in the Heirloom Dashboard Instances Portlet. This instance and the underling Data Volume will be named r-xxxxxxxx where x represents a hexadecimal digit. You can access the "home page" of your application with a URL something like http://r-1234abcd.apps.elpaas.com/ and the file-management portion of your site with http://r-1234abcd.apps.elpaas.com/admin (unless you have reconfigured the admin virtual directory in your Web server or turned off this functionality).

Newly restored instances and their volumes are they themselves not backed up. It is expected that because backups represent a snapshot in history, you do not want to make them your current production version of your application. To do so would lose all transaction records between the backup time and today. Unless, of course, you are restoring as part of a disaster recovery endeavor. In other words, the production system is irreparably damaged and you must get a working system up and running as quickly as possible. In this case you carry out these steps to get a system back in production,

Inform your users that unscheduled maintenance is taking place, perhaps by redirecting your DNS alias from its current myapp.apps.elpaas.com to a Web server with a static page "System Unavailable"
Use the Backup Portlet of the Heirloom Dashboard to restore and start an instance from the most recent backup
Verify the integrity of the application and its data using the restore URL given to you when restored
Use the Instance Portlet to bring down your damaged application instance, if it is still running
Use the Instance Portlet to bring down the working restoration instance r-xxxxxxx
Use the Volume Portlet to rename the production (now not-in-use) volume to "myapp-old"
Use the Volume Portlet to rename the r-xxxxxxxx restored version to your production myapp
Use the Instance Portlet to start your new myapp instance
Verify that your DNS redirection to myapp.apps.elpaas.com and, thus, to your working production instance.

If you are operating under a fail-soft condition where your app is still partially working, but you need to restore some data components follow the simpler set of restoration procedures,

Use the Backup Portlet of the Heirloom Dashboard to restore and start an instance from the most recent backup
Copy individual data files or conduct DB dump/restore from the restored system to the production system
Use the Instance Portlet to terminate your restored instance. Its volume will eventually be removed (although the backup from which it was made can be re-restored at any time).

When a restore is done it is carried out with the current version of the Heirloom platform, complete with OS security updates and improvements. Therefore, your application and data date from the time of the backup, but the OS may be newer. Keep this in mind if you've had to make changes to your application due to security restrictions.

Note: On occasion a backup may fail to take place at the selected time. Backups will be attempted every hour until a valid backup is completed. You may see variability in the backup time for this reason. Each backup is replicated in 3 places for redundancy. Although this generally ensures that physical hardware failure will not cause the loss of data, the current status ("100% complete") always reflects the consistency and availability of a backup.

0 Comments