In this article:
Backup service allows you to automate the creation of instance backups. Backups are created on schedule defined by a user and retained for a predetermined period. If necessary, you can create an instance from an existing backup as per specified date in a couple of clicks.
Agent solution — Backup service using third-party agents.
Resource selection — Set of resources to which a certain backup plan is applied to.
Job — Backup job is automatically created according to the a user-defined schedule.
Protected resource — Resource for which there is at least one backup.
Backup window — Period of time within which an instance snapshot should be made for backup to be created.
Plan — The plan defines backup rules and resources to which these rules are applied to.
Rule — The backup rule sets backup frequency and window, as well as the backup valut and retention period.
Recovery point (— Backup of an instance created from a snapshot according to the backup plan.
Backup frequency — Schedule against which backup is done.
Vault — Logical container where backups are retained.
The service ensures efficient backup storage. First time, all the data are backed up, but all subsequent backups are incremental. In other words, only changes in data relative to the previous backup are saved.
This enables better data protection whuke reducing the expenses on data retention. Thus, backups are billed depending on disk space backups actually take.
Reliable backup storage#
Backups are placed in a dedicated storage system separately from volumes of instances. In addition, instance backups from one availability zone are placed in another availability zone.
Backups are impossible to modify. Their content cannot be modified after creation. To avoid undeliberate data loss, the backups you delete manually stay available for up to five days (for details see the Backup deletion policy section).
Backups are additionally protected thanks to the vault isolation from instances. For example, if you delete a protected instance, the backups themselves will remain intact and be retained according to the selected retention plan. To ensure maximum data protection, the vault is safely isolated from external impacts.
Only users with Backup Administrator or Backup Operator roles can access the Backup section to view information and manage backups. The first role provides all the privileges to handle backups, while the second, unlike it, does not allow you to delete backups.
Backups are automatically encrypted. Every vault has its own encryption key.
Backup deletion policy#
Backups are deleted as soon as their retention period expires. You can also delete them manually, but in order to minimize the consequences of potential cyber threats, we strongly recommend you not to provide users with the privilege to delete them (not to assign the Backup Administrator role) and control backup deletion by setting a retention period.
You can delete backups only in the Recovery Points section. You cannot delete images and snapshots corresponding to a backup.
When it is deleted manually, in fact the backup is not deleted straight away. The service is implemented so that the backup cannot be deleted right away. This solution helps avoid data loss caused by cyberattacks and any user’s actions whether deliberate or undeliberate.
When a backups is deleted manually, it is labelled as Being deleted and is retained for 5 days more, or until the specified deletion date, if less than 5 days remain before it. As long as the backup is in the Being deleted state, instances can still be created from it.
To ensure consistency of the created backups, the service uses QEMU Guest Agent, which must be installed on the guest OS beforehand.
When running a backup job, a command to freeze I/O is sent to QEMU Guest Agent. On Linux, the agent runs
fsfreeze by default, which ensures file system consistency. On Windows, it calls Volume Shadow Copy Service (VSS) for this purpose, which also ensures data consistency for VSS-compatible applications.
To ensure application data consistency on Linux, you can use custom tools for additional preparation of your application before the file system is frozen. Such preparation allows you to make snapshots in which application data is consistent.
20 seconds are allocated to perform interrupts and freeze the file system. A snapshot will be made either way regardless of freezing status and whether the agent is responding. The following options are possible.
The agent is not installed, or there is an error connecting to the agent
Freezing completed successfully within 20 seconds
Freezing will take no more than 20 sec 1
Instance in the Stopped state
In this case unfreezing is forced.
As soon as the snapshot is created, operating system is unfreezed by sending a corresponding command to the agent.
To learn more about QEMU Guest Agent installation and settings, see the instruction.
Plans and rules application peculiarities#
Backup in accordance with a specific backup plan can be performed no more than once an hour.
If at some point within the backup window, one or more rules of the same plan overlap, the rule with a larger backup retention period will be performed. If retention periods are the same, an arbitrary rule will be selected.
For example, two rules are specified:
backup should run at 00 hours daily, backup window is 1 hour, backup retention period is 7 days.
backup should run at 30 minutes past every hour, backup window is 1 hour, backup retention period is 1 day.
These two rules overlap daily at 00:30, as the backup window of the fists rule is 00:00-01:00, while the second is 00:30-01:30. In this case backup will run against the first rule as it provides for a larger retention period. A backup job against the second rule will not be created at 00:30, but it will start at the following hours, i.e. at 01:30, 02:30, etc., provided there is no overlapping with other rules.
The same instance can be included into different backup plans. If an instance is backed up while a new job for backing up this instance starts according to this plan or a different one, then the new job will be postponed until the current job is completed. If the earlier job is not completed before closing the backup window specified in the rule according to which the later job started, the later job will not run.
Postponing snapshot creation#
Backup process involves the creation of snapshots of protected resources. Snapshots can be taken at any point in time within the backup window, depending on the current utilization of the server infrastructure and whether there are other jobs for backing up the resource.
Snapshots are made as soon as the window opens, provided there are no other jobs for backing up this resource (for details see the previous page). In this case it is possible that a snapshot will not be made within the available timeframe and no backup will be made.
The beta-version of the backup service has the following constraints:
1 backup vault per project;
5 plans per project;
5 rules per plan;
5 resource selections per plan;
20 unique instances in all resource selections.
The same instance can be included into different resource selections and backup plans, but the total number of unique reserved instances cannot be more than 20. This quota is applied during the service beta-testing after which it will be increased.
The backup retention period is limited to 30 days while the service is under beta-testing.
If necessary, you can increase quotas. To do this, contact the support service.