Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

How point-in-time recovery works in Amazon Keyspaces

This section provides an overview of how Amazon Keyspaces point-in-time recovery (PITR) works. For more information about pricing, see Amazon Keyspaces (for Apache Cassandra) pricing.

Enabling point-in-time recovery (PITR)

You can enable PITR by using the console, or you can enable it programmatically.

Enabling PITR with the console

PITR settings for new tables can be managed under the Customized settings option. By default, PITR is enabled on new tables created through the console.

To enable PITR for an existing table, complete the following steps.

You can disable PITR on a table at any time with the following steps.

To learn how to restore a table using the console, see Restoring a table to a point in time (console).

Enabling PITR using the Amazon CLI

You can manage PITR settings for tables by using the UpdateTable API.

When creating a new table using Amazon CLI, you must explicitly enable PITR when you create the new table.

To enable PITR when you're creating a new table, you can use the following Amazon CLI command as an example. The command has been broken into separate lines to improve readability.

aws keyspaces create-table --keyspace-name 'myKeyspace' --table-name 'myTable' 
            --schema-definition 'allColumns=[{name=id,type=int},{name=name,type=text},{name=date,type=timestamp}],partitionKeys=[{name=id}]' 
            --point-in-time-recovery 'status=ENABLED'

To confirm the point-in-time recovery setting for a table, you can use the following Amazon CLI command.

aws keyspaces get-table --keyspace-name 'myKeyspace' --table-name 'myTable'

To enable PITR for an existing table using the Amazon CLI, run the following command.

aws keyspaces update-table --keyspace-name 'myKeyspace' --table-name 'myTable' --point-in-time-recovery 'status=ENABLED'

To disable PITR on an existing table, run the following Amazon CLI command.

aws keyspaces update-table --keyspace-name 'myKeyspace' --table-name 'myTable' --point-in-time-recovery 'status=DISABLED'

Enabling PITR using CQL

You can manage PITR settings for tables by using the point_in_time_recovery custom property.

When creating a new table using CQL, you must explicitly enable PITR when you create the new table.

To enable PITR when you're creating a new table, you can use the following CQL command as an example.

CREATE TABLE "my_keyspace1"."my_table1"(
	"id" int,
	"name" ascii,
	"date" timestamp,
	PRIMARY KEY("id"))
WITH CUSTOM_PROPERTIES = {
	'capacity_mode':{'throughput_mode':'PAY_PER_REQUEST'}, 
	'point_in_time_recovery':{'status':'enabled'}
}

To enable PITR for an existing table using CQL, run the following CQL command.

ALTER TABLE mykeyspace.mytable
WITH custom_properties = {'point_in_time_recovery': {'status': 'enabled'}}

To disable PITR on an existing table, run the following CQL command.

ALTER TABLE mykeyspace.mytable
WITH custom_properties = {'point_in_time_recovery': {'status': 'disabled'}}

For more information in the CQL Language Reference, see CREATE TABLE and ALTER TABLE. To learn how to restore a table using CQL, see Restoring a table to a point in time with CQL.

Permissions required to restore a table

To successfully restore a table, the IAM user or role needs the following minimum permissions:

The following is an example of a policy that grants minimum required permissions to a user to restore tables in keyspace mykeyspace.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Effect":"Allow",
         "Action":[
            "cassandra:Restore",
            "cassandra:Select"
         ],
         "Resource":[
            "arn:aws:cassandra:us-east-1:111122223333:/keyspace/mykeyspace/*",
            "arn:aws:cassandra:us-east-1:111122223333:/keyspace/system*"
         ]
      }
   ]
}

Additional permissions to restore a table might be required based on other selected features. For example, if the source table is encrypted at rest with a customer managed key, Amazon Keyspaces must have permissions to access the customer managed key of the source table to successfully restore the table. For more information, see PITR restore of encrypted tables.

If you are using IAM policies with condition keys to restrict incoming traffic to specific sources, you must ensure that Amazon Keyspaces has permission to perform a restore operation on your principal's behalf. You must add an aws:ViaAWSService condition key to your IAM policy if your policy restricts incoming traffic to any of the following:

The aws:ViaAWSService condition key allows access when any Amazon service makes a request using the principal's credentials. For more information, see IAM JSON policy elements: Condition key in the IAM User Guide.

The following is an example of a policy that restricts source traffic to a specific IP address and allows Amazon Keyspaces to restore a table on the principal's behalf.

