Resources backup process

This document describes what kind of operations are performed by AutoBackup in order to make backups of different types of resources. We hope that it will help to understand how to configure backup setups correctly and realize limitations imposed by cloud providers.

AWS

This section provides a description of backup operations performed on supported AWS and AWS China resources types.

EC2 instances

In order to make backup and replication of an EC2 instance, the following operations are performed by AutoBackup:

snapshots of EBS volumes attached to the EC2 instance are created in the protected account,
if replication is enabled, snapshots are copied to the vault account into a region specified by a backup setup assigned to the backed up EC2 instance,
if sharing snapshot back is enabled, snapshots replicas are shared with protected account.

AutoBackup allows sharing EC2 instance's EBS volumes snapshots replicas with the protected account to make restoring from replicas easier in protected account. Sharing snapshots back with the protected account is not performed by default. To enable this functionality you must explicitly enable Share snapshot back option in a backup setup assigned to an EC2 instance. It is important to note that the shared snapshots will be visible in a protected account in a region where replicas are stored. For example, if you have an EC2 instance in eu-west-1 region, and you replicate its EBS snapshots to the eu-central-1 region, then the shared back EBS replicas will be visible in the protected account in eu-central-1 region. To restore a shared snapshot in the protected account, first, you must copy it from the vault account to the protected account. If a shared snapshot which you want to copy or restore is encrypted, make sure that the policy of the KMS key used for encryption grants access for using that key for data decryption by the protected account.

Encryption

If an EBS volume attached to an EC2 instance was encrypted, then snapshots taken in protected account will be automatically encrypted by the same KMS key as the original volume. While copying to the vault account, encryption can be forced by enabling Force encryption of unencrypted resources replicas setting in a backup setup associated with the backed up EC2 instance. The snapshot replica will be encrypted by KMS key identified by alias specified in Replicas encryption KMS key alias backup setup setting. Note that the KMS key with the specified alias must be present in a replication region and its policy must allow AutoBackup role to use it.

Please also note that it's not possible to copy to another account a snapshot which was encrypted using KMS key managed by AWS. In such case, an additional, temporary copy of snapshot must be created in protected account and encrypted using a key specified by Default KMS key replacement backup setup setting. For EC2 the key specified by Default KMS key replacement backup setup setting must be present in protected account, in the same region as backed up EC2 instance.

If an EBS volume in protected account is not encrypted, then a snapshot taken in protected account also won't be encrypted. Unencrypted snapshots' replicas can still be encrypted with KMS key while copying to the vault account, depending on the Force encryption of unencrypted resources replicas setting.

Creating and setting KMS key policies is not part of AutoBackup system. They should be created by a user.

EBS volumes

In order to make backup and replication of an EBS volume, the following operations are performed by AutoBackup:

snapshot of backed up EBS volume is created in the protected account,
if replication is enabled, the snapshot is copied to the vault account into a region specified by a backup setup the backed up EBS volume,
if sharing snapshot back is enabled, snapshot's replica is shared with protected account.

AutoBackup allows sharing EBS volume snapshot's replica with the protected account to make restoring from replica easier in protected account. Sharing snapshot back with the protected account is not performed by default. To enable this functionality you must explicitly enable Share snapshot back option in a backup setup assigned to an EBS volume. It is important to note that the shared snapshot will be visible in a protected account in a region where replicas are stored. For example, if you have an EBS volume in eu-west-1 region, and you replicate its snapshots to the eu-central-1 region, then the shared back EBS replicas will be visible in the protected account in eu-central-1 region. To restore a shared snapshot in the protected account, first, you must copy it from the vault account to the protected account. If a shared snapshot which you want to copy or restore is encrypted, make sure that the policy of the KMS key used for encryption grants access for using that key for data decryption by the protected account.

Encryption

If a backed up EBS volume was encrypted, then snapshots taken in protected account will be automatically encrypted by the same KMS key as the original volume. While copying to the vault account, encryption can be forced by enabling Force encryption of unencrypted resources replicas setting in a backup setup associated with the backed up EBS volume. The snapshot replica will be encrypted by KMS key identified by alias specified in Replicas encryption KMS key alias backup setup setting. Note that the KMS key with the specified alias must be present in a replication region and its policy must allow AutoBackup role to use it.

Please also note that it's not possible to copy to another account a snapshot which was encrypted using KMS key managed by AWS. In such case, an additional, temporary copy of snapshot must be created in protected account and encrypted using a key specified by Default KMS key replacement backup setup setting. For EBS the key specified by Default KMS key replacement backup setup setting must be present in protected account, in replication region.

