Busca en todas las páginas de la documentación
A Redshift cluster's durability comes from snapshots - point-in-time backups stored in S3. AWS takes automated ones for you on a schedule, and you take manual ones from the SDK when you want a backup that outlives the automated retention window. Recovery and cloning both go the other way: RestoreFromClusterSnapshot builds a fresh cluster from any snapshot.
Disaster recovery adds a region dimension. A snapshot in the same region as the cluster does not survive a regional outage, so you configure Redshift to copy snapshots to a second region automatically. This page covers manual snapshots, cross-region copy, and restore, all from the redshift client.
Quick-reference recipe card - copy-paste ready.
# --- Python (boto3) ---
import boto3
rs = boto3.client("redshift", region_name="us-east-1")
# Manual snapshot you control retention on.
rs.create_cluster_snapshot(
SnapshotIdentifier="analytics-2026-07-23",
ClusterIdentifier="analytics-cluster",
ManualSnapshotRetentionPeriod=30, # days; -1 keeps indefinitely
)
# Turn on automatic cross-region copy for DR.
rs.enable_snapshot_copy(
ClusterIdentifier="analytics-cluster",
DestinationRegion="us-west-2",
RetentionPeriod=7, # days retained in the destination region
)// --- TypeScript (AWS SDK v3) ---
import {
RedshiftClient, CreateClusterSnapshotCommand, EnableSnapshotCopyCommand,
} from "@aws-sdk/client-redshift";
const rs = new RedshiftClient({ region: "us-east-1" });
// Manual snapshot you control retention on.
await rs.send(new CreateClusterSnapshotCommand({
SnapshotIdentifier: "analytics-2026-07-23",
ClusterIdentifier: "analytics-cluster",
ManualSnapshotRetentionPeriod: 30, // days; -1 keeps indefinitely
}));
// Turn on automatic cross-region copy for DR.
await rs.send(new EnableSnapshotCopyCommand({
ClusterIdentifier: "analytics-cluster",
DestinationRegion: "us-west-2",
RetentionPeriod: 7, // days retained in the destination region
}));When to reach for this:
Take a manual snapshot and wait for it, retain a copy of an automated snapshot, enable cross-region copy, then restore a new cluster from a snapshot. Snapshot operations are asynchronous, so you poll DescribeClusterSnapshots for status.
# --- Python (boto3) ---
import boto3, time
rs = boto3.client("redshift", region_name="us-east-1")
# 1. Take a manual snapshot and wait until it is available.
rs.create_cluster_snapshot(
SnapshotIdentifier="analytics-2026-07-23",
ClusterIdentifier="analytics-cluster",
ManualSnapshotRetentionPeriod=30,
)
while True:
snap = rs.describe_cluster_snapshots(SnapshotIdentifier="analytics-2026-07-23")["Snapshots"][0]
if snap["Status"] == "available":
break
time.sleep(30)
print("snapshot ready:", snap["SnapshotIdentifier"])
# 2. Promote an automated snapshot to a durable manual copy (same region).
rs.copy_cluster_snapshot(
SourceSnapshotIdentifier="rs:analytics-cluster-2026-07-22-06-00",
TargetSnapshotIdentifier="analytics-keep-2026-07-22",
ManualSnapshotRetentionPeriod=-1, # keep indefinitely
)
# 3. Enable automatic cross-region copy for DR.
rs.enable_snapshot_copy(
ClusterIdentifier="analytics-cluster",
DestinationRegion="us-west-2",
RetentionPeriod=7,
)
# 4. Restore a NEW cluster from a snapshot (recovery or clone).
rs.restore_from_cluster_snapshot(
ClusterIdentifier="analytics-restored",
SnapshotIdentifier="analytics-2026-07-23",
PubliclyAccessible=False,
)
print("restore started")// --- TypeScript (AWS SDK v3) ---
import {
RedshiftClient, CreateClusterSnapshotCommand, DescribeClusterSnapshotsCommand,
CopyClusterSnapshotCommand, EnableSnapshotCopyCommand, RestoreFromClusterSnapshotCommand,
} from "@aws-sdk/client-redshift";
const rs = new RedshiftClient({ region: "us-east-1" });
const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms));
// 1. Take a manual snapshot and wait until it is available.
await rs.send(new CreateClusterSnapshotCommand({
SnapshotIdentifier: "analytics-2026-07-23",
ClusterIdentifier: "analytics-cluster",
ManualSnapshotRetentionPeriod: 30,
}));
let snap;
for (;;) {
const out = await rs.send(new DescribeClusterSnapshotsCommand({
SnapshotIdentifier: "analytics-2026-07-23",
}));
snap = out.Snapshots![0];
if (snap.Status === "available") break;
await sleep(30_000);
}
console.log("snapshot ready:", snap.SnapshotIdentifier);
// 2. Promote an automated snapshot to a durable manual copy (same region).
await rs.send(new CopyClusterSnapshotCommand({
SourceSnapshotIdentifier: "rs:analytics-cluster-2026-07-22-06-00",
TargetSnapshotIdentifier: "analytics-keep-2026-07-22",
ManualSnapshotRetentionPeriod: -1, // keep indefinitely
}));
// 3. Enable automatic cross-region copy for DR.
await rs.send(new EnableSnapshotCopyCommand({
ClusterIdentifier: "analytics-cluster",
DestinationRegion: "us-west-2",
RetentionPeriod: 7,
}));
// 4. Restore a NEW cluster from a snapshot (recovery or clone).
await rs.send(new RestoreFromClusterSnapshotCommand({
ClusterIdentifier: "analytics-restored",
SnapshotIdentifier: "analytics-2026-07-23",
PubliclyAccessible: false,
}));
console.log("restore started");What this demonstrates:
CreateClusterSnapshot takes a manual backup; you poll DescribeClusterSnapshots for available.CopyClusterSnapshot promotes an automated snapshot to a manual one that will not be aged out.EnableSnapshotCopy sets up ongoing automatic cross-region copy - the DR control.RestoreFromClusterSnapshot always creates a new cluster; it never overwrites the source.Redshift takes automated snapshots to S3 continuously (roughly every 8 hours or per data change) and keeps them for a retention period you set on the cluster (default 1 day, up to 35). They are deleted when the cluster is deleted or when they age out. A manual snapshot from CreateClusterSnapshot is yours: it persists until you delete it, and ManualSnapshotRetentionPeriod sets how long (-1 keeps it indefinitely). Take a manual snapshot before anything risky and for backups that must outlive the automated window.
Snapshots are incremental. Each stores only the blocks that changed since the last one, so they are cheap and fast after the first full backup. A restore reassembles the full state transparently.
A snapshot lives in the same region as its cluster, so it does not protect against a regional failure on its own. EnableSnapshotCopy configures the cluster to automatically copy new snapshots to a DestinationRegion, with its own RetentionPeriod there (and a separate manual-snapshot retention). This is the mechanism to reach for when someone says "cross-region backup" - it keeps the destination region continuously up to date without a per-snapshot call.
CopyClusterSnapshot, by contrast, makes a durable manual copy of a snapshot - most often promoting an automated snapshot to a retained manual one so it survives aging - and is scoped to the region. Use EnableSnapshotCopy for the ongoing cross-region stream and CopyClusterSnapshot to pin a specific snapshot you must keep. To encrypt copied snapshots in the destination region with a KMS key there, pass SnapshotCopyGrantName.
RestoreFromClusterSnapshot never restores in place - it always provisions a new cluster from the snapshot. That is what makes it useful for both recovery (bring up a replacement in a healthy region) and cloning (spin up a copy of production for testing). You can override attributes at restore time: NodeType, NumberOfNodes, VpcSecurityGroupIds, PubliclyAccessible, and more. To restore into another region, run the restore against that region's endpoint using a snapshot already copied there. For a serverless namespace, the parallel calls are RestoreFromSnapshot / RestoreFromRecoveryPoint on the redshift-serverless client.
Redshift Serverless does the same job with different names. It automatically maintains recovery points (retained about 24 hours) and lets you take manual snapshots with CreateSnapshot on the redshift-serverless client, with their own retention. You restore a namespace from either. Cross-region copy for serverless is configured with a snapshot copy configuration rather than EnableSnapshotCopy.
EnableSnapshotCopy with a DestinationRegion for cross-region DR.SnapshotCopyGrantName.create_cluster_snapshot does not apply to serverless. Fix: use redshift-serverless CreateSnapshot/RestoreFromSnapshot.| Alternative | Use When | Don't Use When |
|---|---|---|
| Automated snapshots | Baseline point-in-time recovery with no effort | You need retention beyond 35 days or after cluster deletion |
| Manual snapshot (CreateClusterSnapshot) | Backup before risky changes; long/indefinite retention | A routine backup already covered by automation |
| EnableSnapshotCopy (cross-region) | Ongoing disaster recovery to a second region | Everything is fine in one region and DR is not required |
| CopyClusterSnapshot | Pinning a specific automated snapshot as durable | You need continuous copying (use EnableSnapshotCopy) |
| RestoreFromClusterSnapshot | Recovery or cloning into a new cluster | In-place rollback (not supported; restore is always new) |
| UNLOAD to S3 | Portable, engine-agnostic export of query results | Full-fidelity cluster restore (snapshots do that) |
Automated snapshots are taken by Redshift on a schedule and kept for a retention period (up to 35 days), then deleted - and they vanish when the cluster is deleted. Manual snapshots from CreateClusterSnapshot persist until you delete them, with retention you control, including indefinitely.
Call EnableSnapshotCopy on the cluster with a DestinationRegion and a retention period. Redshift then automatically copies new snapshots to that region, keeping it continuously current for disaster recovery without a per-snapshot call.
No. CopyClusterSnapshot makes a durable manual copy within a region - typically promoting an automated snapshot so it is not aged out. For cross-region copying, use EnableSnapshotCopy with a destination region.
No. RestoreFromClusterSnapshot always provisions a brand-new cluster from the snapshot. That is why it serves both recovery (a replacement cluster) and cloning (a copy for testing). You then repoint clients or DNS to the new cluster.
Yes. Restore accepts overrides such as NodeType, NumberOfNodes, VpcSecurityGroupIds, and PubliclyAccessible, so you can restore into a differently sized or differently networked cluster than the source.
Incremental. After the first full backup, each snapshot stores only the blocks that changed since the previous one, making them cheap and quick. A restore reassembles the complete state from the incremental chain automatically.
You need a snapshot copy grant so Redshift can re-encrypt the snapshot with a KMS key in the destination region. Create the grant and pass SnapshotCopyGrantName when enabling snapshot copy; without it, encrypted cross-region copy fails.
Serverless keeps automatic recovery points (about 24 hours) and lets you take manual snapshots with CreateSnapshot on the redshift-serverless client. You restore a namespace from either, and configure cross-region copy through a snapshot copy configuration rather than EnableSnapshotCopy.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última actualización: 23 jul 2026