Restoring a Redshift backup recreates a cluster or reloads data from a snapshot or SQL dump into a new or existing environment.
Disaster recovery, data corruption, or environment cloning often require restoring a Redshift snapshot or SQL dump. Snapshots rebuild an entire cluster, while SQL dumps let you reload only selected objects.
You can 1) create a new cluster from an automatic/manual snapshot, or 2) replay a .sql
dump with psql
.Choose snapshots for full-cluster recovery and psql
for granular control.
Open Redshift ➜ Snapshots ➜ pick snapshot ➜ Restore. Specify Cluster identifier, node type, VPC, and port. The service spins up a new cluster and automatically loads all data.
Run aws redshift restore-from-cluster-snapshot --cluster-identifier ecommerce-restore --snapshot-identifier ecommerce-snap-2023-09-01 --node-type ra3.xlplus --port 5439 --publicly-accessible
.Monitor status with describe-clusters
.
Create an empty target database, then execute psql -h endpoint -U admin -d ecommerce -f ecommerce_backup.sql
.The script re-creates tables like Customers
, Orders
, and inserts the data.
Enable automated snapshots, keep manual snapshots before major DDL, restore to a staging cluster first, and validate row counts using queries such as SELECT COUNT(*) FROM Orders
.
Avoid restoring to the original cluster without backups of current data, and remember to open security-group ingress for your IP when replaying a psql
dump.
.
No. Redshift snapshots create a new cluster unless you deliberately choose the original identifier and delete the existing cluster first.
Snapshots are all-or-nothing. For table-level restore, export the data to S3, then COPY
it back or replay a SQL dump.
Cluster size, node type, and region affect duration. Small clusters restore in minutes; multi-terabyte RA3 clusters can take hours.