Creating and setting KMS key policies is not part of AutoBackup system. They should be created by a user.

RDS instances

In order to make backup and replication of an RDS instance, the following operations are performed by AutoBackup:

snapshot of backed up RDS instance is created in the protected account,
if replication is enabled, the snapshot is copied to the vault account into a region specified by a backup setup the backed up RDS instance,
if sharing snapshot back is enabled, snapshot's replica is shared with protected account.

AutoBackup allows sharing RDS instance snapshot's replica with the protected account to make restoring from replica easier in protected account. Sharing snapshot back with the protected account is not performed by default. To enable this functionality you must explicitly enable Share snapshot back option in a backup setup assigned to an RDS instance. It is important to note that the shared snapshot will be visible in a protected account in a region where replicas are stored. For example, if you have an RDS instance in eu-west-1 region, and you replicate its snapshots to the eu-central-1 region, then the shared back RDS instance replicas will be visible in the protected account in eu-central-1 region. To restore a shared snapshot in the protected account, first, you must copy it from the vault account to the protected account. If a shared snapshot which you want to copy or restore is encrypted, make sure that the policy of the KMS key used for encryption grants access for using that key for data decryption by the protected account.

Encryption

If a backed up RDS instance was encrypted, then snapshots taken in protected account will be automatically encrypted by the same KMS key as the original instance. While copying to the vault account, encryption can be forced by enabling Force encryption of unencrypted resources replicas setting in a backup setup associated with the backed up RDS instance. The snapshot replica will be encrypted by KMS key identified by alias specified in Replicas encryption KMS key alias backup setup setting. Note that the KMS key with the specified alias must be present in a replication region and its policy must allow AutoBackup role to use it.

Please also note that it's not possible to copy to another account a snapshot which was encrypted using KMS key managed by AWS. In such case, an additional, temporary copy of snapshot must be created in protected account and encrypted using a key specified by Default KMS key replacement backup setup setting. For RDS instances the key specified by Default KMS key replacement backup setup setting must be present in protected account, in replication region.

If an RDS instance in protected account is not encrypted, then a snapshot taken in protected account also won't be encrypted. Unencrypted snapshots' replicas can still be encrypted with KMS key while copying to the vault account, depending on the Force encryption of unencrypted resources replicas setting.

Creating and setting KMS key policies is not part of AutoBackup system. They should be created by a user.

RDS clusters

In order to make backup and replication of an RDS cluster, the following operations are performed by AutoBackup:

manual snapshot of RDS cluster is created in the protected account,
if replication is enabled, snapshot is copied to the vault account into a region specified by a backup setup assigned to the backed up RDS cluster,
if sharing snapshot back is enabled, snapshot's replica is shared with protected account.

AutoBackup allows sharing RDS cluster's snapshots replicas with the protected account to make restoring from replicas easier in protected account. Sharing snapshots back with the protected account is not performed by default. To enable this functionality you must explicitly enable Share snapshot back option in a backup setup assigned to an RDS cluster. It is important to note that the shared snapshots will be visible in a protected account in a region where replicas are stored. For example, if you have an RDS cluster in eu-west-1 region, and you replicate its snapshot to the eu-central-1 region, then the shared back RDS replicas will be visible in the protected account in eu-central-1 region. To restore a shared snapshot in the protected account, first, you must copy it from the vault account to the protected account. If a shared snapshot which you want to copy or restore is encrypted, make sure that the policy of the KMS key used for encryption grants access for using that key for data decryption by the protected account.

Encryption

If an RDS cluster was encrypted, then snapshots taken in protected account will be automatically encrypted by the same KMS key as the original database. The snapshot replica will be encrypted by KMS key identified by alias specified in Replicas encryption KMS key alias backup setup setting. Note that the KMS key with the specified alias must be present in a replication region and its policy must allow AutoBackup role to use it.

Please also note that it's not possible to copy to another account a snapshot which was encrypted using KMS key managed by AWS. In such case, an additional, temporary copy of snapshot must be created in protected account and encrypted using a key specified by Default KMS key replacement backup setup setting. For RDS clusters the key specified by Default KMS key replacement backup setup setting must be present in protected account, in replication region.

If an RDS cluster in protected account is not encrypted, then a snapshot taken in protected account also won't be encrypted. Unlike RDS instances and EBS volumes snapshots, unencrypted RDS clusters snapshots replicas can't be encrypted with KMS key while copying to the vault account. It means that RDS clusters snapshots replicas are encrypted if and only if backed up RDS cluster is encrypted.

