백업 개요

이 페이지에서는 Cloud SQL 인스턴스의 백업 작동 방식을 설명합니다.

백업 예약 또는 주문형 백업 만들기에 관한 단계별 안내는 주문형 백업과 자동 백업 만들기 및 관리를 참조하세요.

백업에서 인스턴스로 데이터를 복원하는 방법에 대한 개요는 인스턴스 복원 개요를 참조하세요.

백업의 기능

백업을 사용하면 손실된 데이터를 Cloud SQL 인스턴스로 복원할 수 있습니다. 또한 인스턴스에 문제가 있는 경우 백업을 사용하여 덮어쓰면 인스턴스를 이전 상태로 복원할 수 있습니다. 필요한 데이터가 포함된 모든 인스턴스에 자동 백업을 사용 설정합니다. 백업은 데이터가 손실되거나 손상되지 않도록 보호합니다.

또한 클론 및 복제본 생성과 같은 일부 작업에는 트랜잭션 로깅과 함께 백업을 사용 설정합니다.

백업 비용

기본적으로 Cloud SQL은 모든 주문형 백업 외에 자동 백업 7개를 각 인스턴스에 보관합니다. 유지할 자동 백업 수를 구성할 수 있습니다. 백업 스토리지 요금은 다른 유형의 인스턴스보다 요금이 낮습니다. 자세한 내용은 가격 책정 페이지를 참조하세요.

백업과 내보내기 비교

백업은 보관 정책에 따라 Cloud SQL에서 관리되며 Cloud SQL 인스턴스와 별도로 저장됩니다. Cloud SQL 백업은 수명주기를 관리하는 Cloud Storage에 업로드된 내보내기와 다릅니다. 백업은 전체 데이터베이스를 포괄합니다. 내보내기는 특정 콘텐츠를 선택할 수 있습니다.

백업 및 복원 작업은 데이터베이스를 이후 버전으로 업그레이드하는 데 사용될 수 없습니다. 백업에서 동일한 데이터베이스 버전의 인스턴스로만 복원할 수 있습니다.

최신 버전으로 업그레이드하려면 Database Migration Service를 사용하거나 데이터베이스를 새 Cloud SQL 인스턴스로 내보낸 후 가져오는 것이 좋습니다.

백업 크기

Cloud SQL 백업은 증분 방식입니다. 이전 백업이 변경된 후 변경된 데이터만 포함됩니다. 가장 오래된 백업은 데이터베이스와 크기가 비슷하지만 후속 백업의 크기는 데이터 변경 속도에 따라 다릅니다. 가장 오래된 백업이 삭제되면 두 번째로 오래된 백업의 크기가 증가하여 전체 백업 크기가 동일하게 유지됩니다.

백업 유형

Cloud SQL은 두 가지 유형의 백업을 수행합니다.

주문형 백업

언제든지 백업을 만들 수 있습니다. 이는 데이터베이스에서 위험 부담이 있는 작업을 하려고 하거나 백업이 필요한데 백업 기간까지 기다리고 싶지 않을 때 유용합니다. 인스턴스에 자동 백업이 사용 설정되어 있는지 여부와 관계없이 모든 인스턴스에 주문형 백업을 만들 수 있습니다.

주문형 백업은 자동 백업과 달리 자동으로 삭제되지 않으며 사용자가 직접 삭제하거나 인스턴스가 삭제되기 전까지 유지됩니다. 주문형 백업은 자동으로 삭제되지 않으므로 이를 계속해서 비용이 청구됩니다.

자동 백업

자동 백업은 4시간 백업 기간을 사용합니다. 백업 기간 동안 백업이 시작됩니다. 가능하면 인스턴스의 활동이 가장 적을 때 백업을 예약합니다.

