This page provides information to review before restoring an instance from a backup.
General tips about performing a restore
When you restore an instance from a backup, whether to the same instance or to a different instance, keep in mind the following items:
- The restore operation overwrites all data on the target instance.
- The target instance is unavailable for connections during the restore operation; existing connections are lost.
- If you are restoring to an instance with read replicas, you must delete all replicas and recreate them after the restore operation completes.
- The restore operation restarts the instance.
For step-by-step instructions for performing a restore, see:
Tips and requirements for restoring to a different instance
When you are restoring a backup to a different instance, keep in mind the following restrictions and best practices:
The target instance must have the same database version and edition as the instance from which the backup was taken.
The storage capacity of the target instance must be at least as large as the capacity of the instance being backed up. The amount of storage being used does not matter. You can see the storage capacity of the instance in the console Cloud SQL instances page
The target instance must be in the
The target instance can have a different number of cores or amount of memory than the instance from which the backup was taken.
The target instance can be in a different region from the source instance.
During an outage, you can still retrieve a list of backups in a particular project. See Viewing backups during an outage.
Restore rate limitations
You are allowed a maximum of three restore operations every 30 minutes per instance per region per project. If a restore operation fails, it does not count towards this quota. If you reach the limit, the operation fails with an error message that tells you when you can run the operation again.
Let's take a look at how Cloud SQL performs rate limiting for restores.
Cloud SQL uses tokens from a bucket to determine how many restore operations are available at any one time. For each backup, there's a bucket for each target project and target region. The target instances from the same project share one bucket if they are in the same region. There's a maximum of three tokens in each bucket that you can use for restore operations. Every 10 minutes, a new token is added to the bucket. If the bucket is full, the token overflows.
Each time you issue a restore operation, a token is granted from the bucket. If the operation succeeds, the token is removed from the bucket. If it fails, the token is returned to the bucket. The following diagram shows how this works:
For example, in the following figure, Backup1, Backup2, and Backup3 are the backups from the same source instance.
- Each backup (Backup1, Backup2, and Backup3) has its own bucket of tokens for restore operations that target different instances in Project 1 in Region A (Bucket11A, Bucket21A, and Bucket31A). Because each backup has its own bucket, you can restore each backup to the same instance three times every thirty minutes.
- Each backup has a bucket for a separate project and for a separate region.
For example, if there are five projects in a region, there are five
buckets for that backup in that region, one in each project. In the previous
figure, we have two projects in region A: Project 1 and Project n.
- Backup1 has two buckets of tokens for restore operations in Region A. One bucket for Project 1 (Bucket11A), and one bucket for Project n (Bucket1nA).
- Similarly, Backup3 has two buckets for restore operations in Region A. One for Project 1 (Bucket31A) and one for Project n (Bucket3nA).
- Backup3 has one bucket in Region B, for Project1, because all instances in the same target project and the same target region share one bucket.