Creating and setting KMS key policies is not part of AutoBackup system. They should be created by a user.

DynamoDB tables

In order to make backup and replication of a DynamoDB table, the following operations are performed by AutoBackup:

table snapshot is created in the protected account using AWS DynamoDB On-Demand Backup feature,
if replication is enabled, a temporary DynamoDB table is created from snapshot, then data from the temporary table is copied to S3 bucket in a vault account.

Replication performance tuning

DynamoDB Backup is using Replicas storing bucket name backup setup setting, to point an S3 bucket in vault account which will store table data in a vault account. Data from temporary DynamoDB table is copied to that bucket. Speed of replication can be tuned using Temporary DynamoDB table read capacity units backup setup setting. By default, when no specific number of read capacity units is provided in a backup setup, AutoBackup creates a temporary table with on-demand mode.

S3 buckets

In order to make backup of S3 buckets, AutoBackup uses native AWS cross-region/same-region replication to replicate objects. The AutoBackup doesn't make any snapshots in protected account. This implies that all objects present in bucket prior to enabling S3 Backup will NOT BE REPLICATED.

It is important to note, that in order for S3 Backup to work properly, backup setup setting named Replication enabled must be enabled.

After enabling S3 Backup, all changes to the bucket objects will be tracked and applied to the bucket in the vault account. Nothing will happen with objects present in a bucket before enabling S3. Only after enabling S3 Backup, adding new objects, modifying or deleting existing objects in original bucket, changes will be replicated to the bucket in the vault account, denoted by Replicas storing bucket name backup setup setting.

Limiting replication scope

By default, all objects stored in an S3 bucket are replicated. If this is not a desired behaviour, you can change it using Replicated prefixes backup setup setting to limit the replication scope only to objects with specified prefixes.

Replicated objects ownership

By default, all objects replicas are owned by an AWS account in which original bucket resides. In order to change this behaviour you can enable Override replica owner backup setup setting. When this setting is enabled, objects replicas ownership will be overridden and transferred to vault account.

Encryption

As stated in AWS documentation, by default, Amazon S3 doesn't replicate objects that are stored at rest using server-side encryption with AWS Key Management Service. In order to replicate encrypted objects, specify Replicas encryption KMS key alias backup setup setting and provide an alias of KMS key which will be used to encrypt replicas.

S3 backup events semantics

For S3 buckets, backup events have a special semantics. They define, when the Auto-Backup will check for changes of S3 bucket backup setup, describing desired replication settings. The retention settings have no impact on backup of S3 buckets, because during backup of those resources, no snapshots are created, hence there are no snapshots to remove.

Redshift

Redshift backup is done using AWS Redshift native manual snapshots' mechanism.

Configuring Redshift Backup

Redshift Backup does not require any special configuration, you just need to enable backup for it. Snapshots will be taken accordingly to meet RPO conditions defined by the backup policy.

Known limitations

replication of snapshots is not supported,
there is a default AWS limit of 20 manual snapshots per region in an account.

EFS

AutoBackup uses native AWS backup vaults for backup of EFS filesystems.

Backup using native AWS backup vaults

EFS snapshots are stored in the AWS backup vault in the protected account. The specific vault has to be chosen and specified in the Backup vault name setting of a backup setup assigned to an EFS resource. The snapshots are then created in the protected account inside the specified AWS backup vault. They are not replicated to vault account.

Replication to S3

Method deprecated - will be removed soon

AutoBackup can replicate EFS filesystem's contents to S3 bucket in vault account. In order to have replication to S3 working you must set the following backup setup settings:

Replicas storing bucket name
Subnet ID
Security group ID
ARN of an instance profile
Vault account id In order to perform replication, AutoBackup launches an EC2 instance using settings listed above, mounts the filesystem and the EC2 instance copies filesystem's contents to specified S3 bucket.

Replication to AWS Backup Vault

For currently onboarded accounts please update role definition (could be downloaded from the UI - Accounts page)

AutoBackup can replicate EFS primary snapshot to vault account. To perform this action Cross-account backup (in AWS Backup Settings) must be enabled and replica AWS Backup vault should have access policy that allows to copy snapshot from protected account to the vault. For more details please visit AWS documentation

Required permissions for PROTECTED account:

backup:StartCopyJob
backup:CopyIntoBackupVault
backup:CopyFromBackupVault

Required permission for VAULT account:

