How point-in-time recovery works in Amazon Keyspaces - Amazon Keyspaces (for Apache Cassandra)

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.

  1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at https://console.aws.amazon.com/keyspaces/home.

  2. In the navigation pane, choose Tables and select the table you want to edit.

  3. On the Backups tab, choose Edit.

  4. In the Edit point-in-time recovery settings section, select Enable Point-in-time recovery.

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

  1. Sign in to the AWS Management Console, and open the Amazon Keyspaces console at https://console.aws.amazon.com/keyspaces/home.

  2. In the navigation pane, choose Tables and select the table you want to edit.

  3. On the Backups tab, choose Edit.

  4. In the Edit point-in-time recovery settings section, clear the Enable Point-in-time recovery check box.

Important

Disabling PITR deletes your backup history immediately, even if you reenable PITR on the table within 35 days.

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

Enabling PITR using the AWS CLI

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

When creating a new table using AWS 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 AWS 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'
Note

If no point-in-time recovery value is specified, point-in-time recovery is disabled by default.

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

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

To enable PITR for an existing table using the AWS 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 AWS CLI command.

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

Disabling PITR deletes your backup history immediately, even if you reenable PITR on the table within 35 days.

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'} }
Note

If no point-in-time recovery custom property is specified, point-in-time recovery is disabled by default.

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'}}
Important

Disabling PITR deletes your backup history immediately, even if you reenable PITR on the table within 35 days.

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:

  • cassandra:Restore – The restore action is required for the target table to be restored.

  • cassandra:Select – The select action is required to read from the source table.

  • cassandra:TagResource – The tag action is optional, and only required if the restore operation adds tags.

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:

  • VPC endpoints with aws:SourceVpce

  • IP ranges with aws:SourceIp

  • VPCs with aws:SourceVpc

The aws:ViaAWSService condition key allows access when any AWS 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.

  • Earliest restorable time – Marks the time of the earliest restorable backup. The earliest restorable backup goes back up to 35 days or when PITR was enabled, whichever is more recent. The maximum backup window of 35 days can't be modified.

  • Current time – The timestamp for the latest restorable backup is the current time. If no timestamp is provided during a restore, current time is used.

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.

Note

Data definition language (DDL) operations on tables, such as schema changes, are performed asynchronously. You can only see completed operations in your restored table data, but you might see additional actions on your source table if they were in progress at the time of the restore. For a list of DDL statements, see DDL statements (data definition language) in Amazon Keyspaces.

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

Note

If a new table is created with the same qualified name (for example, mykeyspace.mytable) as a previously deleted table, the deleted table will no longer be restorable. If you attempt to do this from the console, a warning is displayed.

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.

  • Read/write capacity mode

  • Provisioned throughput capacity settings

  • PITR settings

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.

  • Automatic scaling policies (for tables that use provisioned capacity mode)

  • AWS Identity and Access Management (IAM) policies

  • Amazon CloudWatch metrics and alarms

  • Tags (can be added to the CQL RESTORE statement using WITH TAGS)

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 AWS 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 AWS 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 AWS owned key, confirm that Amazon Keyspaces has access to the customer managed key of the source table to restore the table with an AWS owned key. For more information about encryption at rest settings for tables, see Encryption at rest: How it works in Amazon Keyspaces.

Note

If the table was deleted because Amazon Keyspaces lost access to your customer managed key, you need to ensure the customer managed key is accessible to Amazon Keyspaces before trying to restore the table. A table that was encrypted with a customer managed key can't be restored if Amazon Keyspaces doesn't have access to that key. For more information, see Troubleshooting key access in the AWS Key Management Service Developer Guide.

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.

  • You restore backups to a new table. It can take up to 20 minutes (even if the table is empty) to perform all the actions to create the new table and initiate the restore process.

  • Restore times for large tables with well-distributed data models can be several hours or longer.

  • If your source table contains data that is significantly skewed, the time to restore might increase. For example, if your table’s primary key is using the month of the year as a partition key, and all your data is from the month of December, you have skewed data.

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 AWS services

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

  • Create a new table with PITR enabled or disabled.

  • Enable or disable PITR on an existing table.

  • Restore an active or a deleted table.

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

You can perform the following PITR actions using AWS CloudFormation.

  • Create a new table with PITR enabled or disabled.

  • Enable or disable PITR on an existing table.

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