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