Most Redshift teams can tell you their node type and their monthly bill. Far fewer can tell you how much data they would lose if their warehouse namespace were deleted at 3pm on a Tuesday, or how long it would take to serve queries again from another Region. Automated snapshots are on by default, which is exactly why backup and recovery tends to go unexamined until the day it matters.
This tutorial covers what Redshift actually backs up, how snapshots differ between provisioned clusters and Serverless, how to get copies out of the Region and out of the account, how to restore a single table instead of a whole warehouse, and how to write down an RPO and RTO you can defend.
What Redshift backs up for you, and what it doesn't
Redshift continuously backs up your data to Amazon S3 in the background. Two things follow from that:
- Snapshots are incremental. After the first one, each snapshot stores only changed blocks, so a daily schedule is far cheaper than the raw data size suggests.
- Snapshots are warehouse-wide. There is no "snapshot this schema" — the unit of backup is the cluster or the Serverless namespace.
What is not covered by a snapshot:
| Asset | In a snapshot? | How to protect it |
|---|---|---|
| Table data, schemas, users, permissions | Yes | Snapshot |
| Data in RMS (RA3/Serverless managed storage) | Yes | Snapshot |
| External tables in Glue Data Catalog / Spectrum / Iceberg | No — only the metadata pointer | S3 versioning + Glue catalog backup |
| Parameter groups, WLM config, workgroup settings | No | Infrastructure as code |
| VPC, subnet groups, security groups, IAM roles | No | Infrastructure as code |
| Scheduled queries, COPY JOBs, Query Editor v2 saved queries | Partially / no | Source control |
The practical consequence: a snapshot restore gives you data back, not a working environment. If your workgroup, IAM role association and network config exist only as console clicks, your recovery time is bounded by how fast someone can reconstruct them from memory. Terraform or CloudFormation for the warehouse's surrounding resources is a recovery control, not just a hygiene preference.
Automated snapshots and the retention window
For a provisioned cluster, automated snapshots default to a 1-day retention on some creation paths and are commonly left there. Raise it deliberately:
aws redshift modify-cluster \
--cluster-identifier analytics-prod \
--automated-snapshot-retention-period 14
Retention can go up to 35 days for automated snapshots. Manual snapshots you take yourself have no automatic expiry unless you set one — which is a cost trap as much as a safety net.
Take a manual snapshot before anything irreversible (a major schema migration, a node-type change, a bulk delete):
aws redshift create-cluster-snapshot \
--cluster-identifier analytics-prod \
--snapshot-identifier pre-scd2-migration-2026-02-11 \
--manual-snapshot-retention-period 30
You can also set a custom snapshot schedule (for example every 4 hours during the load window, daily otherwise) with create-snapshot-schedule and attach it to the cluster. Snapshot frequency is the single biggest lever on your RPO, so set it from the RPO number rather than from habit.
Serverless: recovery points, not snapshots
Redshift Serverless does the same thing under different nouns. It creates recovery points roughly every 30 minutes and keeps them for 24 hours. That is your default RPO on Serverless: about half an hour, with a one-day window to notice a problem.
If you need to keep one longer, convert it into a snapshot:
aws redshift-serverless list-recovery-points \
--namespace-name analytics-prod-ns \
--start-time 2026-02-11T00:00:00Z
aws redshift-serverless convert-recovery-point-to-snapshot \
--recovery-point-id <recovery-point-id> \
--snapshot-name pre-scd2-migration-2026-02-11 \
--retention-period 30
And you can schedule your own Serverless snapshots:
aws redshift-serverless create-snapshot \
--namespace-name analytics-prod-ns \
--snapshot-name nightly-2026-02-11 \
--retention-period 14
A 24-hour recovery-point window is not a backup strategy on its own. A corrupted dimension table that nobody notices until the Monday morning dashboard review is already outside it. Schedule daily snapshots with meaningful retention on top.
Getting copies out of the Region
Region-level failure is rare; Region-level unavailability long enough to hurt is not. Cross-Region snapshot copy is the cheap insurance.
For provisioned clusters:
aws redshift enable-snapshot-copy \
--cluster-identifier analytics-prod \
--destination-region us-west-2 \
--retention-period 7 \
--snapshot-copy-grant-name analytics-prod-uswest2-grant
If the cluster is encrypted with a KMS key — it should be — you need a snapshot copy grant in the destination Region first, created against a KMS key that lives there:
aws redshift create-snapshot-copy-grant \
--snapshot-copy-grant-name analytics-prod-uswest2-grant \
--kms-key-id arn:aws:kms:us-west-2:111111111111:key/abcd-1234 \
--region us-west-2
Forgetting the grant is the single most common reason cross-Region copy silently fails to be enabled at the moment it is needed.
For Serverless, copy configuration is per namespace:
aws redshift-serverless create-snapshot-copy-configuration \
--namespace-name analytics-prod-ns \
--destination-region us-west-2 \
--snapshot-retention-period 7
Budget for the cross-Region data transfer and the duplicate storage; both are real, and both are small next to a multi-day outage.
Out of the account, too
Ransomware and fat-fingered delete-cluster --skip-final-cluster-snapshot are account-level events. Cross-Region copy inside the same account does not protect you from either. Two options:
- Share the snapshot with a dedicated backup account (
authorize-snapshot-access --account-with-restore-access 222222222222) and have that account copy it to storage it controls. - Unload to S3 in a separate account with Object Lock in compliance mode for the tables that genuinely must survive anything:
UNLOAD ('SELECT * FROM finance.gl_entries WHERE posted_date >= ''2026-01-01''')
TO 's3://acme-dw-archive/gl_entries/2026-01/'
IAM_ROLE 'arn:aws:iam::111111111111:role/RedshiftUnload'
FORMAT AS PARQUET
PARTITION BY (posted_date)
CLEANPATH;
Parquet in S3 is also the format your recovery has the most options for: Spectrum, Athena, Iceberg, or a plain COPY back in.
Restoring: the three shapes of recovery
1. Restore a whole warehouse. A restore creates a new cluster or namespace; it never overwrites the existing one. That means the restore itself is safe to rehearse.
aws redshift restore-from-cluster-snapshot \
--cluster-identifier analytics-dr \
--snapshot-identifier pre-scd2-migration-2026-02-11 \
--cluster-subnet-group-name dw-subnets \
--publicly-accessible false
On RA3 and Serverless the cluster becomes available before all data is hydrated from S3; queries against not-yet-restored blocks pull them on demand, so early queries are slower but the warehouse is usable in minutes rather than hours. On Serverless:
aws redshift-serverless restore-from-snapshot \
--namespace-name analytics-dr-ns \
--workgroup-name analytics-dr-wg \
--snapshot-arn arn:aws:redshift-serverless:us-west-2:111111111111:snapshot/nightly-2026-02-11
2. Restore a single table. This is the one most teams don't know exists, and it is the answer to 80% of real incidents — a bad MERGE, a truncate against the wrong environment.
aws redshift restore-table-from-cluster-snapshot \
--cluster-identifier analytics-prod \
--snapshot-identifier rs:analytics-prod-2026-02-11-06-00 \
--source-database-name warehouse \
--source-schema-name sales \
--source-table-name fct_orders \
--target-database-name warehouse \
--target-schema-name recovery \
--new-table-name fct_orders_restored
The target table must not already exist, and it lands as a new table — you then reconcile and swap. Restoring into a recovery schema rather than over the top of production is deliberate: it lets you diff before you commit.
Serverless has the equivalent redshift-serverless restore-table-from-snapshot (and restore-table-from-recovery-point).
3. Recover a dropped object without any snapshot. If you are inside the transaction, ROLLBACK. If the load pattern is append-only and partitioned in S3, re-running the COPY is faster than any restore. Design ELT so that "re-run yesterday" is a normal operation and you convert a class of DR events into a Tuesday-afternoon rerun.
Writing down an RPO and RTO you can defend
Pick the numbers per workload, not per company:
| Workload | Typical RPO | Typical RTO | Configuration that gets you there |
|---|---|---|---|
| Finance / regulated reporting | 1 hour | 4 hours | 1-hour snapshot schedule, cross-Region copy, IaC for the environment, quarterly restore drill |
| Standard BI warehouse | 24 hours | 24 hours | Daily snapshot, 14-day retention, cross-Region copy of the daily |
| Dev / sandbox | 7 days | Best effort | Default automated snapshots, rebuild from prod snapshot |
Then close the loop with two things most teams skip:
- Monitor that backups exist. An EventBridge rule on Redshift snapshot events into SNS, plus a weekly check that
describe-cluster-snapshotsshows what you expect. A backup regime nobody checks is a backup regime that failed silently three months ago. - Rehearse the restore, in the DR Region, with a stopwatch. Restore to a small workgroup, run five representative queries, record the elapsed time, then delete it. Your RTO is whatever that stopwatch says — not what the runbook claims.
A minimum viable Redshift DR posture
If you do nothing else this quarter:
- Set automated snapshot retention to at least 7 days (Serverless: schedule daily snapshots — recovery points alone are 24 hours).
- Enable cross-Region snapshot copy, with the KMS snapshot copy grant in place.
- Put workgroup, parameter group, IAM role and network config into Terraform or CloudFormation.
- Take a manual snapshot before every schema migration, with an explicit retention period.
- Run one restore drill and write the measured RTO into the runbook.
That is roughly a day of work and it converts an unknown into a number you can put in front of an auditor.
RougeWarehouse builds and operates Amazon Redshift warehouses for organizations that need the numbers to be right. If you would like a second pair of eyes on your backup, DR and recovery posture — or help rehearsing a restore before you have to do it for real — get in touch.