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.
A server’s backup is a copy of the server’s disk only. A backup does not contain the server’s configuration.
Backups in SolusVM 2.0 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¶
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.
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.
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.
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.0 stores backups that exceed the backup limit until the whole backup chain goes beyond the backup limit. Then SolusVM 2.0 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.0 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:
- Add a server to store them. We call this server a backup node. You can add any number of backup nodes.
- 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:
- Go to Backups > Backup Nodes and click Add Backup Node.
- Give your node a recognizable name.
- Select one or more compute resources whose servers you want to back up.
- Specify the hostname or IP address of a server that you want to add as a backup node.
- Keep the default 22 SSH port or specify a custom one (if any).
- Provide the SSH login and SSH private key.
Specify the path where backup files will be stored.
To specify several paths, add the same server as a backup node several times specifying one path for each case.
The backup node was added.
Now you need to enable the backup feature in a plan's settings.
To enable the backup feature:
- Go to Compure Resources > Plans and add a new plan or edit an existing one.
- Select "Offer backups" and specify the backup price.
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.
You can later customize the backup limit for each server created according to the plan.
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>.
You've set up everything necessary for backups. You and your users can now back up and restore servers.
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.
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:
- Go to Virtual Servers, click the hostname of the server that you want to back up, and then go to the "Backups" tab.
- Turn on "Backups" and then click Enable.
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.
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.
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¶
One server is backed up to one backup node at a time. Several backup are queued and the first tasks to come are processed first. The process of moving backups to backup nodes depends on your configuration:
- If one backup node has multiple compute resources attached, backups will be added to the backup node one by one.
- If multiple backup nodes have one compute resource attached, only one backup node of all the nodes will be chosen to store backups. No backup load balancing exists at the moment.
Backup restoration overwrites all data stored on the server with those stored in a backup.
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:
- Go to Virtual Servers, click the hostname of the server whose backup you want to restore, and then go to the "Backups" tab.
- 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.
This irrevocably deletes a backup from the backup node where it is stored.
You as the SolusVM 2.0 administrator can delete backups manually or have them rotated and deleted automatically.
SolusVM 2.0 automatically deletes backups if you’ve selected the backup limit in the corresponding plan:
- If you offer only full backups, SolusVM 2.0 will automatically delete the oldest backup that exceeds the limit.
- If you’ve enabled incremental backups, SolusVM 2.0 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.
Users can’t delete any backups.
To delete a backup manually:
- Go to Virtual Servers, click the hostname of the server whose backup you want to delete, and then go to the "Backups" tab.
- Click the icon next to the backup you want to delete.
- Confirm deleting the individual backup or the whole backup chain by clicking Delete.
Differences Between Backups and Snapshots¶
SolusVM 2.0 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:
|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. Backups are not incremental.||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.|