This page explains how backup and restore requests are normally handled. Backup scope, retention, recovery objectives, and costs depend on the contracted service.

## Backup Scope

Backup services are only included where explicitly contracted.

Where backup services are included, CFTS may provide:

- backup orchestration
- backup monitoring
- retention scheduling
- restore assistance
- backup storage or archive storage where quoted

Backup services may not include application-consistent backup unless this is designed and agreed for the workload.

## Client Responsibilities

Clients should confirm:

- what data is critical
- what systems require backup
- what retention period is needed
- how much data loss is acceptable
- how quickly systems need to be restored
- whether databases need application-aware backup
- whether restored data must be validated by the client

CFTS strongly recommends that clients maintain independent copies of critical data where appropriate.

## Restore Request Information

A restore request should include:

- affected service, hostname, domain, or system name
- requested restore point or approximate time
- files, folders, database, mailbox, VM, or service to restore
- reason for restore
- urgency and business impact
- whether the restore should overwrite current data or be restored separately
- contact person who can validate the restored data

## Restore Options

Depending on the service and backup design, restore options may include:

- file or folder restore
- database restore
- mailbox restore
- VM or system restore
- restore to alternate location for review
- full service recovery after major failure

Not all restore options are available for every service.

## Application Consistency

Infrastructure-level backup can protect disks, files, or systems, but some applications require special handling to ensure consistency.

Examples include:

- databases
- mail systems
- accounting systems
- transactional applications
- applications with active file locks

Unless agreed otherwise, clients remain responsible for validating application consistency after restore.

## Recovery Objectives

Recovery Time Objective and Recovery Point Objective depend on:

- backup frequency
- backup retention
- data size
- storage platform
- application behaviour
- network conditions
- restore destination
- complexity of the failure

RTO and RPO are not guaranteed unless explicitly stated in a service agreement.

## Backup Limitations

Backups may not protect against every scenario.

Examples include:

- data changed before the oldest available restore point
- corruption that existed before backup
- application-level inconsistency
- client-side deletion outside retention windows
- unsupported application formats
- service termination after retention expiry

## Related Documents

- [Infrastructure SLA](/10_Terms-of-Service/20_Infrastructure-SLA)
- [Shared Responsibility Model](/01_Client-Guidance/15_Shared-Responsibility-Model)
- [Managed Services Addendum](/10_Terms-of-Service/15_Managed-Services-Addendum)
- [Offboarding and Termination](/01_Client-Guidance/50_Offboarding-and-Termination)