This page provides information to review before restoring an instancefrom a backup or performing a point-in-time recovery (PITR).

Note: This page contains features related to Cloud SQL editions. For more information about Cloud SQL editions, seeIntroduction to Cloud SQL editions.

What happens during a restore?

For Cloud SQL Enterprise edition and Cloud SQL Enterprise Plus edition, you can restore an instance from a backup. You can also restore backups across instances of different editions.

When you restore an instance, the following data from the primary instanceare restored to the new instance:

• Databases
• Users

Note: The flags from the primary instance are not restored. Any flags previouslyset on the target instance are retained after the restore.

The restore operation causes the instance to restart.

Point-in-time recovery (PITR)

Point-in-time recovery (PITR) helps you recover an instance to a specific point intime. For example, if an error causes a loss of data, you can recover a databaseto its state before the error occurred.

PITR always creates a new instance; you can't perform aPITR to an existing instance. The new instance inherits thesettings of the source instance, similar to howclone creation works.

When you create a Cloud SQL instance in the Google Cloud console,PITR is enabled by default.

PITR useswrite-ahead logging (WAL) archiving.By default, PITR is enabled for Cloud SQL Enterprise Plus edition instances.

When you restore a backup on a Cloud SQL instance before enablingPITR, you lose the archived logs that let you usePITR. If the size of your write-ahead logs ondisk is causing performance issues for your instance, then deactivatePITR and re-enable it. This action ensures that new logsare stored in Cloud Storage instead of on disk.

Caution: If you deactivate and re-enable PITR, then anyexisting logs are deleted, and you won't be able to performPITR earlier than the time that you re-enabled it. EnablingPITR requires restarting the database.

For step-by-step instructions for performing PITR, seeUse point-in-time recovery (PITR).

Restore an unavailable instance

You can use PITR to restore a Cloud SQL instance that isn't available. PITR typically offers a recovery point objective (RPO) of five minutes or less.

If the instance is unavailable, then you can use the API tocheck for the latest time to which you can restore the instance and perform the recovery to that time. If the zone in which the instance is configured isn't accessible, then you canrestore the instance to a different primary or secondary zone by providing values for the preferred zones.

Suppose a Cloud SQL instance becomes unavailable at 4 PM EST. If the latest recovery time is at 3:55 PM EST, then you can recover the instance up to this time.

General tips about performing a restore

When you restore an instance from a backup, whether to the same instance or toa 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 restoreoperation; existing connections are lost.
• If you are restoring to an instance with readreplicas, you must delete all replicas and recreate them after the restoreoperation completes.
• The restore operation restarts the instance.

For step-by-step instructions for performing a restore, see:

• Restoring an instance

Tips and requirements for restoring to a different instance

When you are restoring a backup to a different instance, keep in mind thefollowing restrictions and best practices:

• The target instance must have the same database version as the instance from which the backup was taken.

• Cloud SQL always sets the storage capacity of the target instance to themaximum value of the size of both the configured disk and the backup disk. Thebackup disk is the size of the disk when the backup is taken.

• The storage capacity of the target instance must be at least as large as thecapacity of the instance being backed up. The amount of storage used doesnot matter. You can see the storage capacity of the instance in the consoleCloud SQLinstances page.

• The target instance must be in theRUNNABLE state.

• The target instance can have a different number of cores or amountof 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 particularproject. SeeViewing backups during an outage.

Restore rate limitations

You are allowed a maximum of three restore operations every 30 minutes perinstance per region per project. If a restore operation fails, it does not counttowards this quota. If you reach the limit, the operation fails with an errormessage 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 operationsare available at any one time. For each backup, there's a bucket for each targetproject 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 bucketis full, the token overflows.

Each time you issue a restore operation, a token is granted from the bucket. Ifthe operation succeeds, the token is removed from the bucket. If it fails, thetoken is returned to the bucket. The following diagram shows how this works:

For example, in the following figure, Backup1, Backup2, and Backup3 are thebackups from the same source instance.

• Each backup (Backup1, Backup2, and Backup3) has its own bucket of tokens forrestore 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 fivebuckets for that backup in that region, one in each project. In the previousfigure, we have two projects in region A: Project 1 and Project n.
  • Backup1 has two buckets of tokens for restore operations in Region A. Onebucket for Project 1 (Bucket11A), and one bucket for Project n (Bucket1nA).
  • Similarly, Backup3 has two buckets for restore operations in Region A. Onefor Project 1 (Bucket31A) and one for Project n (Bucket3nA).
• Backup3 has one bucket in Region B, for Project1, because all instances inthe same target project and the same target region share one bucket.

What's next

• Perform a restore from a backup
• Use point-in-time recovery (PITR)