Backup and Restore in Amazon Web Services

When determining your backup strategy, consider the following:

Account for the following areas of your Nexus Repository deployment when creating a backup strategy:

Although you back up these areas independently, plan the database and blob store backups to occur at approximately the same time to minimize differences between their recovery points.

As you review the backup strategies in the following sections, consider the following recovery objectives:

You can configure Amazon’s Relational Database Service (RDS) to automatically snapshot RDS instances as frequently as every 5 minutes; you can also create a manual snapshot on demand. It is important to configure the retention policy for these snapshots to meet your data retention requirements.

RDS provides a mechanism for restoring to a specific point in time. Depending upon the nature of the incident, you may still be able to recover Nexus Repository content (not configuration) added after the incident using the data repair tasks.

You can also configure RDS to replicate backup snapshots to a distinct region automatically. This allows you to restore Nexus Repository to a secondary AWS region in the event of a complete failure of the deployed region. When using this replication, you must replicate the blob storage to the same region as the RDS backup.

Snapshots of an RDS instance are associated with that instance. In some scenarios, the snapshots may be deleted automatically when an RDS instance is removed. To avoid this, you should periodically export database snapshot data to S3. These exported snapshots are also important should access to the database be maliciously compromised.

The backup strategy for blob storage depends on the storage service used by your deployment. See Sonatype Nexus Repository System Requirements for more information.

Use AWS backup capabilities to protect the file system data required by Nexus Repository.

If using EBS, point-in-time snapshots can help provide multi-AZ redundancy. While EBS only uses one AZ, it stores snapshots in multiple AZs. In the event of an AZ failure, you could use EBS snapshots to provision a new EBS volume in another AZ. However, this is not automatic. You will need to implement a process such as specifying the EBS snapshot ID in the EC2 launch configuration. See the AWS documentation for more information. Amazon EBS also offers a higher durability volume type (i.e., io2), that is designed to provide 99.999% durability with an annual failure rate (AFR) of 0.001%, where failure refers to a complete or partial loss of the volume.

Amazon EFS Standard is inherently designed to protect against losing an entire AZ.

The table below outlines various recovery methods and the RPO and RTO you can expect to achieve given your selected database, blob storage, and file system.