Backup and Restore Procedure

Purpose

This Procedure describes how backups are made and watched, how data is restored, and how we prove every quarter that a restore works within our recovery targets.

Scope

It applies to the backups of our internal systems and of the hosting platforms we run for customers, in both data centres.

Roles

• Service Desk Lead: owns this Procedure, watches the backup jobs, and runs the quarterly restore test.
• System owners: approve restores of the systems they own.
• Change Manager: approves the restore of a production system that is in use.
• Incident Coordinator: decides on a restore during a disruption.
• ISMS Manager: receives the test report.

Procedure

Daily backups

1. Backups run daily. They are encrypted and copied to the other data centre.
2. Backups are kept for 35 days and are then deleted automatically.
3. The Service Desk checks the result of every job each working day.
4. A failed job is turned into a ticket within 1 working day, and the ticket stays open until a good backup exists.

Restore requests

1. A restore is requested through a ticket that names the system, the data, and the point in time.
2. The owner of the system approves the request. For a production system in use, the Change Manager approves as well.
3. The Service Desk restores into a separate location first, unless the Incident Coordinator has ordered a direct restore during a disruption.
4. The requester confirms that the restored data is correct before the ticket closes.

Quarterly restore test

1. Every quarter the Service Desk restores three systems in an isolated environment. The systems differ from one quarter to the next so that all critical systems are covered over time.
2. Each restore is checked for integrity against the source: file counts, checksums, and a start-up check of the service.
3. The restore time is compared with the target of 8 hours, and the age of the data with the target of 24 hours of data loss at most.
4. The Service Desk Lead writes the test report and files it as Evidence on the quarterly Task.

Defects

1. Every failed check, missed target, or missing backup becomes a Task with an owner and a due date.
2. The ISMS Manager follows the Tasks until they are done and reports repeated failures to the Management Board.

Records

• The backup job results and the tickets for failed jobs.
• The restore tickets with their approvals.
• The quarterly test reports and the Tasks that came from them.

Related documents

• Business Continuity and Disaster Recovery Policy
• Incident Handling Procedure
• Change Management Procedure

Review

The Service Desk Lead reviews this Procedure at least once a year and after a significant change, and after any quarterly test that missed a recovery target.