This Schedule forms part of the Cloud Master Services Agreement and describes the scope, responsibilities and limitations relating to Backup and Recovery.”

It should be read alongside the Fair Use Policy and the Shared Responsibility Model for Cloud Services.

1. Backup scope

  1. Where you purchase Cloud Backup and Recovery Services, we will back up:
    • agreed virtual machines hosted on the Cloud Platform; and/or
    • agreed storage volumes or file shares hosted on the Cloud Platform;
    as described in your Order.
  2. Backup may be performed at:
    • virtual machine level (for example image-based or snapshot-based backups);
    • file or volume level; or
    • application-aware level (for example database-aware backups) where specifically stated.
  3. Backups are performed to storage that we control or procure from a backup provider. Backup data may be stored in the same data centre or in a different data centre or region, depending on the service you purchase.

2. Backup frequency and retention

  1. Unless stated otherwise in your Order:
    • backups are taken once per day (daily); and
    • backups are retained for up to 30 days.
  2. Different backup frequencies and retention periods may be available as options (for example multiple snapshots per day, or longer retention). These will be documented in your quotation or Order if selected.
  3. Once the agreed retention period expires, older backup data may be overwritten or deleted in line with our standard backup rotation processes.

3. Recovery objectives

  1. We aim to provide:
    • a Recovery Point Objective (RPO) of “up to 24 hours” for workloads covered by daily backups (that is, you may lose changes made since the last successful backup); and
    • a Recovery Time Objective (RTO) that is appropriate to the size of the data and the complexity of the restore request. In many cases this will be within Business Hours on the same Business Day for single-system restores, but complex or large restores may take longer.
  2. RPO and RTO are targets, not guarantees, and may be affected by:
    • data size and complexity;
    • network and storage performance at the time of restore;
    • the nature of the incident (for example logical corruption vs. hardware failure); and
    • dependencies on upstream suppliers.

4. Restore requests

  1. To request a restore, you (or an authorised contact) must log a ticket with our Service Desk, providing:
    • the system, volume or data set to be restored;
    • the desired restore point (for example date/time); and
    • whether the restore should overwrite the existing data or be restored to an alternate location.
  2. We will:
    • acknowledge the request within the normal response time for the agreed priority;
    • confirm which restore points are available; and
    • carry out the restore in line with the agreed scope.
  3. Complex restores (for example restoring individual items from large databases, or partial historical datasets) may require additional effort and may be chargeable on a time-and-materials basis. We will discuss this with you before proceeding.

5. Testing of backups and restores

  1. We monitor backup jobs for success or failure and will investigate backup job failures that we identify or that you report.
  2. You are strongly encouraged to schedule and participate in periodic test restores of critical systems and data. This helps confirm that backups are working as expected and that restored systems behave correctly.
  3. Where you request structured, documented restore testing (for example annual DR tests), this may be provided on a project or time-and-materials basis.

6. Customer responsibilities

  1. You are responsible for:
    • telling us which systems or data must be backed up, and for informing us promptly of any changes to that list;
    • reviewing backup reports or summaries we provide and raising concerns if you believe something is missing;
    • ensuring that applications are correctly quiesced, closed or placed into backup mode where required for a supportable backup (for example some databases or legacy applications);
    • requesting restores in good time where you need data recovered; and
    • maintaining your own separate backup arrangements for systems or data not covered by this Schedule.
  2. If you choose not to back up certain systems or data, or if you instruct us to remove them from our backup scope, you accept the risk of data loss for those systems or data.

7. Backup exclusions and limitations

  1. Backups under this Schedule do not guarantee:
    • zero data loss (RPO is “up to 24 hours” for daily backups unless agreed otherwise);
    • instant recovery (RTO depends on size, complexity and platform conditions); or
    • recovery from every possible scenario (for example application-level corruption that has already been replicated into all backup copies).
  2. Unless specifically stated, the following are excluded:
    • backup of systems or data not hosted on the Cloud Platform;
    • backup of endpoints or on-premise devices (unless part of a separate service);
    • version-level restore of individual application components where the application does not support such restores; and
    • long-term archival storage for compliance beyond the agreed retention period.
  3. If you require longer retention or specific archival arrangements, this must be purchased as a separate service.

8. Disaster recovery and business continuity

  1. This Schedule is focused on backup and recovery of systems and data. It does not, by itself, provide full disaster recovery or business continuity, such as:
    • maintenance of warm or hot standby environments;
    • automated failover between sites or regions; or
    • recovery of your wider environment (for example office connectivity, on-premise systems or third-party services).
  2. Where disaster recovery or business continuity services are required (for example failover sites, replicated environments or standby infrastructure), these will be defined in a separate Schedule or Statement of Work.