Skip to content

Backing up and Restoring Servers

To help prevent data loss, you and your users can back up and restore servers.

In this topic, you'll learn how to do the following:

  • Set up the backup feature.
  • Create scheduled and manual backups.
  • Limit the number of backups users can store.
  • Enable incremental backups for the ThinLVM storage type.
  • Restore backups.
  • Delete backups automatically or manually.

Note

A server’s backup is a copy of the server’s disk only. A backup does not contain the server’s configuration.

Danger

Backups in SolusVM 2 can't protect you from accidental deletion of servers and compute resources. Deleting a server automatically deletes all server’s backups. Deleting a compute resource automatically deletes compute resource’s servers and the servers' backups.

Differences Between Full and Incremental Backups

Note

Incremental backups are available only for plans with the ThinLVM storage type.

A full backup is a copy of the whole server disk without its configuration. An incremental backup contains only the data that has changed since the last backup date.

Compared to full backups, incremental ones have their advantages:

  • They save disk space.
  • They generally take less time to be created.

    Note

    It’s not always true if, for example, a server disk accumulated a large number of changes since the last backup.

However, incremental backups also have disadvantages. They take more time to be restored, and it is easier to accidentally lose the possibility to restore them.

If, after you weighed up the pros and cons, you’ve decided not to use incremental backups, you can stop reading here and move on to setting up the backup feature.

If you’ve decided to enable incremental backups, let’s dig deeper in how they function. This information will be useful when you enable incremental backups in a plan.

Backup Chain

Full backups are independent of each other and restored individually.

When you enable incremental backups, you get a sequence of backups dependent on each other. We call this sequence a backup chain. Each backup chain starts with a full backup and includes one or more incremental backups. The number of backups in a chain is its length. On the picture below, the chain length is four.

Each incremental backup depends on the previous incremental one and on the full backup that starts the chain. If any of the previous backups in the chain are lost or damaged, you’ll lose the ability to restore from subsequent incremental backups. Backup chains, especially long ones, are fragile. We recommend that you keep them short by setting backup limits.

Backup Limit

When enabling backups in a plan, you can set the limit of backups a user can have per server. This limit includes all types of backups: manual, scheduled, full, and incremental (if any).

If you offer only full backups, the backup limit matches the number of backups a user sees in the User interface and the number of backups stored on a backup node.

When you enable incremental backups, the following things happen:

  • The unlimited number of backups becomes unavailable. This prevents unlimited backup chains, which isn't reliable.
  • Another setting appears: the number of incremental backups for each full backup. This number matches a backup chain length minus one.
  • The backup limit is no longer as straightforward as with full backups only.

With enabled incremental backups, the backup limit operates differently. It still matches the number of backups a user sees in the User interface but no longer matches the actual number of backups stored on a backup node. It happens because it’s not possible to delete a single incremental backup without breaking a backup chain.

SolusVM 2 stores backups that exceed the backup limit until the whole backup chain goes beyond the backup limit. Then SolusVM 2 deletes the whole backup chain from a backup node.

All of this happens under the hood. Users don’t see any difference between full and incremental backups in the User interface. They also don’t know that they have some backups stored on a backup node beyond the backup limit.

However, you as the SolusVM 2 administrator see the actual number of backups stored on a backup node both in the Administrator and User interfaces.

Setting up the Backup Feature

Before you and your users can start creating backups, you need to do the following:

  1. Add a server to store them. We call this server a backup node. You can add any number of backup nodes.
  2. Enable the backup feature in a plan's settings. You and your users can back up only those servers that have been created under a plan with enabled backups.

A backup node must meet the following requirements:

  • Installed rsync.
  • Firewall rules must allow connections to the backup node’s SSH port from the management server and compute resources.
  • Enough disk space to store backups. You can roughly estimate the minimum necessary disk space using the following formula:

    A number of servers × server disk space × 8 (the allowed number of backups per server + 1)

To add a backup node:

  1. Go to Backups > Backup Nodes and click Add Backup Node.
  2. Give your node a recognizable name.
  3. Choose Backup Node type. Currently supported backup node types are:

    • SSH server

    • Hetzner Storage Box

    • S3 storage which can be an AWS S3 or any generic S3 storage

  4. Select one or more compute resources whose servers you want to back up.
  5. Specify the hostname or IP address of a server that you want to add as a backup node.
  6. Keep the default 22 SSH port or specify a custom one (if any).
  7. Provide the SSH login and SSH private key.
  8. Specify the path where backup files will be stored.

    Note

    To specify several paths, add the same server as a backup node several times specifying one path for each case.

  9. Click Save.

The backup node was added.

Now you need to enable the backup feature in a plan's settings.

To enable the backup feature:

  1. Go to Compute Resources > Plans and add a new plan or edit an existing one.
  2. Select "Offer backups" and specify the backup price.
  3. You can set the backup limit: the maximum number of backup files users can store (including full, incremental, scheduled, and manual backups).

    Keep the default limit as it is, change it, or choose not to limit the number of users' backups by selecting "Unlimited". Your choice depends on the estimated number of future servers, the number of backup nodes, and their disk space.

    Note

    You can later customize the backup limit for each server created according to the plan.

  4. If the plan has the ThinLVM storage type, you can also enable incremental backups by selecting the corresponding checkbox. If you enable incremental backups, you'll need to limit their number for each full backup. We recommend that you keep the default value of three.

    Increasing this value will increase the time necessary to restore backups and make the restoration less reliable. If you want to enable incremental backups, we recommend that you first :ref:read about a backup chain and backup limit <backup-chain>.

  5. Click Save.

You've set up everything necessary for backups. You and your users can now back up and restore servers.

