ITProjectManagement.org

IT checklist for backup and restore

This backup and restore checklist is written from the perspective of enterprise IT.

For this section we consider the following elements of backup:

  1. Firmware and device drivers
  2. Operating system
  3. Operating system configuration
  4. Installed Application
  5. Application configuration
  6. Application data

The scope of backup and restore possible for a customer depends on the technology boundaries (by implication you are relying/ trusting your service provider to fulfil their backup/ restore responsibilities on any items you cannot cover):

  • SaaS hosted applications should consider item 6 only and some basic application configurations, for example authentication setup.
  • PaaS hosted applications (e.g Microsoft Azure SQL database, Azure AD) you should consider items 5 and 6.
  • IaaS hosted applications (e.g. using Azure/ AWS virtual machines) should consider items 2 – 6.
  • Self hosted applications (which effectively includes appliances) should consider, items 1 – 6.

SaaS backup

  • Have a process to backup your data to a location that you choose (independent of the SaaS provider).
  • Have a method of backup of avaiable SaaS configurations such as authentication settings.

PaaS backup

Considerations for SaaS backup and restore apply, and in addition the following items:

  • Platform configuration backup process; is this a script that exports a file, is it an existing configuration file, is it combinations of this.

IaaS backup

  • Consider full virtual server backup when a full restore of the operating system, operating system configuration, installed application, application confuration and application data is desired. By implication full virtual server backup includes the operating system and application installation including the state of patches and any configuration, for example SSL certificates. Note, full virtual server backups can be expensive due to the amount of storage they require.
  • Note that without a full virtual machines backup a corruption in the operating system or the application requires these items to be re-installed (and for example, SSL certificates regenerated/ installed). This re-installation process can be automated, and this may be the preferred recovery approach as for some applications (in particular databases) the restore process does not suit a full virtual machine restore, rather the operating systems should be reinstalled, then the applciaton reinstalled, and then the *data* restored.
  • Consider file based backup if you need to do granula restore for an application configuration or the application data, often this applies to backup of database tables where data in a table needs to be restored that an application relies on. This process can also rely on application configuration settings if stored in a configuration file. Note that file based backup will not assist if there is an operating system of application level corruption that requires restore.

Self hosted backup

There are some additional considerations for backup and restore process for applications installed on physical servers:

  • Drivers, firmware, BIOS/ UEFI and any items that are specific to the operating system interacting with the hardware will need to be re-installed in the event of an operating system corruption. Ask yourself where and how you have these backed-up and how will you restore them?

General considerations

Regardless of SaaS, IaaS, PaaS or self-hosted there are some general items to consider:

  • Backup targets – the ultimate backup target should be independent to the system that is being backed-up and should also be at a physically different location. This can be achieved using backup to tapes which are then taken offsite, or by using backup over data networks to remote data storage locatons. This avoids a scenario where a service is corrupt that needs a restore but be actioned as the backup is also corrupt.
  • Backup frequency – how often are backups to be taken? Define this based on how much data you are willing to lose; backups one a day, by defintiion mean you could lose up to 1 days worth of data.
  • Incremental v full backups – Incremental backups only capture the change since the last full backup. This uses less data than only taking full backups. The downside is a restore requires the last full backup to be merged with the incremental backups to desired restore date; this increases the time taken for restore to complete.
  • Backup retention – how long are backups retained. Define this
  • Backup security – who has access to backup, what protections are in place to prevent malicous or accidential backup deletion.
  • Restore testing – Backups need to restore testing to ensure there is a reliable process in place. The best testing is automated and takes a subset of backup and gives a report on restore success rate. This allows any backup or restore issues to be proactively addressed.
  • Restore time – how long do you need to complete a restore within? This will help define your backup process and help define the measure of “success” for backup testing.