백업 기간에는 인스턴스가 실행되는 동안 자동 백업이 수행됩니다. 인스턴스가 중지되기 전에 모든 변경사항을 보호하기 위해 인스턴스가 중지된 후 추가 자동 백업이 한 번 수행됩니다. 기본적으로 최대 7개의 최신 백업이 유지됩니다. 인스턴스가 36시간을 초과하여 중지되면 자동 백업은 중지됩니다. 1개에서 365개까지 유지할 자동 백업 수를 구성할 수 있습니다. 백업 및 트랜잭션 로그 보관 값은 기본 설정에서 변경할 수 있습니다. 자세히 알아보기

백업 저장 위치

백업 위치는 다음과 같습니다.

  • 원본 인스턴스의 위치에 따라 Cloud SQL에서 선택하는 기본 위치
  • 기본 위치를 사용하지 않을 때 선택하는 커스텀 위치

기본 백업 위치

스토리지 위치를 지정하지 않으면 백업은 Cloud SQL 인스턴스의 위치와 지리적으로 가장 가까운 멀티 리전에 저장됩니다. 예를 들어 Cloud SQL 인스턴스가 us-central1에 있는 경우 백업은 기본적으로 us 멀티 리전에 저장됩니다. 하지만 australia-southeast1과 같은 기본 위치는 멀티 리전 외부에 있습니다. 가장 가까운 멀티 리전은 asia입니다.

커스텀 백업 위치

Cloud SQL을 사용하면 백업 데이터의 커스텀 위치를 선택할 수 있습니다. 이 기능은 조직이 특정 지역적 경계 내에서 백업을 유지하는 데이터 상주 규정을 준수해야 하는 경우에 유용합니다. 조직에 이러한 유형의 요구사항이 있는 경우 리소스 위치 제한 조직 정책을 사용할 가능성이 높습니다. 이 정책을 통해 정책을 준수하지 않는 지리적 위치를 사용하려고 하면 백업 페이지에 알림이 표시됩니다. 이 알림이 표시되면 백업 위치를 정책에서 허용하는 위치로 변경해야 합니다.

유효한 리전 값의 전체 목록은 인스턴스 위치를 참조하세요. 멀티 리전 값의 전체 목록은 멀티 리전 위치를 참조하세요.

백업용 커스텀 위치 설정백업 위치 보기를 참조하세요.

자동 백업 및 트랜잭션 로그 보관

자동 백업은 Cloud SQL 인스턴스를 복원하는 데 사용됩니다. 자동 백업 및 트랜잭션 로그 조합은 point-in-time recovery 수행에 사용됩니다.

자동 백업은 보관 기간을 구성하여 최대 1년까지 보관될 수 있지만 주문형 백업은 백업을 삭제할 때까지 또는 인스턴스가 삭제될 때까지 지속됩니다.

트랜잭션 로그는 며칠 단위로 계산되지만 자동 백업이 일일 경계에 발생하는 것은 아닙니다. 이러한 보관 설정에는 서로 다른 단위가 사용됩니다. 자동 백업 보관은 개수이며 1개부터 365개의 백업으로 설정할 수 있습니다. 트랜잭션 로그 보관은 일수이며 1일부터 7일까지로 설정할 수 있습니다. 두 가지 모두 기본값은 7입니다.

로그와 백업이 더 빨리 삭제되므로 하한 경계는 테스트 인스턴스에 유용합니다. 트랜잭션 로그의 경우 디스크 크기가 하한으로 늘어나지 않습니다. 자동 백업 보관에 더 높은 값을 사용하면 나중에 복원할 수 있습니다.

로그는 매일 한 번씩 영구 삭제되며, 지속적으로 진행되지 않습니다. 로그 보관 일수가 백업 수와 동일한 경우 로그 보관이 부족할 수 있습니다. 예를 들어 로그 보관을 7일로 설정하고 백업 보관을 7개로 설정하면 6~7일 동안의 로그가 유지됩니다.

백업 수는 로그 보관 일수보다 최소 1일 이상으로 설정해야 로그 보관 기간을 지정된 최소 일수 이상으로 유지할 수 있습니다.

