CFTS Documentation
Backup and Restore Requests
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