Backup and Restore

Backup and Restore is essentially a component of good IT service Continuity Planning. As such, Service Design should ensure that there are solid backup strategies for each service and Service Transition should ensure that these are properly tested.

In addition, regulatory requirements specify that certain types of organization (such as Financial Services or listed companies) must have a formal Backup and Restore strategy in place and that this strategy is executed and audited. The exact requirements will vary from country to country and by industry sector. This should be determined during Service Design and built into the service functionality and documentation.

The only point of taking backups is that they may need to be restored at some point. For this reason it is not as important to define how to back a system up as it is to define what components are at risk and how to effectively mitigate that risk.

There are any number of tools available for Backup and Restore, but it is worth noting that features of storage technologies used for business data are being used for backup/restore (e.g. snapshots). There is therefore an increasing degree of integration between Backup and Restore activities and those of Storage and Archiving (see section 5.6).

Backup

The organization’s data has to be protected and this will include backup (copying) and storage of data in remote locations where it can be protected – and used should it need to be restored due to loss, corruption or implementation of IT Service Continuity Plans.

An overall backup strategy must be agreed with the business, covering:

• What data has to be backed up and the frequency and intervals to be used.
• How many generations of data have to be retained – this may vary by the type of data being backed up, or what type of file (e.g. data file or application executable).
• The type of backup (full, partial, incremental) and checkpoints to be used.
• The locations to be used for storage (likely to include disaster recovery sites) and rotation schedules.
• Transportation methods (e.g. file transfer via the network, physical transportation on magnetic media).
• Testing/checks to be performed, such as test-reads, test restores, check-sums etc.
• Recovery Point Objective. This describes the point to which data will be restored after recovery of an IT service. This may involve loss of data. For example, a Recovery Point Objective of one day may be supported by daily backups, and up to 24 hours of data may be lost. Recovery Point Objectives for each IT service should be negotiated, agreed and documented in OLAs, SLAs and UCs.
• Recovery Time Objective. This describes the maximum time allowed for recovery of an IT service following an interruption. The Service Level to be provided may be less than normal Service Level Targets. Recovery Time Objectives for each IT service should be negotiated, agreed and documented in OLAs, SLAs and UCs.
• How to verify that the backups will work if they need to be restored. Even if there are no error codes generated, there may be several reasons why the backup cannot be restored. A good backup strategy and operations procedures will minimize the risk of this happening. Backup procedures should include a verification step to ensure that the backups are complete and that they will work if a restore is needed. Where any backup failures are detected, recovery actions must be initiated.

There is also a need to procure and manage the necessary media (disks, tapes, CDs, etc.) to be used for backups, so that there is no shortage of supply.

Where automated devices are being used, pre-loading of the required media will be needed in advance. When loading and clearing media returned from off-site storage it is important that there is a procedure for verifying that these are the right ones. This will prevent the most recent backup being overwritten with faulty data, and then having no valid data to restore. After successful backups have been taken, the media must be removed for storage.

The actual initiation of the backups might be automated, or carried out from the Operations Bridge.

Some organizations may utilize Operations staff to perform the physical transportation and racking of backup copies to/from remote locations, where in other cases this may be handed over to other groups such as internal security staff or external contractors.

If backups are being automated or performed remotely, then Event Monitoring capabilities should be considered so that any failures can be detected early and rectified before they cause problems. In such cases IT Operations has a role to play in defining alerts and escalation paths.

In all cases, IT Operations staff must be trained in backup (and restore) procedures – which must be well documented in the organization’s IT Operations Procedures Manual. Any specific requirements or targets should be referenced in OLAs or UCs where appropriate, while any user or customer requirements or activity should be specified in the appropriate SLA.

Date: 2014-12-29; view: 909