Backup#

General information#

Backup service allows you to automate the creation of instance and volume backups. Recovery points are created on schedule defined by a user and retained for a predetermined period. If necessary, you can create the required resource from an existing recovery point as per specified date in a couple of clicks.

При резервном копировании экземпляров из резервной копии можно исключить отдельные диски, кроме системного. Эта возможность полезна, например, когда на одних дисках хранятся статичные данные, а на других — часто меняющиеся.

In addition to its own service for instance backup, K2 Cloud also offers database backup and agent-based backup service.

Key concepts#

  • 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 a resource snapshot should be made for the recovery point 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 vault and retention period.

  • Backup — A copy of the resource content made at a particular point in time.

  • Backup frequency — Schedule against which backup is done.

  • Vault — Logical container where recovery points are retained.

Reliable backup storage#

Recovery points are placed in a dedicated storage system separately from volumes. In addition, resource’s recovery points from one availability zone are placed in another availability zone.

Recovery points 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).

Recovery points are additionally protected thanks to the vault isolation. For example, if you delete a protected resource, the recovery points 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 specific privileges (for example, those from BackupAdministrators or BackupOperators groups) can access the Backup section to view information and manage backups. The first group provides all the privileges to handle backups, while the second, unlike it, does not allow you to delete recovery points.

Recovery points 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 to control backup deletion by setting a retention period and not to provide users with the privilege to delete them (not include them to the BackupAdministrators group and not grant similar privileges).

Note

You can delete recovery points only in the Recovery Points section. You cannot delete images and snapshots corresponding to a recovery point.

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 Deleting state, the protected resource (instance or volume) can still be created from it.

Backup consistency#

Data consistency can be ensured at different levels:

  • file system;

  • application.

In the first case, consistency means that all file system data and metadata are saved to a volume and there are no pending write operations. In the second case, application data that may be in memory is saved to a volume and new write operations are suspended.

When an instance snapshot or its volume snapshot is made, the data can be in one of four states, from the consistency perspective:

  • File system and application data are not consistent. Both the file system and the application had data in memory at the time the snapshot was created, therefore the snapshot doesn’t contain them.

    When creating a volume from such a snapshot, the OS will first determine that the file system was not consistent and restore it to the most recent consistent state. The application can then detect that its data is not consistent, which is worsened by the fact that the file system itself was not consistent at the time of the snapshot. The application (for example, database) will recover the data by rolling it back to the time of the last consistent data state using the log.

  • The file system data is consistent, but the application data is not consistent. In this case, the file system will not start the recovery process, though the snapshot may lack some recent application data.

  • The file system data is not consistent and the application data is consistent. The application has written its data, but the file system failed to save it to the volume or had not enough time to do so. Practically, this is the most rare case, because most applications force data synchronization so that the file system writes data to volume immediately.

    If the file system is not additionally synchronized, the application data in the volume will probably be intact, but the file system may still start the recovery process at the next mounting because other applications’ data may have remained in memory and was not forced to be written to the volume.

  • Both the file system and application data are consistent. In this case, first the application writes all data in a forced manner to the volume and suspends new write requests, and then the file system synchronizes its state with the volume and also suspends further writing.

To ensure consistency of the created recovery points at the file system level, the service interacts with 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 consistency for the file system only. On Windows, it calls Volume Shadow Copy Service (VSS) for this purpose, which also ensures data consistency for VSS-compatible applications.

Attention

When an individual volume is backed up, no I/O freezing occurs. Therefore, the backup copy may be inconsistent when the volume is attached to a running instance.

To ensure application data consistency in Linux, you can set additional hooks to prepare your application and write its data to volume before freezing the file system. This will provide snapshots in which both file system data and application data are 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.

Communication status

Snapshot consistency

The agent is not installed, or there is an error connecting to the agent

Inconsistent

Freezing completed successfully within 20 seconds

Consistent 1

Freezing will take no more than 20 sec 2

Inconsistent

Instance in the Stopped state

Consistent
1

This status means that the agent has confirmed successful freezing of the file system or the snapshot was taken when the instance was stopped. In any case, the cloud does not know whether the application data is consistent or your own hook execution is successful.

2

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 resource can be included into different backup plans. If the resource is backed up while a new backup job starts according to this plan or a different one, then the new job will be postponed until the current job is completed.

A later job will not run if the earlier job is not completed before closing the backup window specified in the rule according to which the later job started.

Note

When both the instance and an attached volume are to be backed up at the same time, the instance backup will have priority if neither job has started yet. If one of the jobs is already running, the second one will be postponed until the first job is completed.

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 backup jobs for this resource (for details see the previous page). If there are backup jobs, it is possible that a snapshot will not be made within the available timeframe and no recovery point will be created.

Usage restrictions#

The backup service is subject to 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;

  • 20 unique volumes in all resource selections.

Note

The same instance or volume can be included into different resource selections and backup plans, but the total number of unique reserved resources of the same type cannot be more than 20.

If necessary, you can increase quotas. To do this, contact the support service.