Last updated: 23 July 2026. View change log.

This Schedule is part of the Cloud Master Services Agreement between you and Cultrix Limited (“Cultrix”, “we”, “us”). It describes the scope, responsibilities and limits relating to Backup and Recovery.

Please read it alongside the Fair Use Policy and the Shared Responsibility Model for Cloud Services.

1. Backup scope

  1. Where you buy 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 set out in your Order.
  2. We may back up 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 we specifically state this.
  3. We take backups to storage that we control or buy in 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 buy.

2. Backup frequency and retention

  1. Unless your Order says otherwise:
    • we take backups once per day (daily); and
    • we retain backups 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). If you select these, we will document them in your quotation or Order.
  3. Once the agreed retention period expires, we may overwrite or delete older backup data 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 suits 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 versus 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, telling us:
    • the system, volume or data set to be restored;
    • the restore point you want (for example date/time); and
    • whether the restore should overwrite the existing data or go 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 take extra effort and may be chargeable on a time-and-materials basis. We will discuss this with you before we proceed.

5. Testing of backups and restores

  1. We monitor backup jobs for success or failure, and we will investigate backup job failures that we identify or that you report.
  2. We strongly encourage you to schedule and take part 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 ask for structured, documented restore testing (for example annual DR tests), we may provide this 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 letting us know promptly of any changes to that list;
    • reviewing any backup reports or summaries we provide, and raising concerns if you believe something is missing;
    • making sure applications are correctly quiesced, closed or placed into backup mode where this is needed for a supportable backup (for example some databases or legacy applications);
    • requesting restores in good time where you need data recovered; and
    • keeping 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 tell 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 we agree 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 we specifically state otherwise, 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 need longer retention or specific archival arrangements, you must buy this as a separate service.

8. Disaster recovery and business continuity

  1. This Schedule focuses on backup and recovery of systems and data. On its own, it does not provide full disaster recovery or business continuity, such as:
    • maintaining 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 you need disaster recovery or business continuity services (for example failover sites, replicated environments or standby infrastructure), we will define these in a separate Schedule or Statement of Work.