데이터베이스에 대한 쓰기 작업이 많으면 대량의 트랜잭션 로그가 생성되어 상당한 디스크 공간을 사용할 수 있고 스토리지 자동 증가가 사용 설정된 인스턴스의 디스크 증가로 이어질 수 있습니다. 트랜잭션 로그 보관을 고려하여 인스턴스 스토리지의 크기를 조정하는 것이 좋습니다.

자동 백업 보관 설정을 참조하세요.

트랜잭션 로그 보관 설정를 참조하세요.

백업을 내보낼 수 있나요?

아니요, 백업을 내보낼 수 없습니다. 인스턴스 데이터만 내보낼 수 있습니다. Cloud SQL에서 데이터 내보내기를 참조하세요.

특별 백업 사용자 정보

Cloud SQL은 인스턴스별로 특별 데이터베이스 사용자인 cloudsqladmin을 만들고 고유한 인스턴스 비밀번호를 생성합니다. Cloud SQL은 자동 백업을 수행하기 위해 cloudsqladmin 사용자로 로그인합니다.

백업이 인스턴스 작업에 미치는 영향

쓰기 및 다른 작업은 백업의 영향을 받지 않습니다.

로깅되지 않은 테이블

로깅되지 않은 테이블은 백업 복원 중에 자동으로 완전 삭제됩니다.

문제 해결하기

문제 문제 해결하기
현재 작업의 상태를 볼 수 없습니다. Google Cloud Console은 작업 완료시에만 성공 또는 실패를 보고합니다. 경고 또는 기타 업데이트를 표시하도록 설계되지 않았습니다.

gcloud sql operations list 명령어를 실행하여 특정 Cloud SQL 인스턴스의 모든 작업을 나열합니다.

주문형 백업 작업을 실행한 사용자를 확인하려고 합니다. 사용자 인터페이스에 작업을 시작한 사용자가 표시되지 않습니다.

로그를 살펴보고 텍스트로 필터링하여 사용자를 찾습니다. 비공개 정보의 경우 감사 로그를 사용해야 할 수도 있습니다. 관련 로그 파일은 다음과 같습니다.

  • cloudsql.googleapis.com/postgres.log
  • Cloud 감사 로그가 사용 설정되어 있고 이를 보는 데 필요한 권한이 있는 경우 cloudaudit.googleapis.com/activity를 사용할 수도 있습니다.
인스턴스가 삭제된 후에는 백업을 수행할 수 없습니다. Cloud SQL 인스턴스 삭제 유예 기간은 4일입니다. 즉시 삭제되는 읽기 복제본은 제외됩니다. 이 시간 동안 고객지원에서 인스턴스를 다시 만들 수 있습니다. 인스턴스가 삭제된 후에는 데이터를 복구할 수 없습니다.

내보내기 작업을 완료한 경우 새 인스턴스를 만든 다음 가져오기 작업을 수행하여 데이터베이스를 다시 만들 수 있습니다. 내보내기는 Cloud Storage에 쓰이고 여기에서 가져오기를 읽습니다.

자동 백업이 장시간 중단되고 취소할 수 없습니다. 데이터베이스 크기에 따라 백업에 오랜 시간이 걸릴 수 있습니다.

작업을 취소해야 하는 경우 고객지원에 인스턴스 force restart를 요청할 수 있습니다.

SQL 덤프 파일에 참조된 하나 이상의 사용자가 없으면 복원 작업이 실패할 수 있습니다. SQL 덤프를 복원하기 전에 객체를 소유하거나 덤프된 데이터베이스의 객체에 대한 권한이 부여된 모든 데이터베이스 사용자가 대상 데이터베이스에 있어야 합니다. 그렇지 않으면 복원 작업이 원래 소유권이나 권한으로 객체를 다시 만들지 못합니다.

SQL 덤프에서 복원하기 전에 데이터베이스 사용자를 만듭니다.

자동 백업 보관 일수를 7일에서 30일 이상으로 늘리려고 합니다. 백업은 7개만 보관됩니다. 백업은 백업 보관 비용과 크기 때문에 정기적으로 삭제됩니다. 따라서 복원할 수 있는 자동 백업은 현재 표시되는 백업뿐입니다.

