Skip to content

Backups

The whitesky.cloud BV Backups feature makes it easy to export virtual machines (VMs) to cloud storage near the IAAS system where they are running. It uses Restic to manage backups and S3-compatible storage to store them.

To set up backups, you need to configure two key components: a backup target and a backup policy.

  • A backup target is the storage location where your backups will be saved. This could be an S3-compatible storage system that ensures your data is safe, accessible.
  • A backup policy defines the rules for when and how backups are created, retained, and managed. This includes scheduling, retention periods, and handling backup failures.

The Restic tool plays a crucial role in managing backups. It minimizes storage usage through deduplication, ensures data security with encryption, and verifies the integrity of your backups.

To Create a New Backup Target

  1. On the left side of the page, in the navigation drawer under the Cloud Admin subgroup, click Backups.
    windows
  2. Open the TARGETS tab. Then, click ADD BACKUP TARGET on the top bar.
  3. Enter the S3 configuration details. More details can be found in the S3 Backup Guide.
  4. Provide a name for the backup target and set a Restic password, which will be used to manage Restic.
  5. Click SUBMIT.

Important: Always securely store your Restic password. Losing this password will result in permanent loss of access to your backups.

Assign a Location to a Backup Target

To start backing up virtual machines (VMs) in a specific location, you need to link the location to a backup target.

  1. Go to the backup target's details page and click SUBSCRIBE LOCATION at the top.

  2. Choose the location you want to associate with the backup target.

  3. Once you've selected the location, pick a cloudspace that will be used to manage and access the backups by the target.

  4. Click SUBMIT.

Backup Policy defines how backups are scheduled, retained, and managed.

To Create a New Backup Policy

  1. On the left side of the page, in the navigation drawer under the Cloud Admin subgroup, click Backups.

  2. Open the POLICIES tab. Then, click ADD BACKUP POLICY on the top bar.

  3. Configure the Snapshot Policy:

  4. Cooperative Mode (cooperative): Enable or disable cooperative backup mode.

  5. Cooperative Timeout (cooperative_timeout): Set the timeout duration for cooperative backups.
  6. Failure Behavior (cooperative_failure_behaviour): Choose the action to take on failure (e.g., FAIL).
  7. Timeout (timeout): Set the overall backup process timeout.
  8. Retry Pause (retry_pause): Define the wait time between retry attempts.

  9. Retry Times (retry_times): Specify how many times the backup should retry on failure.

  10. Configure frequency & retention policy:

  11. Schedule (cron): Define the backup frequency using a cron expression. (You can either enter a custom cron expression or choose a frequency from a dropdown list)

  12. Retention Flags (restic_retention_flags): Specify Restic retention rules for managing old backups. (You can either enter a custom restic retention flags expression or choose a retention frequency from a dropdown list) For more details: Restic Retention Flags Guide.

  13. Failure Report Email (failure_report_email): Provide an email address to receive failure notifications.

  14. Provide a name for the policy.

  15. Click ADD POLICY.

Backup Settings

Backup Settings determine how backup policies and targets are managed for each location on whitesky.cloud BV.

Cloud Admin Controls

The Cloud Admin has the ability to configure the following settings for each location:

  • Customer Permissions: Decide whether customers are allowed to define their own backup policies and targets. If disabled, only the Cloud Admin can create and manage backup policies and targets.
  • Mandatory Backup Policies: Enforce a rule requiring all newly created VMs in this location to have at least one backup policy assigned at the time of creation.

Sizing Backup Workers

A backup worker is the compute instance that runs Restic to read the virtual machine's virtual disks (vDisks), deduplicate and encrypt the data, and stream it to the backup target. How you size a worker determines both how reliably backups complete and how fast they run.

The default worker is 1 vCPU, 1 GiB of RAM, and 2000 IOPS. This is a sensible starting point for small VMs, but it is not enough for larger workloads.

What drives worker sizing

  • Memory (RAM) is the most important factor. Restic keeps its deduplication index in memory while a backup runs, and the index grows with the total amount of data being processed. If a worker runs out of memory, the backup fails rather than slowing down — so RAM is the resource to increase first when backing up large vDisks.
  • vCPUs determine throughput. Restic uses CPU for compression, encryption, and deduplication, so more vCPUs mean faster backups, especially for large or frequently changing disks.
  • IOPS control how quickly the worker can read from the source vDisks and write to the S3 target. Low IOPS becomes the bottleneck on large or busy disks.

The main input to sizing is the size of the vDisks being backed up. Use the largest single vDisk (or the combined size when one worker backs up several disks) to pick a row from the matrix below.

vDisk size (largest / combined) vCPUs Memory (RAM) IOPS
Up to 100 GiB 1 1 GiB (default) 2000
100 GiB – 500 GiB 2 2 GiB 3000
500 GiB – 1 TiB 2 4 GiB 5000
1 TiB – 2 TiB 4 8 GiB 7500
2 TiB – 4 TiB 4 16 GiB 10000
More than 4 TiB 8 16–32 GiB 15000+

Note: These are general best-practice recommendations. Actual requirements also depend on how much data changes between backups, how many VMs a single worker handles, and how many backups run at the same time.

Best practices

  • Start from the default and scale up. Begin with 1 vCPU / 1 GiB for small VMs and move up one tier if backups are slow or fail.
  • Increase RAM first when backups fail. An out-of-memory worker is the most common cause of failed backups for large vDisks.
  • Increase vCPUs and IOPS to make backups faster. If backups complete but run too long, add vCPUs and raise IOPS before adding more memory.
  • Spread the load across multiple workers. Rather than sizing one very large worker to cover many VMs, create additional workers so backups can run in parallel and a single failure has a smaller impact.
  • Re-check sizing as data grows. vDisks and change rates grow over time — revisit worker sizing periodically and after adding large VMs.