이 페이지에서는 백업에서 인스턴스를 복원하거나 point-in-time recovery(PITR)를 수행하기 전에 검토할 정보를 제공합니다.
복원 중에는 어떻게 되나요?
Cloud SQL Enterprise 버전과 Cloud SQL Enterprise Plus 버전의 경우 백업에서 인스턴스를 복원할 수 있습니다. 또한 다른 버전의 인스턴스 간에 백업을 복원할 수 있습니다.
인스턴스를 복원하면 기본 인스턴스의 다음 데이터가 새 인스턴스로 복원됩니다.
데이터베이스
사용자
복원 작업으로 인해 인스턴스가 재시작됩니다.
PITR(point-in-time recovery)
PITR(point-in-time recovery)은 인스턴스를 특정 시점으로 복구하는 데 도움이 됩니다. 예를 들어 오류로 데이터가 손실된 경우 오류가 발생하기 전의 시점으로 데이터베이스를 복구할 수 있습니다.
PITR은 항상 새 인스턴스를 만듭니다. 기존 인스턴스에서 PITR을 수행할 수 없습니다. 새로운 인스턴스는 클론 생성 방식과 유사하게 소스 인스턴스의 설정을 상속합니다.
Google Cloud 콘솔에서 Cloud SQL 인스턴스를 만들면 PITR이 기본적으로 사용 설정됩니다.
PITR은 바이너리 로깅을 사용하여 로그를 보관처리합니다. 기본적으로 PITR은 Cloud SQL Enterprise Plus 버전 인스턴스에 사용 설정됩니다.
PITR을 사용 설정하기 전에 Cloud SQL 인스턴스에서 백업을 복원하면 PITR을 사용할 수 있는 보관처리된 로그가 손실됩니다. 디스크의 바이너리 로그 크기로 인해 인스턴스에 성능 문제가 발생하면 PITR을 비활성화하고 다시 사용 설정합니다. 이 작업을 수행하면 새 로그가 디스크 대신 Cloud Storage에 저장됩니다.
Cloud SQL은 항상 대상 인스턴스의 스토리지 용량을 구성된 디스크와 백업 디스크 모두의 최대 크기 값으로 설정합니다. 백업 디스크는 백업이 작성될 때의 디스크 크기입니다.
대상 인스턴스의 스토리지 용량은 최소한 백업되는 인스턴스의 용량 이상이어야 합니다. 사용되는 스토리지의 크기는 중요하지 않습니다. 콘솔의 Cloud SQL 인스턴스 페이지에서 인스턴스의 스토리지 용량을 확인할 수 있습니다.
대상 인스턴스는 RUNNABLE 상태여야 합니다.
대상 인스턴스의 코어 개수와 메모리 양은 백업이 실행된 인스턴스와 다를 수 있습니다.
대상 인스턴스가 소스 인스턴스와 다른 리전에 있을 수 있습니다.
서비스 중단 시 특정 프로젝트의 백업 목록을 계속 검색할 수 있습니다. 서비스 중단 시 백업 보기를 참조하세요.
복원 비율 제한
프로젝트마다 리전별로 인스턴스당 30분 간격으로 복원 작업이 최대 3개까지 허용됩니다. 복원 작업이 실패하면 이 할당량에 포함되지 않습니다. 이 한도에 도달하면 작업이 실패하고 작업을 다시 실행할 수 있는 시기를 알려주는 오류 메시지가 표시됩니다.
Cloud SQL에서 복원에 비율 제한을 수행하는 방법을 살펴보겠습니다.
Cloud SQL에서는 버킷의 토큰을 사용하여 한 번에 사용할 수 있는 복원 작업 수를 결정합니다. 백업마다 각 타겟 프로젝트와 타겟 리전에 대한 버킷이 있습니다. 동일한 프로젝트의 타겟 인스턴스가 같은 리전에 있으면 버킷 하나를 공유합니다.
버킷마다 복원 작업에 사용할 수 있는 토큰이 최대 3개 있습니다. 10분마다 새 토큰이 버킷에 추가됩니다. 버킷이 가득 차면 토큰이 오버플로됩니다.
복원 작업을 실행할 때마다 버킷에서 토큰이 부여됩니다. 작업이 성공하면 토큰이 버킷에서 삭제됩니다. 실패하면 토큰은 버킷으로 반환됩니다. 다음 다이어그램에서는 작동 방식을 보여줍니다.
예를 들어 다음 그림에서 Backup1, Backup2, Backup3은 동일한 소스 인스턴스의 백업입니다.
각 백업(Backup1, Backup2, Backup3)에는 리전 A의 프로젝트 1에 있는 여러 인스턴스(Bucket11A, Bucket21A, Bucket31A)를 타겟팅하는 복원 작업에 사용되는 자체 토큰 버킷이 있습니다. 각 백업에는 자체 버킷이 있으므로 30분마다 3회씩 각 백업을 동일한 인스턴스로 복원할 수 있습니다.
백업마다 별도의 프로젝트와 별도의 리전에 사용되는 버킷이 있습니다.
예를 들어 리전 하나에 프로젝트가 5개 있는 경우 해당 리전에는 프로젝트마다 백업 하나에 사용되는 버킷 5개가 있습니다. 앞의 그림에는 리전 A에 프로젝트 1과 프로젝트 n이라는 프로젝트 두 개가 있습니다.
Backup1에는 리전 A의 복원 작업에 사용되는 토큰 버킷이 두 개 있습니다. 프로젝트 1(Bucket11A)에 버킷 하나, 프로젝트 n(Bucket1nA)에 버킷 하나가 있습니다.
마찬가지로 Backup3에는 리전 A의 복원 작업에 사용되는 버킷이 두 개 있습니다. 프로젝트 1(Bucket31A)에 하나, 프로젝트 n(Bucket3nA)에 하나가 있습니다.
동일한 타겟 프로젝트와 동일한 타겟 리전의 모든 인스턴스에서 버킷 하나를 공유하므로 Backup3에는 리전 B의 Project1에 사용되는 버킷이 하나 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-08-19(UTC)"],[],[],null,["# About restoring an instance\n\n\u003cbr /\u003e\n\nMySQL \\| [PostgreSQL](/sql/docs/postgres/backup-recovery/restore \"View this page for the PostgreSQL database engine\") \\| [SQL Server](/sql/docs/sqlserver/backup-recovery/restore \"View this page for the SQL Server database engine\")\n\n\u003cbr /\u003e\n\nThis page provides information to review before restoring an instance\nfrom a backup or performing a point-in-time recovery (PITR).\n| **Note:** This page contains features related to Cloud SQL editions. For more information about Cloud SQL editions, see [Introduction to Cloud SQL editions](/sql/docs/mysql/editions-intro).\n\nWhat happens during a restore?\n------------------------------\n\nFor 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.\n\nWhen you restore an instance, the following data from the primary instance\nare restored to the new instance:\n\n- Databases\n- Users\n\n| **Note:** The flags from the primary instance are not restored. Any flags previously set on the target instance are retained after the restore.\n\nThe restore operation causes the instance to restart.\n\nPoint-in-time recovery (PITR)\n-----------------------------\n\nPoint-in-time recovery (PITR) helps you recover an instance to a specific point in\ntime. For example, if an error causes a loss of data, you can recover a database\nto its state before the error occurred.\n\nPITR always creates a new instance; you can't perform a\nPITR to an existing instance. The new instance inherits the\nsettings of the source instance, similar to how\n[clone creation](/sql/docs/mysql/clone-instance) works.\n\n\u003cbr /\u003e\n\nWhen you create a Cloud SQL instance in the Google Cloud console, PITR is enabled by default.\n\nPITR uses [binary logging](/sql/docs/mysql/backup-recovery/pitr#enablingpitr)\nto archive logs. By default, PITR is enabled for Cloud SQL Enterprise Plus edition\ninstances.\nWhen you restore a backup on a Cloud SQL instance before enabling PITR, you lose the archived logs that let you use PITR. If the size of your binary logs on disk is causing performance issues for your instance, then deactivate PITR and re-enable it. This action ensures that new logs are stored in Cloud Storage instead of on disk.\n\n\u003cbr /\u003e\n\n| **Caution:** If you deactivate and re-enable PITR, then any existing logs are deleted, and you won't be able to perform PITR earlier than the time that you re-enabled it. Enabling PITR requires restarting the database.\n\nFor step-by-step instructions for performing PITR, see [Use point-in-time recovery (PITR)](/sql/docs/mysql/backup-recovery/pitr).\n\n### Restore an unavailable instance\n\nYou 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.\n\nIf the instance is unavailable, then you can use the API to [check for the latest time](/sql/docs/mysql/backup-recovery/pitr#get-the-latest-recovery-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 can [restore the instance to a different primary or secondary zone](/sql/docs/mysql/backup-recovery/pitr#perform-PITR-unavailable-instance) by providing values for the preferred zones.\n\nSuppose 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.\n\nGeneral tips about performing a restore\n---------------------------------------\n\nWhen you restore an instance from a backup, whether to the same instance or to\na different instance, keep in mind the following items:\n\n- The restore operation overwrites all data on the target instance.\n- The target instance is unavailable for connections during the restore operation; existing connections are lost.\n- If you are restoring to an instance with read replicas, you must delete all replicas and recreate them after the restore operation completes.\n- The restore operation restarts the instance.\n\nFor step-by-step instructions for performing a restore, see:\n\n- [Restoring an instance](/sql/docs/mysql/backup-recovery/restoring)\n\nTips and requirements for restoring to a different instance\n-----------------------------------------------------------\n\nWhen you are restoring a backup to a different instance, keep in mind the\nfollowing restrictions and best practices:\n\n- The target instance must have the same database version as the instance from which the backup was taken.\n\n\n If you want to upgrade the database version for your instance, follow the steps in\n [Upgrade the database major version in-place](/sql/docs/mysql/upgrade-major-db-version-inplace).\n- Cloud SQL always sets the storage capacity of the target instance to the\n maximum value of the size of both the configured disk and the backup disk. The\n backup disk is the size of the disk when the backup is taken.\n\n- The storage capacity of the target instance must be at least as large as the\n *capacity* of the instance being backed up. The amount of storage used does\n not matter. You can see the storage capacity of the instance in the console\n [Cloud SQL\n instances page](https://console.cloud.google.com/sql/instances).\n\n- The target instance must be in the `RUNNABLE` state.\n\n- The target instance can use a different number of cores and amounts of memory\n than the instance from which the backup was taken.\n\n- The target instance can be in a different region from the source instance.\n\n- During an outage, you can still retrieve a list of backups in a particular\n project. See [Viewing backups during an outage](/sql/docs/mysql/backup-recovery/backing-up#backuplist).\n\nRestore rate limitations\n------------------------\n\nYou are allowed a maximum of three restore operations every 30 minutes per\ninstance per region per project. If a restore operation fails, it does not count\ntowards this quota. If you reach the limit, the operation fails with an error\nmessage that tells you when you can run the operation again.\n\nLet's take a look at how Cloud SQL performs rate limiting for restores.\n\nCloud SQL uses tokens from a bucket to determine how many restore operations\nare available at any one time. For each backup, there's a bucket for each target\nproject and target region. The target instances from the same project share one bucket if they are in the same region.\nThere'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\nis full, the token overflows.\n\nEach time you issue a restore operation, a token is granted from the bucket. If\nthe operation succeeds, the token is removed from the bucket. If it fails, the\ntoken is returned to the bucket. The following diagram shows how this works:\n\nFor example, in the following figure, Backup1, Backup2, and Backup3 are the\nbackups from the same source instance.\n\n- 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.\n- 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.\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).\n - Similarly, Backup3 has two buckets for restore operations in Region A. One for Project 1 (Bucket31A) and one for Project n (Bucket3nA).\n- 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.\n\nWhat's next\n-----------\n\n- [Perform a restore from a backup](/sql/docs/mysql/backup-recovery/restoring#restorebackups)\n- [Use point-in-time recovery (PITR)](/sql/docs/mysql/backup-recovery/pitr)"]]