{
   "Version":"2012-10-17",
   "Statement":[
      {
         "Sid":"CassandraAccessForCustomIp",
         "Effect":"Allow",
         "Action":"cassandra:*",
         "Resource":"*",
         "Condition":{
            "Bool":{
               "aws:ViaAWSService":"false"
            },
            "ForAnyValue:IpAddress":{
               "aws:SourceIp":[
                  "123.45.167.89"
               ]
            }
         }
      },
      {
         "Sid":"CassandraAccessForAwsService",
         "Effect":"Allow",
         "Action":"cassandra:*",
         "Resource":"*",
         "Condition":{
            "Bool":{
               "aws:ViaAWSService":"true"
            }
         }
      }
   ]
}

For an example policy using the aws:ViaAWSService global condition key, see VPC endpoint policies and Amazon Keyspaces point-in-time recovery (PITR).

Time window for PITR continuous backups

Amazon Keyspaces PITR uses two timestamps to maintain the time frame for which restorable backups are available for a table.

When PITR is enabled, you can restore to any point in time between EarliestRestorableDateTime and CurrentTime. You can only restore table data to a time when PITR was enabled.

If you disable PITR and later reenable it again, you reset the start time for the first available backup to when PITR was reenabled. This means that disabling PITR erases your backup history.

A table doesn't have to be active to be restored. You can also restore deleted tables if PITR was enabled on the deleted table and the deletion occurred within the backup window (or within the last 35 days).

PITR restore settings

When you restore a table using PITR, Amazon Keyspaces restores your source table's schema and data to the state based on the selected timestamp (day:hour:minute:second) to a new table. PITR doesn't overwrite existing tables.

In addition to the table's schema and data, PITR restores the custom_properties from the source table. Unlike the table's data, which is restored based on the selected timestamp between earliest restore time and current time, custom properties are always restored based on the table's settings as of the current time.

The settings of the restored table match the settings of the source table with the timestamp of when the restore was initiated. If you want to overwrite these settings during restore, you can do so using WITH custom_properties. Custom properties include the following settings.

If the table is in provisioned capacity mode with auto scaling enabled, the restore operation also restores the table's auto scaling settings. You can overwrite them using the autoscaling_settings parameter in CQL or autoScalingSpecification with the CLI. For more information on auto scaling settings, see Manage throughput capacity automatically with Amazon Keyspaces auto scaling.

When you do a full table restore, all table settings for the restored table come from the current settings of the source table at the time of the restore.

For example, suppose that a table's provisioned throughput was recently lowered to 50 read capacity units and 50 write capacity units. You then restore the table's state to three weeks ago. At this time, its provisioned throughput was set to 100 read capacity units and 100 write capacity units. In this case, Amazon Keyspaces restores your table data to that point in time, but uses the current provisioned throughput settings (50 read capacity units and 50 write capacity units).

The following settings are not restored, and you must configure them manually for the new table.

PITR restore of encrypted tables

When you restore a table using PITR, Amazon Keyspaces restores your source table's encryption settings. If the table was encrypted with an Amazon owned key (default), the table is restored with the same setting automatically. If the table you want to restore was encrypted using a customer managed key, the same customer managed key needs to be accessible to Amazon Keyspaces to restore the table data.

You can change the encryption settings of the table at the time of restore. To change from an Amazon owned key to a customer managed key, you need to supply a valid and accessible customer managed key at the time of restore.

If you want to change from a customer managed key to an Amazon owned key, confirm that Amazon Keyspaces has access to the customer managed key of the source table to restore the table with an Amazon owned key. For more information about encryption at rest settings for tables, see Encryption at rest: How it works in Amazon Keyspaces.

PITR restore of multi-Region tables

You can restore a multi-Region table using PITR. For the restore operation to be successful, both the source and the destination table have to be replicated to the same Amazon Web Services Regions.

Amazon Keyspaces restores the settings of the source table in each of the replicated Regions that are part of the keyspace. You can also override settings during the restore operation. For more information about settings that can be changed during the restore, see PITR restore settings.

For more information about Multi-Region Replication, see How Multi-Region Replication works in Amazon Keyspaces.

Table restore time with PITR

The time it takes you to restore a table is based on multiple factors and isn't always correlated directly to the size of the table.

The following are some considerations for restore times.

A best practice when planning for disaster recovery is to regularly document average restore completion times and establish how these times affect your overall Recovery Time Objective.

Amazon Keyspaces PITR and integration with Amazon services

The following PITR operations are logged using Amazon CloudTrail to enable continuous monitoring and auditing.

For more information, see Logging Amazon Keyspaces API calls with Amazon CloudTrail.

You can perform the following PITR actions using Amazon CloudFormation.

For more information, see the Cassandra Resource Type Reference in the Amazon CloudFormation User Guide.