백업을 무기한 보관하려면 자동 백업의 경우처럼 삭제되지 않는 주문형 백업을 직접 생성할 수 있습니다. 주문형 백업은 무기한 유지됩니다. 즉, 백업이나 백업이 속한 인스턴스가 삭제될 때까지 유지됩니다. 이러한 유형의 백업은 자동으로 삭제되지 않으므로 결제에 영향을 미칠 수 있습니다.

백업이 실패했으며 Unknown error 메시지가 표시됩니다. 백업 작업이 타임아웃되었을 수 있습니다.

백업 생성에 영향을 미치는 플래그는 checkpoint_timeout 플래그와 checkpoint_completion_target 플래그입니다. 백업이 시작되면 slow 체크포인트가 실행되고 checkpoint_completion_targetcheckpoint_timeout을 곱한 값만큼 시간이 소요됩니다.

예: 900 sec * 0.9 sec = 810 sec = 13.5 min

따라서 제한 시간을 초과합니다. 이 경우 checkpoint_completion_target 값을 낮추면 문제가 해결됩니다.

자동 백업에 실패했으며 이메일 알림을 받지 못했습니다. 백업 실패에는 알림이 지원되지 않습니다.

자동 백업이 실패하면 Cloud SQL 인스턴스의 Details 페이지에 Operation error 메시지가 표시됩니다.

REST API 또는 gcloud 명령어를 통해 백업 상태를 확인할 수 있습니다. 예를 들어 먼저 인스턴스의 백업을 나열한 다음 해당 ID로 특정 백업을 설명합니다.


gcloud sql backups list \
--project=PROJECT_ID \
--instance=INSTANCE_ID
   

gcloud sql backups describe BACKUP-ID \
--instance=INSTANCE_ID
    
인스턴스가 실패 및 백업 복원 상태 사이를 순환하며 반복적으로 실패합니다. 복원 후 데이터베이스에 대한 연결과 사용 시도가 실패합니다.
  • 개방형 연결이 너무 많을 수 있습니다. 끊어진 연결을 삭제하는 autovacuum 설정이 없는 상황에서 연결 중간에 발생하는 오류로 인해 너무 많은 연결이 생길 수 있습니다.
  • 커스텀 코드에서 몇 번 실패해도 중지되지 않는 재시도 로직을 사용하면 순환이 발생할 수 있습니다.
  • 트래픽이 너무 많을 수 있습니다. 연결 풀링과 기타 연결 권장사항을 따릅니다.

해결 방법:

  1. 데이터베이스가 autovacuum에 설정되었는지 확인합니다.
  2. 커스텀 코드에 설정된 연결 재시도 로직이 있는지 확인합니다.
  3. 데이터베이스가 복구될 때까지 트래픽을 줄였다가 천천히 다시 복구합니다.
백업/복원 작업을 수행할 때 데이터가 누락됐음을 발견합니다. 테이블이 로깅되지 않는 상태로 생성되었습니다. 예를 들면 다음과 같습니다.

CREATE UNLOGGED TABLE ....

이러한 테이블은 백업에서 복원에 포함되지 않습니다.

  • 로깅되지 않은 테이블의 콘텐츠는 HA 인스턴스의 장애 조치 시 유실됩니다.
  • 로깅되지 않은 테이블은 postgres 비정상 종료 시 유실됩니다.
  • 로깅되지 않은 테이블은 읽기 복제본에 복제되지 않습니다.
  • 로깅되지 않은 테이블은 백업 복원 중에 자동으로 완전 삭제됩니다.

해결 방법은 백업을 통해 이러한 테이블을 복원하고 싶다면 로깅되지 않은 테이블을 사용하지 않는 것입니다. 이미 로깅되지 않은 테이블이 있는 데이터베이스에서 복원하는 경우 데이터베이스를 파일로 덤프하고 해당 테이블에 대하여 SET LOGGEDALTER TABLE하여 덤프된 파일을 수정한 후 데이터를 다시 로드할 수 있습니다.

다음 단계