Restore

Backup

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 requirement s 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).

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 Plan s.

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 Target s. Recovery Time Objectives for each IT service should be negotiated, agreed and documented in OLAs, SLAs and UCs.
• How to verify that the backup s will work if they need to be restore d. Even if there are no error codes generated, there may be several reasons why the backup cannot be restored. A good backup strategy and operation s procedure s will minimize the risk of this happening. Backup procedure s 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 failure s 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 problem s. In such cases IT Operations has a role to play in defining alert s 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 requirement s or targets should be referenced in OLAs or UCs where appropriate, while any user or customer requirement s or activity should be specified in the appropriate SLA.

A restore can be initiated from a number of sources, ranging from an event that indicates data corruption, through to a Service Request from a user or customer logged at the Service Desk. A restore may be needed in the case of:

• Corrupt data
• Lost data
• Disaster recovery/ IT service Continuity situation
• Historical data required for forensic investigation.

The steps to be taken will include:

• Location of the appropriate data/media
• Transportation or transfer back to the physical recovery location
• Agreement on the checkpoint recovery point and the specific location for the recovered data (disk, directory, folder etc)
• Actual restoration of the file/data (copy-back and any roll-back/roll-forward needed to arrive at the agreed checkpoint
• Checking to ensure successful completion of the restore – with further recovery action if needed until success has been achieved.
• User/ customer sign-off.

Дата добавления: 2014-12-23