Overview of Restoring an Instance

This page provides information you should know before restoring an instance from a backup or performing a point-in-time recovery (PITR).

For step-by-step instructions for performing a restore or point-in-time recovery, see Restoring an instance.

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 that is in a high availability configuration (it has a failover replica) or to an instance with read replicas, you must delete all replicas and recreate them after the restore operation completes.

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:

  • You cannot restore a backup to an instance in a different Cloud Platform project.
  • You cannot restore a backup to a different instance type (First Generation or Second Generation).
  • The target instance should have the same database version as the instance from which the backup was taken.

    If you want to upgrade the database version for your instance, follow the steps in Upgrading the Database for an Instance.

  • 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.

  • The target instance must be in the RUNNABLE state.
  • The target instance can be a different tier or machine type than the instance from which the backup was taken.

Overview of point-in-time recovery

Point-in-time recovery enables you to recover an instance to a specific point in time. For example, if an operator error causes a loss of data, you can recover a database to its state before the error occurred.

A point-in-time recovery always creates a new instance; you cannot perform a point-in-time recovery to an existing instance. The new instance inherits the settings of the source instance, similar to how clone creation works.

Requirements for point-in-time recovery

To perform a point-in-time recovery, your source instance must have automated backups and binary logging enabled. In addition, your instance must have a backup that was taken before the event you want to recover from, as well as continuous binary logs from the time that backup was taken.

About enabling binary logging

Enabling binary logging causes a slight reduction in write performance. Read performance is unaffected.

In addition, when you enable or disable binary logging, the instance is restarted.

Binary logs are stored on the instance. For First Generation instances, the space used by binary logs counts against the total storage used by the instance. For Second Generation instances, binary logs are charged at the regular storage rate. When you disable binary logging, all the existing binary logs are deleted.

What's next

Send feedback about...

Cloud SQL for MySQL