Creating Backups

You and your users can create both scheduled and manual backups. You can back up manually at any time or you can schedule backups to be created automatically and periodically.

Note

All new servers have the backup feature turned off by default. You and your users turn it on individually for each server.

To back up a server:

  1. Go to Virtual Servers, click the hostname of the server that you want to back up, and then go to the "Backups" tab.
  2. Turn on "Backups" and then click Enable.
  3. Choose how to create a backup:

    • To schedule a backup, click "Schedule settings" and select how often and when backups will be created. If you're not satisfied with the backup limit of the plan, you can customize it for the server.

      When the limit is exceeded, backups are automatically rotated. See more information about backup rotation.

      Once you've finished with schedule setting, click Save Changes. Backups will now be created regularly at the specified time and frequency.

      Note

      To prevent data loss and get peace of mind, we recommend that you schedule backups.

    • To create a manual backup, click Create Backup. Backing up will start right away if no previous backup tasks are in the queue.

Created backups will be shown in the list.

Note

Users schedule backups in the user interface (go to Projects, click "…servers", click the name of the server for which you want to schedule backups, and then go to the "Backups" tab). At the moment, users can create manual backups only via the API.

Backup Tasks Processing

The backup node and compute resources have settings to set the number of concurrent backup operations, namely backup creation and restoration.

The default values of these settings are 1. It means that one backup node can process one backup creation and one restoration at a time. And a compute resource can do the same. With the default settings, the backup process happens the following way depending on your configuration:

  • If multiple backup nodes have one compute resource attached, only one backup node of all the nodes will be chosen to store backups.
  • If one backup node has multiple compute resources attached, backups will be added to the backup node one by one.

By changing the default settings, you can specify the exact number of backup operations to be run simultaneously. However, to determine this number, you need to take into account the following:

  • You configuration: if one backup node has multiple compute resources attached, or multiple backup nodes have one compute resource attached.
  • The number of servers deployed on a compute resource.
  • The ratio between the management node and compute resource settings.

Let's have a closer look at the settings using the following example.

The number of concurrent backups for the management node is 3 for backup creation and 3 for restoration. The number of concurrent backups for a compute resource attached to the management node is 3 for backup creation and 1 for restoration. The compute resource has 4 deployed servers.

In this case, it is possible to back up only 3 servers at a time, because the management node setting for backup creation (3) is less than the number of servers (4). The fourth server backup will be queued until the previous backup tasks are finished. At the same time, it is possible to restore only one server. Although the management node setting allows 3 concurrent restoration tasks, the compute resource setting allows only one. To be able to restore all 4 servers at a time, change the values of the management node and compute resource settings to 4.

Note

Backup creation and restoration can be concurrent regardless of the value of the settings.

Note

If you specify large values for the settings (for example, 100 concurrent backup operations), make sure that the system bandwidth supports it. Otherwise, backup restoration and creation may fail.

Restoring Backups

Backup restoration overwrites all data stored on the server with those stored in a backup.

Warning

A server with the qcow2 image format loses its snapshots after being restored from a backup. It happens because of the way snapshots are implemented for qcow2.

To restore a backup:

  1. Go to Virtual Servers, click the hostname of the server whose backup you want to restore, and then go to the "Backups" tab.
  2. Click the icon next to the backup you want to restore and then click Restore.

Restoring a backup usually takes one minute to start. Restoring tasks are processed one after another, one restoring task at a time.

Deleting Backups

This irrevocably deletes a backup from the backup node where it is stored.

You as the SolusVM 2 administrator can delete backups manually or have them rotated and deleted automatically.

SolusVM 2 automatically deletes backups if you’ve selected the backup limit in the corresponding plan:

  • If you offer only full backups, SolusVM 2 will automatically delete the oldest backup that exceeds the limit.
  • If you’ve enabled incremental backups, SolusVM 2 will automatically delete the whole backup chain (the full backup and its related incremental backups) once the last backup of the chain goes beyond the backup limit.

You can also delete backups manually but with the following limitations:

  • You can’t delete individual incremental backups.
  • You can delete the following:

    • Any full backup that doesn’t start a backup chain
    • A whole backup chain: the full backup and its related incremental backups.

Note

Users can’t delete any backups.

To delete a backup manually:

  1. Go to Virtual Servers, click the hostname of the server whose backup you want to delete, and then go to the "Backups" tab.
  2. Click the icon next to the backup you want to delete.
  3. Confirm deleting the individual backup or the whole backup chain by clicking Delete.

Differences Between Backups and Snapshots

SolusVM 2 offers two ways to copy servers and prevent data loss: to create backups and to create snapshots. Although backups and snapshots serve more or less the same purpose, they have differences, which you can see in the table below:

Parameter Backups Snapshots
Migration a virtual server between Compute Resources Virtual server which have backups can be migrated between compute resources. Virtual server which have snapshots can't be migrated between compute resources.
Saved data The server’s disk copy (without configuration). The server’s disk copy (without configuration) for all snapshots except qcow2. (qcow2) The server’s disk copy and memory state.
Storage place Backup node. Compute resource for all snapshots except qcow2. (qcow2) Compute resource and the snapshot server’s disk file.
Creation speed Varies greatly from minutes to hours. Depends on a backed up server disk size, HDD speed, and network speed. Almost instant.
Consumed disk space The server’s disk space. Less than the server disk space for all snapshots except the first one. Snapshots are incremental.
Enabling Turned on individually for each server. Turned on for a plan.
Ways to lose Delete the backup node. Delete a backed up server. Delete the compute resource. Delete the compute resource. (qcow2) Delete the snapshot server’s disk file.
Back to top