Overview of backing up and restoring a Neptune DB cluster
This section provides top-level information about backing up and restoring data in Amazon Neptune.
Topics
Fault tolerance for a Neptune DB cluster
A Neptune DB cluster is fault tolerant by design. The cluster volume spans multiple Availability Zones in a single Amazon Region, and each Availability Zone contains a copy of the cluster volume data. This functionality means that your DB cluster can tolerate a failure of an Availability Zone without any loss of data and only a brief interruption of service.
If the primary instance in a DB cluster fails, Neptune automatically fails over to a new primary instance in one of two ways:
By promoting an existing Neptune replica to the new primary instance
By creating a new primary instance
If the DB cluster has one or more Neptune replicas, then a Neptune replica is promoted to the primary instance during a failure event. A failure event results in a brief interruption, during which read and write operations fail with an exception. However, service is typically restored in less than 120 seconds, and often less than 60 seconds. To increase the availability of your DB cluster, we recommend that you create at least one or more Neptune replicas in two or more different Availability Zones.
You can customize the order in which your Neptune replicas are promoted to the primary instance after a failure by assigning each replica a priority. Priorities range from 0 for the highest priority to 15 for the lowest priority. If the primary instance fails, Neptune promotes the Neptune replica with the highest priority to the new primary instance. You can modify the priority of a Neptune replica at any time. Modifying the priority doesn't trigger a failover.
You can use the Amazon CLI to set the failover priority of a DB instance, as follows:
aws neptune modify-db-instance --db-instance-identifier(the instance ID)--promotion-tier(the failover priority value)
More than one Neptune replica can share the same priority, resulting in promotion tiers. If two or more Neptune replicas share the same priority, then Neptune promotes the replica that is largest in size. If two or more Neptune replicas share the same priority and size, then Neptune promotes an arbitrary replica in the same promotion tier.
If the DB cluster doesn't contain any Neptune replicas, then the primary instance is recreated during a failure event. A failure event results in an interruption during which read and write operations fail with an exception. Service is restored when the new primary instance is created, which typically takes less than 10 minutes. Promoting a Neptune replica to the primary instance is much faster than creating a new primary instance.
Neptune Backups
Neptune backs up your cluster volume automatically and retains restore data for the length of the backup retention period. Neptune backups are continuous and incremental so you can quickly restore to any point within the backup retention period. No performance impact or interruption of database service occurs as backup data is being written. You can specify a backup retention period, from 1 to 35 days, when you create or modify a DB cluster.
To control your backup storage usage, you can reduce the backup retention interval, remove old manual snapshots when they are no longer needed, or both. To help manage your costs, you can monitor the amount of storage consumed by continuous backups and manual snapshots that persist beyond the retention period. You can reduce the backup retention interval and remove manual snapshots when they are no longer needed.
If you want to retain a backup beyond the backup retention period, you can also take a
snapshot of the data in your cluster volume. Storing snapshots incurs the standard storage
charges for Neptune. For more information about Neptune storage pricing, see Amazon Neptune Pricing
Neptune retains incremental restore data for the entire backup retention period. So you only need to create a snapshot for data that you want to retain beyond the backup retention period. You can create a new DB cluster from the snapshot.
Important
If you delete a DB cluster, all its automated backups are deleted at the same time and cannot be recovered. This means that unless you choose to create a final DB snapshot manually, you can't restore the DB instance to its final state at a later time. Manual snapshots are not deleted when the cluster is deleted.
Note
For Amazon Neptune DB clusters, the default backup retention period is one day regardless of how the DB cluster is created.
You cannot disable automated backups on Neptune. The backup retention period for Neptune is managed by the DB cluster.
CloudWatch metrics that are useful for managing Neptune backup storage
You can use the Amazon CloudWatch metrics TotalBackupStorageBilled,
SnapshotStorageUsed, and BackupRetentionPeriodStorageUsed to review and
monitor the amount of storage used by your Neptune backups, as follows:
-
BackupRetentionPeriodStorageUsedrepresents the amount of backup storage used, in bytes, for storing continuous backups at the current time. This value depends on the size of the cluster volume and the amount of changes you make during the retention period. However, for billing purposes it doesn't exceed the cumulative cluster volume size during the retention period. For example, if your cluster'sVolumeBytesUsedsize is 107,374,182,400 bytes (100 GiB), and your retention period is two days, the maximum value forBackupRetentionPeriodStorageUsedis 214,748,364,800 bytes (100 GiB + 100 GiB). -
SnapshotStorageUsedrepresents the amount of backup storage used, in bytes, for storing manual snapshots beyond the backup retention period. Manual snapshots don't count against your snapshot backup storage while their creation timestamp is within the retention period. All automatic snapshots also don't count against your snapshot backup storage. The size of each snapshot is the size of the cluster volume at the time you take the snapshot. TheSnapshotStorageUsedvalue depends on the number of snapshots you keep and the size of each snapshot. For example, suppose you have one manual snapshot outside the retention period, and the cluster'sVolumeBytesUsedsize was 100 GiB when that snapshot was taken. The amount of SnapshotStorageUsed is 107,374,182,400 bytes (100 GiB). -
TotalBackupStorageBilledrepresents the sum, in bytes, ofBackupRetentionPeriodStorageUsedandSnapshotStorageUsed, minus an amount of free backup storage, which equals the size of the cluster volume for one day. The free backup storage is equal to the latest volume size. For example if your cluster'sVolumeBytesUsedsize is 100 GiB, your retention period is two days, and you have one manual snapshot outside the retention period, theTotalBackupStorageBilledis 214,748,364,800 bytes (200 GiB + 100 GiB - 100 GiB).
You can monitor a Neptune cluster and build reports using CloudWatch metrics through the
CloudWatch console
Restoring data from a Neptune backup
You can recover your data by creating a new Neptune DB cluster from the backup data that Neptune retains, or from a DB cluster snapshot that you have saved. You can quickly restore a new copy of a DB cluster created from backup data to any point in time during your backup retention period. The continuous and incremental nature of Neptune backups during the backup retention period means you don't need to take frequent snapshots of your data to improve restore times.
To determine the latest or earliest restorable time for a DB instance, look for
the Latest Restorable Time or Earliest Restorable Time
values on the Neptune console. The latest restorable time for a DB cluster is the
most recent point at which you can restore your DB cluster, typically within
5 minutes of the current time. The earliest restorable time specifies how far back
within the backup retention period that you can restore your cluster volume.
You can determine when the restore of a DB cluster is complete by checking the
Latest Restorable Time and Earliest Restorable Time
values. The Latest Restorable Time and Earliest Restorable
Time values return NULL until the restore operation is complete. You
can't request a backup or restore operation if Latest Restorable
Time or Earliest Restorable Time returns NULL.
To restore a DB instance to a specified time using the Amazon Web Services Management Console
Sign in to the Amazon Management Console, and open the Amazon Neptune console at https://console.aws.amazon.com/neptune/home
. In the navigation pane, choose Instances. Choose the primary instance for the DB cluster that you want to restore.
-
Choose Instance actions, and then choose Restore to point in time.
In the Launch DB Instance window, choose Custom under Restore time.
Specify the date and time that you want to restore to under Custom.
Type a name for the new, restored DB instance for DB instance identifier under Settings.
-
Choose Launch DB Instance to launch the restored DB instance.
A new DB instance is created with the name you specified, and a new DB cluster is created. The DB cluster name is the new DB instance name followed by
–cluster. For example, if the new DB instance name ismyrestoreddb, the new DB cluster name ismyrestoreddb-cluster.
Backup window in Neptune
Automated backups occur daily during the preferred backup window. If the backup requires more time than allotted to the backup window, the backup continues after the window ends, until it finishes. The backup window can't overlap with the weekly maintenance window for the DB instance.
During the automatic backup window, storage I/O might be suspended briefly while the backup process initializes (typically under a few seconds). You might experience elevated latencies for a few minutes during backups for Multi-AZ deployments.
The backup window is normally selected at random from an eight-hour block of time per Region by the Amazon RDS control plane underlying Neptune. The time blocks for each Region from which the default backups windows are assigned is documented in the Backup Window section of the Amazon RDS User Guide.