backup:DeleteRecoveryPoint

Access policy example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Allow PROTECTED account to copy into vault",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<protected account id>:root"
            },
            "Action": "backup:CopyIntoBackupVault",
            "Resource": "*"
        }
    ]
}

Route53

Route 53 backup is performed by making snapshots of the following components' configuration:

hosted zones,
health checks,
traffic policies and traffic policy instances.

The snapshots are stored in a special S3 bucket in the protected account. AutoBackup searches for a bucket with a name specified in Storing bucket name backup setup setting. Snapshots can be replicated to S3 bucket in the vault account. You can specify a bucket for storing replicas by providing a value for Replicas storing bucket name backup setup setting.

Encryption

Snapshots replicas can optionally be encrypted. In order to make encryption enabled, enable Force encryption of unencrypted resources replicas backup setup setting and provide a value for the Replicas encryption KMS key ARN or alias backup setup setting to specify an alias of KMS key which should be used to encrypt replicas. Make sure that KMS key is present in the same region as a bucket designated to store replicas. The KMS key policy must allow the key usage by AutoBackup role.

Azure

This section provides a description of backup operations performed on supported Azure resources types.

Azure VM

AutoBackup uses native Azure backup vaults mechanism in order to perform Azure VM backup. AutoBackup automatically creates required backup vault, sets up a policy and adds VM to the vault. When backup event occurs, AutoBackup uses manual backup job trigger in order to take snapshot.

Snapshots replication is fully managed by Azure. AutoBackup sets geo-redundant replication type for utilized backup vaults.

AutoBackup also does not control the retention process. Azure removes obsolete snapshots automatically.

Azure allows to take at most 1 snapshot per 12 hours. Users should be aware of it when they will be creating backup policies for Azure VMs.

Azure SAP HANA

Before you start:

all the prerequisites must be met,
a pre-registration script must be run on the SAP HANA machine. More information about what the script does, refer to the page,
to allow AutoBackup to distinguish normal Virtual Machine from the SAP HANA instance, make sure that this instance is tagged with following tag: <nc-backup-resource-type: sap-hana>

AutoBackup uses native Azure backup vaults mechanism in order to perform Azure SAP HANA backup. AutoBackup automatically creates required backup vault, sets up a policy, refreshes container, registers container and adds databases installed on the VM to the vault. When backup event occurs, AutoBackup uses manual backup job trigger in order to take snapshot.

Snapshots replication is fully managed by Azure. AutoBackup sets geo-redundant replication type for utilized backup vaults.

AutoBackup also does not control the retention process. Azure removes obsolete snapshots automatically.

Known limitations

For Azure SAP HANA retention will not be kept according to the attached policy (AutoBackup triggers snapshots manually to keep the RPO but the default retention for on-demand backup is 45 days - Azure documentation)

GCP

This section provides a description of backup operations performed on supported GCP resources types.

GCP VM

Primary backup is performed by saving metadata about a virtual machine and taking snapshots of all disks attached to the virtual machine. Identifiers of created snapshots are saved alongside with instance metadata.

GCP does not have a native mechanism for copying snapshots. In order to perform replication, AutoBackup must create disks images based on primary snapshots, share the images with vault account, create temporary disks in vault account and take snapshots of those temporary disks.

The user can specify the location of created snapshots. For both primary and replica snapshots, snapshots can be stored in a single region or in a multi-region. To configure Regional snapshots (Multi-region is default), use the appropriate options: Use Regional location for primary backup/replication.

IBM Cloud

This section provides a description of backup operations performed on supported IBM Cloud resources types.

IBM Cloud VM

Required permissions:

is.instance.instance.read
is.instance.instance.operate
is.volume.volume.read
is.volume.volume.operate
is.snapshot.snapshot.read
is.snapshot.snapshot.create
is.snapshot.snapshot.delete
global-search-tagging.tag.attach-user-tag
global-search-tagging.resource.read
resource-controller.instance.create

Primary backup is performed by saving metadata about a virtual machine and attached volumes, and taking snapshots of all volumes (boot and data volumes) attached to the virtual machine. Tags are propagated from volumes to theirs snapshots as user tags. Information about created snapshots are saved alongside with obtained metadata.

Resources backup process

AWS

.css-1r0pe6c{color:inherit;-webkit-text-decoration:none;text-decoration:none;}.css-1r0pe6c:hover{-webkit-text-decoration:underline;text-decoration:underline;}EC2 instances

Azure

GCP

IBM Cloud

EC2 instances