Amazon Redshift will no longer support the creation of new Python UDFs starting Patch 198. Existing Python UDFs will continue to function until June 30, 2026. For more information, see the [ blog post ](https://amazonaws-china.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). # Amazon Redshift snapshots and backups Snapshots and backups Snapshots are point-in-time backups of a cluster. There are two types of snapshots: *automated* and *manual*. Amazon Redshift stores these snapshots internally in Amazon S3 by using an encrypted Secure Sockets Layer (SSL) connection. Amazon Redshift automatically takes incremental snapshots that track changes to the cluster since the previous automated snapshot. Automated snapshots retain all of the data required to restore a cluster from a snapshot. You can create a snapshot schedule to control when automated snapshots are taken, or you can take a manual snapshot any time. When you restore from a snapshot, Amazon Redshift creates a new cluster and makes the new cluster available before all of the data is loaded, so you can begin querying the new cluster immediately. The cluster streams data on demand from the snapshot in response to active queries, then loads the remaining data in the background. When you launch a cluster, you can set the retention period for automated and manual snapshots. You can change the default retention period for automated and manual snapshots by modifying the cluster. You can change the retention period for a manual snapshot when you create the snapshot or by modifying the snapshot. You can monitor the progress of snapshots by viewing the snapshot details in the Amazon Web Services Management Console, or by calling [describe-cluster-snapshots](https://docs.amazonaws.cn/cli/latest/reference/redshift/describe-cluster-snapshots.html) in the CLI or the [DescribeClusterSnapshots](https://docs.amazonaws.cn/redshift/latest/APIReference/API_DescribeClusterSnapshots.html) API action. For an in-progress snapshot, these display information such as the size of the incremental snapshot, the transfer rate, the elapsed time, and the estimated time remaining. To ensure that your backups are always available to your cluster, Amazon Redshift stores snapshots in an internally managed Amazon S3 bucket that is managed by Amazon Redshift. To manage storage charges, evaluate how many days you need to keep automated snapshots and configure their retention period accordingly. Delete any manual snapshots that you no longer need. For more information about the cost of backup storage, see the [Amazon Redshift pricing](http://www.amazonaws.cn/redshift/pricing/) page. You can also create and restore snapshots using Amazon Backup, a fully managed service that helps you centralize and automate data protection across Amazon services, in the cloud, and on premises. For more information, see [Amazon Backup integration with Amazon Redshift](managing-aws-backup.md). For information on Amazon Backup, see [What is Amazon Backup?](https://docs.amazonaws.cn/aws-backup/latest/devguide/whatisbackup.html) in the *Amazon Backup Developer Guide*. ## Working with snapshots and backups in Amazon Redshift Serverless Amazon Redshift Serverless, like a provisioned cluster, enables you to take a backup as a point-in-time representation of the objects and data in the namespace. There are two types of backups in Amazon Redshift Serverless: snapshots that are manually created and recovery points that Amazon Redshift Serverless creates automatically. You can find more information about working with snapshots for Amazon Redshift Serverless at [Snapshots and recovery points](https://docs.amazonaws.cn/redshift/latest/mgmt/serverless-snapshots-recovery-points.html). You can also restore a snapshot from a provisioned cluster to a serverless namespace. For more information, see [Restoring a serverless namespace from a snapshot](https://docs.amazonaws.cn/redshift/latest/mgmt/serverless-snapshot-restore.html). ## Automated snapshots When automated snapshots are enabled for a cluster, Amazon Redshift periodically takes snapshots of that cluster. By default Amazon Redshift takes a snapshot about every eight hours or following every 5 GB per node of data changes, or whichever comes first. If your data is larger than 5 GB \$1 the number of nodes, the shortest amount of time in between automated snapshot creation is 15 minutes. Alternatively, you can create a snapshot schedule to control when automated snapshots are taken. If you're using custom schedules, the minimum amount of time between automated snapshots is one hour. Automated snapshots are enabled by default when you create a cluster. Automated snapshots are deleted at the end of a retention period. The default retention period is one day, but you can modify it by using the Amazon Redshift console or programmatically by using the Amazon Redshift API or CLI. To disable automated snapshots, set the retention period to zero. If you disable automated snapshots, Amazon Redshift stops taking snapshots and deletes any existing automated snapshots for the cluster. You can't disable automated snapshots for RA3 node types. You can set an RA3 node type automated retention period from 1–35 days. Only Amazon Redshift can delete an automated snapshot; you cannot delete them manually. Amazon Redshift deletes automated snapshots at the end of a snapshot's retention period, when you disable automated snapshots for the cluster, or when you delete the cluster. *Amazon Redshift retains the latest automated snapshot until you disable automated snapshots or delete the cluster.* If you want to keep an automated snapshot for a longer period, you can create a copy of it as a manual snapshot. The automated snapshot is retained until the end of the retention period, but the corresponding manual snapshot is retained until you manually delete it or until the end of the retention period. ## Automated snapshot schedules To precisely control when snapshots are taken, you can create a snapshot schedule and attach it to one or more clusters. When you modify a snapshot schedule, the schedule is modified for all associated clusters. If a cluster doesn't have a snapshot schedule attached, the cluster uses the default automated snapshot schedule. A *snapshot schedule* is a set of schedule rules. You can define a simple schedule rule based on a specified interval, such as every 8 hours or every 12 hours. You can also add rules to take snapshots on certain days of the week, at specific times, or during specific periods. Rules can also be defined using Unix-like cron expressions. ## Snapshot schedule format On the Amazon Redshift console, you can create a snapshot schedule. Then, you can attach a schedule to a cluster to trigger the creation of a system snapshot. A schedule can be attached to multiple clusters, and you can create multiple cron definitions in a schedule to trigger a snapshot. You can define a schedule for your snapshots using a cron syntax. The definition of these schedules uses a modified Unix-like [cron](http://en.wikipedia.org/wiki/Cron) syntax. You specify time in [Coordinated universal time (UTC)](http://en.wikipedia.org/wiki/Coordinated_Universal_Time). You can create schedules with a maximum frequency of one hour and minimum precision of one minute. Amazon Redshift modified cron expressions have 3 required fields, which are separated by white space. **Syntax** ``` cron(Minutes Hours Day-of-month Month Day-of-week Year) ``` | **Fields** | **Values** | **Wildcards** | | --- | --- | --- | | Minutes | 0–59 | , - \$1 / | | Hours | 0–23 | , - \$1 / | | Day-of-month | 1–31 | , - \$1 ? / L W | | Month | 1–12 or JAN-DEC | , - \$1 / | | Day-of-week | 1–7 or SUN-SAT | , - \$1 ? L \$1 | | Year | 1970–2199 | , - \$1 / | **Wildcards** + The **,** (comma) wildcard includes additional values. In the `Day-of-week` field, `MON,WED,FRI` would include Monday, Wednesday, and Friday. Total values are limited to 24 per field. + The **-** (dash) wildcard specifies ranges. In the `Hour` field, 1–15 would include hours 1 through 15 of the specified day. + The **\$1** (asterisk) wildcard includes all values in the field. In the `Hours` field, **\$1** would include every hour. + The **/** (forward slash) wildcard specifies increments. In the `Hours` field, you could enter **1/10** to specify every 10th hour, starting from the first hour of the day (for example, the 01:00, 11:00, and 21:00). + The **?** (question mark) wildcard specifies one or another. In the `Day-of-month` field you could enter **7**, and if you didn't care what day of the week the seventh was, you could enter **?** in the Day-of-week field. + The **L** wildcard in the `Day-of-month` or `Day-of-week` fields specifies the last day of the month or week. + The **W** wildcard in the `Day-of-month` field specifies a weekday. In the `Day-of-month` field, `3W` specifies the day closest to the third weekday of the month. + The **\$1** wildcard in the Day-of-week field specifies a certain instance of the specified day of the week within a month. For example, 3\$12 would be the second Tuesday of the month: the 3 refers to Tuesday because it is the third day of each week, and the 2 refers to the second day of that type within the month. **Note** If you use a '\$1' character, you can define only one expression in the day-of-week field. For example, "3\$11,6\$13" is not valid because it is interpreted as two expressions. **Limits** + You can't specify the `Day-of-month` and `Day-of-week` fields in the same cron expression. If you specify a value in one of the fields, you must use a **?** (question mark) in the other. + Snapshot schedules don't support the following frequencies: + Snapshots scheduled more frequently than 1 per hour. + Snapshots scheduled less frequently than 1 per day (24 hours). If you have overlapping schedules that result in scheduling snapshots within a 1 hour window, a validation error results. When creating a schedule, you can use the following sample cron strings. | Minutes | Hours | Day of week | Meaning | | --- | --- | --- | --- | | 0 | 14-20/1 | TUE | Every hour between 2pm and 8pm on Tuesday. | | 0 | 21 | MON-FRI | Every night at 9pm Monday–Friday. | | 30 | 0/6 | SAT-SUN | Every 6 hour increment on Saturday and Sunday starting at 30 minutes after midnight (00:30) that day. This results in a snapshot at [00:30, 06:30, 12:30, and 18:30] each day. | | 30 | 12/4 | \$1 | Every 4 hour increment starting at 12:30 each day. This resolves to [12:30, 16:30, 20:30]. | For example to run on a schedule on an every 2 hour increment starting at 15:15 each day. This resolves to [15:15, 17:15, 19:15, 21:15, 23:15] , specify: ``` cron(15 15/2 *) ``` You can create multiple cron schedule definitions within as schedule. For example the following Amazon CLI command contains two cron schedules in one schedule. ``` create-snapshot-schedule --schedule-identifier "my-test" --schedule-definition "cron(0 17 SAT,SUN)" "cron(0 9,17 MON-FRI)" ``` ## Manual snapshots You can take a manual snapshot any time. By default, manual snapshots are retained indefinitely, even after you delete your cluster. You can specify the retention period when you create a manual snapshot, or you can change the retention period by modifying the snapshot. For more information about changing the retention period, see [Modifying the manual snapshot retention period](snapshot-manual-retention-period.md). If a snapshot is deleted, you can't start any new operations that reference that snapshot. However, if a restore operation is in progress, that restore operation will run to completion. Amazon Redshift has a quota that limits the total number of manual snapshots that you can create; this quota is per Amazon account per Amazon Region. The default quota is listed at [Quotas and limits in Amazon Redshift](amazon-redshift-limits.md). ## Snapshot storage Because snapshots accrue storage charges, it's important that you delete them when you no longer need them. Amazon Redshift deletes automated and manual snapshots at the end of their respective snapshot retention periods. You can also delete manual snapshots using the Amazon Web Services Management Console or with the [batch-delete-cluster-snapshots](https://docs.amazonaws.cn/cli/latest/reference/redshift/batch-delete-cluster-snapshots.html) CLI command. You can change the retention period for a manual snapshot by modifying the manual snapshot settings. You can get information about how much storage your snapshots are consuming using the Amazon Redshift Console or using the [describe-storage](https://docs.amazonaws.cn/cli/latest/reference/redshift/describe-storage.html) CLI command. ## Excluding tables from snapshots By default, all user-defined permanent tables are included in snapshots. If a table, such as a staging table, doesn't need to be backed up, you can significantly reduce the time needed to create snapshots and restore from snapshots. You also reduce storage space on Amazon S3 by using a no-backup table. To create a no-backup table, include the BACKUP NO parameter when you create the table. For more information, see [CREATE TABLE](https://docs.amazonaws.cn/redshift/latest/dg/r_CREATE_TABLE_NEW.html) and [CREATE TABLE AS](https://docs.amazonaws.cn/redshift/latest/dg/r_CREATE_TABLE_AS.html) in the *Amazon Redshift Database Developer Guide*. **Note** No-backup tables aren't supported for RA3 provisioned clusters and Amazon Redshift Serverless workgroups. A table marked as no-backup in an RA3 cluster or serverless workgroup is treated as a permanent table that will always be backed up while taking a snapshot, and always restored when restoring from a snapshot. To avoid snapshot costs for no-backup tables, truncate them before taking a snapshot. # Creating a manual snapshot You can create a manual snapshot of a cluster from the snapshots list as follows. Or, you can take a snapshot of a cluster in the cluster configuration pane. For more information, see [Amazon Redshift snapshots and backups](working-with-snapshots.md). **Note** No-backup tables aren't supported for RA3 provisioned clusters and Amazon Redshift Serverless workgroups. A table marked as no-backup in an RA3 cluster or serverless workgroup is treated as a permanent table that will always be backed up while taking a snapshot, and always restored when restoring from a snapshot. To avoid snapshot costs for no-backup tables, truncate them before taking a snapshot. **To create a manual snapshot** 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose **Create snapshot**. The snapshot page to create a manual snapshot is displayed. 1. Enter the properties of the snapshot definition, then choose **Create snapshot**. It might take some time for the snapshot to be available. # Creating a snapshot schedule Amazon Redshift takes automatic, incremental snapshots of your data periodically and saves them to Amazon S3. Additionally, you can take manual snapshots of your data whenever you want. All snapshot tasks in the Amazon Redshift console start from the snapshot list. You can filter the list by using a time range, the snapshot type, and the cluster associated with the snapshot. In addition, you can sort the list by date, size, and snapshot type. Depending on the snapshot type that you select, you might have different options available for working with the snapshot. To precisely control when snapshots are taken, you can create a snapshot schedule and attach it to one or more clusters. You can attach a schedule when you create a cluster or by modifying the cluster. For more information, see [Automated snapshot schedules](working-with-snapshots.md#automated-snapshot-schedules). **To create a snapshot schedule** 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the **Snapshot schedules** tab. The snapshot schedules are displayed. 1. Choose **Add schedule** to display the page to add a schedule. 1. Enter the properties of the schedule definition, then choose **Add schedule**. 1. On the page that appears, you can attach clusters to your new snapshot schedule, then choose **OK**. # Sharing a snapshot You can share an existing manual snapshot with other Amazon customer accounts by authorizing access to the snapshot. You can authorize up to 20 for each snapshot and 100 for each Amazon Key Management Service (Amazon KMS) key. That is, if you have 10 snapshots that are encrypted with a single KMS key, then you can authorize 10 Amazon accounts to restore each snapshot, or other combinations that add up to 100 accounts and do not exceed 20 accounts for each snapshot. A person logged in as a user in one of the authorized accounts can then describe the snapshot or restore it to create a new Amazon Redshift cluster under their account. For example, if you use separate Amazon customer accounts for production and test, a user can log on using the production account and share a snapshot with users in the test account. Someone logged on as a test account user can then restore the snapshot to create a new cluster that is owned by the test account for testing or diagnostic work. A manual snapshot is permanently owned by the Amazon customer account under which it was created. Only users in the account owning the snapshot can authorize other accounts to access the snapshot, or to revoke authorizations. Users in the authorized accounts can only describe or restore any snapshot that has been shared with them; they cannot copy or delete snapshots that have been shared with them. An authorization remains in effect until the snapshot owner revokes it. If an authorization is revoked, the previously authorized user loses visibility of the snapshot and cannot launch any new actions referencing the snapshot. If the account is in the process of restoring the snapshot when access is revoked, the restore runs to completion. You cannot delete a snapshot while it has active authorizations; you must first revoke all of the authorizations. Amazon customer accounts are always authorized to access snapshots owned by the account. Attempts to authorize or revoke access to the owner account will receive an error. You cannot restore or describe a snapshot that is owned by an inactive Amazon customer account. After you have authorized access to an Amazon customer account, no users in that account can perform any actions on the snapshot unless they assume a role with policies that allow them to do so. + Users in the snapshot owner account can authorize and revoke access to a snapshot only if they assume a role with an IAM policy that allows them to perform those actions with a resource specification that includes the snapshot. For example, the following policy allows a user or role in Amazon account `012345678912` to authorize other accounts to access a snapshot named `my-snapshot20130829`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "redshift:AuthorizeSnapshotAccess", "redshift:RevokeSnapshotAccess" ], "Resource":[ "arn:aws-cn:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829" ] } ] } ``` ------ + Users in an Amazon account with which a snapshot has been shared cannot perform actions on that snapshot unless they have permissions allowing those actions. You can do this by assigning the policy to a role and assuming the role. + To list or describe a snapshot, they must have an IAM policy that allows the `DescribeClusterSnapshots` action. The following code shows an example: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "redshift:DescribeClusterSnapshots" ], "Resource":[ "*" ] } ] } ``` ------ + To restore a snapshot, a user must assume a role with an IAM policy that allows the `RestoreFromClusterSnapshot` action and has a resource element that covers both the cluster they are attempting to create and the snapshot. For example, if a user in account `012345678912` has shared snapshot `my-snapshot20130829` with account `219876543210`, in order to create a cluster by restoring the snapshot, a user in account `219876543210` must assume a role with a policy such as the following: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "redshift:RestoreFromClusterSnapshot" ], "Resource":[ "arn:aws-cn:redshift:us-east-1:012345678912:snapshot:*/my-snapshot20130829", "arn:aws-cn:redshift:us-east-1:219876543210:cluster:from-another-account" ] } ] } ``` ------ + After access to a snapshot has been revoked from an Amazon account, no users in that account can access the snapshot. This is the case even if those accounts have IAM policies that allow actions on the previously shared snapshot resource. ## Sharing a cluster snapshot using the console On the console, you can authorize other users to access a manual snapshot you own, and you can later revoke that access when it is no longer required. **To share a snapshot with another account** 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the manual snapshot to share. 1. For **Actions**, choose **Manual snapshot settings** to display the properties of the manual snapshot. 1. Enter the account or accounts to share with in the **Manage access** section, then choose **Save**. ## Security considerations for sharing encrypted snapshots When you provide access to an encrypted snapshot, Redshift requires that the Amazon KMS customer managed key used to create the snapshot is shared with the account or accounts performing the restore. If the key isn't shared, attempting to restore the snapshot results in an access-denied error. The receiving account doesn't need any extra permissions to restore a shared snapshot. When you authorize snapshot access and share the key, the identity authorizing access must have `kms:DescribeKey` permissions on the key used to encrypt the snapshot. This permission is described in more detail in [Amazon KMS permissions](https://docs.amazonaws.cn/kms/latest/developerguide/kms-api-permissions-reference.html). For more information, see [DescribeKey](https://docs.amazonaws.cn/kms/latest/APIReference/API_DescribeKey.html) in the Amazon Redshift API reference documentation. The customer managed key policy can be updated programmatically or in the Amazon Key Management Service console. **Note** If you're using a default KMS key, you don't need to take action or change anything in Amazon KMS in order to share a snapshot. ### Allowing access to the Amazon KMS key for an encrypted snapshot To share the Amazon KMS customer managed key for an encrypted snapshot, update the key policy by performing the following steps: 1. Update the KMS key policy with the Amazon Resource Name (ARN) of the Amazon account that you are sharing to as `Principal` in the KMS key policy. 1. Allow the `kms:Decrypt` action. In the following key-policy example, user `111122223333` is the owner of the KMS key, and user `444455556666` is the account that the key is shared with. This key policy gives the Amazon account access to the sample KMS key by including the ARN for the root Amazon account identity for user `444455556666` as a `Principal` for the policy, and by allowing the `kms:Decrypt` action. ------ #### [ JSON ] **** ``` { "Id": "key-policy-1", "Version":"2012-10-17", "Statement": [ { "Sid": "Allow use of the key", "Effect": "Allow", "Principal": { "AWS": [ "arn:aws-cn:iam::111122223333:user/KeyUser", "arn:aws-cn:iam::444455556666:root" ] }, "Action": [ "kms:Decrypt" ], "Resource": "*" } ] } ``` ------ After access is granted to the customer managed KMS key, the account that restores the encrypted snapshot must create an Amazon Identity and Access Management (IAM) role, or user, if it doesn't already have one. In addition, that Amazon account must also attach an IAM policy to that IAM role or user that allows them to restore an encrypted database snapshot, using your KMS key. For more information about giving access to an Amazon KMS key, see [Allowing users in other accounts to use a KMS key](https://docs.amazonaws.cn/kms/latest/developerguide/key-policy-modifying-external-accounts.html#cross-account-console), in the Amazon Key Management Service developer guide. For an overview of key policies, see [How Amazon Redshift uses Amazon KMS](https://docs.amazonaws.cn/kms/latest/developerguide/services-redshift.html). # Copying an automated snapshot Automated snapshots are automatically deleted when their retention period expires, when you disable automated snapshots, or when you delete a cluster. If you want to keep an automated snapshot, you can copy it to a manual snapshot. **To copy an automated snapshot** 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the snapshot to copy. 1. For **Actions**, choose **Copy automated snapshot** to copy the snapshot. 1. Update the properties of the new snapshot, then choose **Copy**. # Copying a snapshot to another Amazon Region You can configure Amazon Redshift to automatically copy snapshots (automated or manual) for a cluster to another Amazon Region. When a snapshot is created in the cluster's primary Amazon Region, it's copied to a secondary Amazon Region. The two Amazon Regions are known respectively as the *source Amazon Region* and *destination Amazon Region*. If you store a copy of your snapshots in another Amazon Region, you can restore your cluster from recent data if anything affects the primary Amazon Region. You can configure your cluster to copy snapshots to only one destination Amazon Region at a time. For a list of Amazon Redshift Regions, see [Regions and endpoints](https://docs.amazonaws.cn/general/latest/gr/rande.html) in the *Amazon Web Services General Reference*. When you enable Amazon Redshift to automatically copy snapshots to another Amazon Region, you specify the destination Amazon Region to copy the snapshots to. For automated snapshots, you can also specify the retention period to keep them in the destination Amazon Region. After an automated snapshot is copied to the destination Amazon Region and it reaches the retention time period there, it's deleted from the destination Amazon Region. Doing this keeps your snapshot usage low. To keep the automated snapshots for a shorter or longer time in the destination Amazon Region, change this retention period. The retention period that you set for automated snapshots that are copied to the destination Amazon Region is separate from the retention period for automated snapshots in the source Amazon Region. The default retention period for copied snapshots is seven days. That seven-day period applies only to automated snapshots. In both the source and destination Amazon Regions, manual snapshots are deleted at the end of the snapshot retention period or when you manually delete them. You can disable automatic snapshot copy for a cluster at any time. When you disable this feature, snapshots are no longer copied from the source Amazon Region to the destination Amazon Region. Any automated snapshots copied to the destination Amazon Region are deleted as they reach the retention period limit, unless you create manual snapshot copies of them. These manual snapshots, and any manual snapshots that were copied from the destination Amazon Region, are kept in the destination Amazon Region until you manually delete them. To change the destination Amazon Region that you copy snapshots to, first disable the automatic copy feature. Then re-enable it, specifying the new destination Amazon Region. After a snapshot is copied to the destination Amazon Region, it becomes active and available for restoration purposes. To copy snapshots for Amazon KMS–encrypted clusters to another Amazon Region, create a grant for Amazon Redshift to use a customer managed key in the destination Amazon Region. Then choose that grant when you enable copying of snapshots in the source Amazon Region. For more information about configuring snapshot copy grants, see [Copying Amazon KMS–encrypted snapshots to another Amazon Web Services Region](working-with-db-encryption.md#configure-snapshot-copy-grant). # Restoring a cluster from a snapshot A snapshot contains data from any databases that are running on your cluster. It also contains information about your cluster, including the number of nodes, node type, and admin user name. If you restore your cluster from a snapshot, Amazon Redshift uses the cluster information to create a new cluster. Then it restores all the databases from the snapshot data. **Note** No-backup tables aren't supported for RA3 provisioned clusters and Amazon Redshift Serverless workgroups. A table marked as no-backup in an RA3 cluster or serverless workgroup is treated as a permanent table that will always be backed up while taking a snapshot, and always restored when restoring from a snapshot. For the new cluster created from the original snapshot, you can choose the configuration, such as node type and number of nodes. The cluster is restored in the same Amazon Region and a random, system-chosen Availability Zone, unless you specify another Availability Zone in your request. When you restore a cluster from a snapshot, you can optionally choose a compatible maintenance track for the new cluster. **Note** When you restore a snapshot to a cluster with a different configuration, the snapshot must have been taken on a cluster with cluster version 1.0.10013, or later. When a restore is in progress, events are typically emitted in the following order: 1. RESTORE\$1STARTED – REDSHIFT-EVENT-2008 sent when the restore process begins. 1. RESTORE\$1SUCCEEDED – REDSHIFT-EVENT-3003 sent when the new cluster has been created. The cluster is available for queries. 1. DATA\$1TRANSFER\$1COMPLETED – REDSHIFT-EVENT-3537 sent when data transfer complete. **Note** RA3 clusters only emit RESTORE\$1STARTED and RESTORE\$1SUCCEEDED events. There is no explicit data transfer to be done after a RESTORE succeeds because RA3 node types store data in Amazon Redshift managed storage. With RA3 nodes, data is continuously transferred between RA3 nodes and Amazon Redshift managed storage as part of normal query processing. RA3 nodes cache hot data locally and keep less frequently queried blocks in Amazon Redshift managed storage automatically. You can monitor the progress of a restore by either calling the [DescribeClusters](https://docs.amazonaws.cn/redshift/latest/APIReference/API_DescribeClusters.html) API operation, or viewing the cluster details in the Amazon Web Services Management Console. For an in-progress restore, these display information such as the size of the snapshot data, the transfer rate, the elapsed time, and the estimated time remaining. For a description of these metrics, see [RestoreStatus](https://docs.amazonaws.cn/redshift/latest/APIReference/API_RestoreStatus.html). You can't use a snapshot to revert an active cluster to a previous state. **Note** When you restore a snapshot into a new cluster, the default security group and parameter group are used unless you specify different values. You might want to restore a snapshot to a cluster with a different configuration for these reasons: + When a cluster is made up of smaller node types and you want to consolidate it into a larger node type with fewer nodes. + When you have monitored your workload and determined the need to move to a node type with more CPU and storage. + When you want to measure performance of test workloads with different node types. Restore has the following constraints: + The new node configuration must have enough storage for existing data. Even when you add nodes, your new configuration might not have enough storage because of the way that data is redistributed. + The restore operation checks if the snapshot was created on a cluster version that is compatible with the cluster version of the new cluster. If the new cluster has a version level that is too early, then the restore operation fails and reports more information in an error message. + The possible configurations (number of nodes and node type) you can restore to is determined by the number of nodes in the original cluster and the target node type of the new cluster. To determine the possible configurations available, you can use the Amazon Redshift console or the `describe-node-configuration-options` Amazon CLI command with `action-type restore-cluster`. For more information about the restoring using the Amazon Redshift console, see [Restoring a cluster from a snapshot](#working-with-snapshot-restore-cluster-from-snapshot). The following steps take a cluster with many nodes and consolidate it into a bigger node type with a smaller number of nodes using the Amazon CLI. For this example, we start with a source cluster of 24 nodes. In this case, suppose that we already created a snapshot of this cluster and want to restore it into a bigger node type. 1. Run the following command to get the details of our 24-node cluster. ``` aws redshift describe-clusters --region eu-west-1 --cluster-identifier mycluster-123456789012 ``` 1. Run the following command to get the details of the snapshot. ``` aws redshift describe-cluster-snapshots --region eu-west-1 --snapshot-identifier mycluster-snapshot ``` 1. Run the following command to describe the options available for this snapshot. ``` aws redshift describe-node-configuration-options --snapshot-identifier mycluster-snapshot --region eu-west-1 --action-type restore-cluster ``` This command returns an option list with recommended node types, number of nodes, and disk utilization for each option. For this example, the preceding command lists the following possible node configurations. We choose to restore into a three-node cluster. ``` { "NodeConfigurationOptionList": [ { "EstimatedDiskUtilizationPercent": 65.26134808858235, "NodeType": "dc2.large", "NumberOfNodes": 24 }, { "EstimatedDiskUtilizationPercent": 32.630674044291176, "NodeType": "dc2.large", "NumberOfNodes": 48 }, { "EstimatedDiskUtilizationPercent": 65.26134808858235, "NodeType": "dc2.8xlarge", "NumberOfNodes": 3 }, { "EstimatedDiskUtilizationPercent": 48.94601106643677, "NodeType": "dc2.8xlarge", "NumberOfNodes": 4 }, { "EstimatedDiskUtilizationPercent": 39.156808853149414, "NodeType": "dc2.8xlarge", "NumberOfNodes": 5 }, { "EstimatedDiskUtilizationPercent": 32.630674044291176, "NodeType": "dc2.8xlarge", "NumberOfNodes": 6 } ] } ``` 1. Run the following command to restore the snapshot into the cluster configuration that we chose. After this cluster is restored, we have the same content as the source cluster, but the data has been consolidated into three `dc2.8xlarge` nodes. ``` aws redshift restore-from-cluster-snapshot --region eu-west-1 --snapshot-identifier mycluster-snapshot --cluster-identifier mycluster-123456789012-x --node-type dc2.8xlarge --number-of-nodes 3 ``` If you have reserved nodes, for example DC2 reserved nodes, you can upgrade to RA3 reserved nodes. You can do this when you restore from a snapshot or perform an elastic resize. You can use the console to guide you through this process. For more information about upgrading to RA3 nodes, see [Upgrading to RA3 node types](https://docs.amazonaws.cn/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3). **To restore a cluster from a snapshot on the console** 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the snapshot to restore. 1. Choose **Restore from snapshot** to view the **Cluster configuration** and **Cluster details** values of the new cluster to be created using the snapshot information. 1. Update the properties of the new cluster, then choose **Restore cluster from snapshot**. After restoring your cluster snapshot, the restored data warehouse is encrypted with the same custom Amazon KMS key that it was using at the time that the snapshot was taken. If the snapshot didn't have a custom KMS key, Amazon Redshift's backup encryption logic depends on the following factors: + The type of Amazon Redshift data warehouse you're restoring the snapshot to. + The encryption type of the cluster at the time the snapshot was taken. To learn how your data warehouse is encrypted after you restore it from your cluster snapshot, see the following table: | Destination type | Snapshot encryption type | Destination encryption type | | --- | --- | --- | | Provisioned cluster | Encrypted with an Amazon managed key | Encrypted with an Amazon managed key | | Provisioned cluster | Encrypted with an Amazon owned key | Encrypted with an Amazon owned key | | Serverless namespace | Encrypted with an Amazon managed key | Encrypted with an Amazon owned key | | Serverless namespace | Encrypted with an Amazon owned key | Encrypted with an Amazon owned key | If Amazon Secrets Manager managed your cluster's admin password at the time the snapshot was taken, you must continue using Amazon Secrets Manager to manage the admin password. You can opt out of using a secret after restoring the cluster by updating the cluster's admin credentials in the cluster detail page. If you have reserved nodes, you can upgrade to RA3 reserved nodes. You can do this when you restore from a snapshot or perform an elastic resize. You can use the console to guide you through this process. For more information about upgrading to RA3 nodes, see [Upgrading to RA3 node types](https://docs.amazonaws.cn/redshift/latest/mgmt/working-with-clusters.html#rs-upgrading-to-ra3). # Restoring a table from a snapshot You can restore a single table from a snapshot instead of restoring an entire cluster. When you restore a single table from a snapshot, you specify the source snapshot, database, schema, and table name, and the target database, schema, and a new table name for the restored table. **Note** No-backup tables aren't supported for RA3 provisioned clusters and Amazon Redshift Serverless workgroups. A table marked as no-backup in an RA3 cluster or serverless workgroup is treated as a permanent table that will always be backed up while taking a snapshot, and always restored when restoring from a snapshot. However, selective restoration of no-backup tables isn't supported. The new table name cannot be the name of an existing table. To replace an existing table with a restored table from a snapshot, rename or drop the existing table before you restore the table from the snapshot. The target table is created using the source table's column definitions, table attributes, and column attributes except for foreign keys. To prevent conflicts due to dependencies, the target table doesn't inherit foreign keys from the source table. Any dependencies, such as views or permissions granted on the source table, aren't applied to the target table. If the owner of the source table exists, then that database user is the owner of the restored table, provided that the user has sufficient permissions to become the owner of a relation in the specified database and schema. Otherwise, the restored table is owned by the admin user that was created when the cluster was launched. The restored table returns to the state it was in at the time the backup was taken. This includes transaction visibility rules defined by the Amazon Redshift adherence to [serializable isolation](https://docs.amazonaws.cn/redshift/latest/dg/c_serial_isolation.html), meaning that data will be immediately visible to in flight transactions started after the backup. Restoring a table from a snapshot has the following limitations: + You can restore a table only to the current, active running cluster and from a snapshot that was taken of that cluster. + You can restore only one table at a time. + You can't restore a table from a cluster snapshot that was taken prior to a cluster being resized. An exception is that you can restore a table after an elastic resize if the node type didn't change. + Any dependencies, such as views or permissions granted on the source table, aren't applied to the target table. + If row-level security is turned on for a table being restored, Amazon Redshift restores the table with row-level security turned on. **To restore a table from a snapshot** 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, then choose the cluster that you want to use to restore a table. 1. For **Actions**, choose **Restore table** to display the **Restore table** page. 1. Enter the information about which snapshot, source table, and target table to use, and then choose **Restore table**. **Example: Restoring a table from a snapshot using the Amazon CLI** The following example uses the `restore-table-from-cluster-snapshot` Amazon CLI command to restore the `my-source-table` table from the `sample-database` schema in the `my-snapshot-id`. You can use the Amazon CLI command `describe-table-restore-status` to review the status of your restore operation. The example restores the snapshot to the `mycluster-example` cluster with a new table name of `my-new-table`. ``` aws redshift restore-table-from-cluster-snapshot --cluster-identifier mycluster-example --new-table-name my-new-table --snapshot-identifier my-snapshot-id --source-database-name sample-database --source-table-name my-source-table ``` # Restoring a serverless namespace from a snapshot Restoring a serverless namespace from a snapshot replaces all of the namespace’s databases with databases in the snapshot. For more information about serverless snapshots, see [Snapshots and recovery points](https://docs.amazonaws.cn/redshift/latest/mgmt/serverless-snapshots-recovery-points.html). Amazon Redshift automatically converts tables with interleaved keys into compound keys when you restore a provisioned cluster snapshot to an Amazon Redshift Serverless namespace. For more information about sort keys, see [Working with sort keys](https://docs.amazonaws.cn/redshift/latest/dg/t_Sorting_data.html). To restore a snapshot from your provisioned cluster to your serverless namespace. 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the snapshot to use. 1. Choose **Restore from snapshot**, **Restore to serverless namespace**. 1. Choose the namespace you want to restore to. 1. Confirm you want to restore from your snapshot. Choose **restore**. This action replaces all the databases in serverless namespace with the data from your provisioned cluster. # Configuring cross-Region snapshot copy for a nonencrypted cluster You can configure Amazon Redshift to copy snapshots for a cluster to another Amazon Region. To configure cross-Region snapshot copy, you need to enable this copy feature for each cluster and configure where to copy snapshots and how long to keep copied automated or manual snapshots in the destination Amazon Region. When cross-Region copy is enabled for a cluster, all new manual and automated snapshots are copied to the specified Amazon Region. Copied snapshot names are prefixed with **copy:**. **To configure a cross-Region snapshot** 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, then choose the cluster that you want to move snapshots for. 1. For **Actions**, choose **Configure cross-region snapshot**. The Configure cross-Region dialog box appears. 1. For **Copy snapshots**, choose **Yes**. 1. In **Destination Amazon Region**, choose the Amazon Region to which to copy snapshots. 1. In **Automated snapshot retention period (days)**, choose the number of days for which you want automated snapshots to be retained in the destination Amazon Region before they are deleted. 1. In **Manual snapshot retention period**, choose the value that represents the number of days for which you want manual snapshots to be retained in the destination Amazon Region before they are deleted. If you choose **Custom value**, the retention period must be between 1 to 3653 days. 1. Choose **Save**. # Configuring cross-Region snapshot copy for an Amazon KMS–encrypted cluster When you launch an Amazon Redshift cluster, you can configure a snapshot copy grant for a root key in your account in the destination Amazon Web Services Region. If you don't configure a grant, snapshots in the destination region are encrypted with a default Amazon-owned key. By doing this, you enable Amazon Redshift to perform encryption operations in the destination Amazon Region. The following procedure describes the process of enabling cross-Region snapshot copy for an Amazon KMS-encrypted cluster. For more information about encryption in Amazon Redshift and snapshot copy grants, see [Copying Amazon KMS–encrypted snapshots to another Amazon Web Services Region](working-with-db-encryption.md#configure-snapshot-copy-grant). **To configure a cross-Region snapshot for an Amazon KMS–encrypted cluster** 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, then choose the cluster that you want to move snapshots for. 1. For **Actions**, choose **Configure cross-region snapshot**. The Configure cross-Region dialog box appears. 1. For **Copy snapshots**, choose **Yes**. 1. In **Destination Amazon Region**, choose the Amazon Region to which to copy snapshots. 1. In **Automated snapshot retention period (days)**, choose the number of days for which you want automated snapshots to be retained in the destination Amazon Region before they are deleted. 1. In **Manual snapshot retention period**, choose the value that represents the number of days for which you want manual snapshots to be retained in the destination Amazon Region before they are deleted. If you choose **Custom value**, the retention period must be between 1 to 3653 days. 1. Choose **Save**. # Modifying the manual snapshot retention period You can change the retention period for a manual snapshot by modifying the snapshot settings. **To change the manual snapshot retention period** 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the manual snapshot to change. 1. For **Actions**, choose **Manual snapshot settings** to display the properties of the manual snapshot. 1. Enter the revised properties of the snapshot definition, then choose **Save**. # Modifying the retention period for cross-Region snapshot copy After you configure cross-Region snapshot copy, you might want to change the settings. You can easily change the retention period by selecting a new number of days and saving the changes. **Warning** You can't modify the destination Amazon Region after cross-Region snapshot copy is configured. If you want to copy snapshots to a different Amazon Region, first disable cross-Region snapshot copy. Then re-enable it with a new destination Amazon Region and retention period. Any copied automated snapshots are deleted after you disable cross-Region snapshot copy. Thus, you should determine if there are any that you want to keep and copy them to manual snapshots before disabling cross-Region snapshot copy. **To modify a cross-Region snapshot** 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, then choose the cluster that you want to modify snapshots for. 1. For **Actions**, choose **Configure cross-region snapshot** to display the properties of the snapshot. 1. Enter the revised properties of the snapshot definition, then choose **Save**. # Deleting a manual snapshot You can delete manual snapshots by selecting one or more snapshots in the snapshot list. **To delete a manual snapshot** 1. Sign in to the Amazon Web Services Management Console and open the Amazon Redshift console at [https://console.amazonaws.cn/redshiftv2/](https://console.amazonaws.cn/redshiftv2/). 1. On the navigation menu, choose **Clusters**, **Snapshots**, then choose the snapshot to delete. 1. For **Actions**, choose **Delete snapshot** to delete the snapshot. 1. Confirm the deletion of the listed snapshots, then choose **Delete**.