Database > RDS for MySQL > 백업 및 복원

백업 개요

장애 상황에 대비하여 DB 인스턴스의 데이터베이스를 복구할 수 있도록 미리 준비할 수 있습니다. 필요할 때마다 콘솔에서 백업을 수행하거나, 주기적으로 백업이 수행되도록 설정할 수 있습니다. 백업이 수행되는 동안에는 해당 DB 인스턴스의 스토리지의 성능 저하가 발생할 수 있습니다. 서비스에 영향을 주지 않기 위해 서비스의 부하가 적은 시간에 백업할 것을 권장합니다. 백업으로 인한 성능 저하를 원치 않을 경우 고가용성 구성을 사용하거나, 이전 백업 이후 데이터의 증분만 백업할 수 있으며, 읽기 복제본에서 백업을 수행할 수도 있습니다.

[참고] 고가용성 DB 인스턴스는 예비 마스터에서 백업이 수행되어 마스터의 스토리지 성능 저하가 발생하지 않습니다. 단, 다음의 경우 고가용성 DB 인스턴스이더라도 마스터에서 백업이 수행될 수 있습니다. * 예비 마스터 장애로 인해 백업 수행이 불가능한 상태인 경우 * 예비 마스터 재구축을 위해 예비 마스터가 아닌 다른 DB 인스턴스에서 수행한 백업이 필요한 상황에서 읽기 복제본이 없는 경우

RDS for MySQL에서는 Percona XtraBackup을 이용하여 데이터베이스를 백업합니다. 외부 MySQL의 백업으로 복원하거나 RDS for MySQL의 백업으로 복원하기 위해서는 RDS for MySQL에서 사용하는 Percona XtraBackup과 동일한 버전을 사용해야 합니다. DB 엔진 버전에 따른 Percona XtraBackup 버전은 아래와 같습니다.

MySQL 버전	XtraBackup 버전
5.7.15	2.4.28
5.7.19	2.4.28
5.7.26	2.4.28
5.7.33	2.4.28
5.7.37	2.4.28
8.0.18	8.0.32
8.0.23	8.0.32
8.0.28	8.0.32
8.0.32	8.0.32
8.0.33	8.0.33
8.0.34	8.0.34
8.0.35	8.0.35
8.0.36	8.0.35
8.0.40	8.0.35

• XtraBackup의 설치에 대한 자세한 설명은 Percona 홈페이지를 참고합니다.
• https://www.percona.com/doc/percona-xtrabackup/2.4/index.html
• https://www.percona.com/doc/percona-xtrabackup/8.0/index.html

[참고] 2023년 8월 17일 XtraBackup 유틸리티의 버전이 업그레이드되었습니다. 이전 백업에 사용된 XtraBackup 버전은 콘솔에서 확인할 수 있습니다.

백업 종류

백업은 수동 백업과 자동 백업으로 구분할 수 있습니다.

수동 백업

콘솔에서 수동으로 백업을 수행해 특정 시점의 데이터베이스를 영구히 저장할 수 있습니다. 수동 백업은 자동 백업과 달리 명시적으로 백업을 삭제하지 않는 한 DB 인스턴스가 삭제될 때 같이 삭제되지 않습니다. 수동 백업 생성 시에는 백업 이름을 지정해야 하며, 다음과 같은 제약 사항이 있습니다. * 백업 이름은 리전별로 고유해야 합니다. * 백업 이름은 1~100자 사이의 영문자, 숫자, 일부 기호(-, _, .)만 입력할 수 있으며, 첫 번째 글자는 영문자만 사용할 수 있습니다.

수동 전체 백업 생성하기

❶ DB 인스턴스 목록에서 백업할 DB 인스턴스 선택 후 백업을 클릭하여 수동으로 전체 백업을 생성할 수 있습니다. ❷ 백업 목록에서 전체 백업 생성을 클릭하고 백업할 DB 인스턴스를 지정하여 수동으로 전체 백업을 생성할 수 있습니다.

수동 증분 백업 생성하기

❸ 백업 목록에서 기준 백업을 선택 후 증분 백업 생성을 클릭하여 증분 백업을 생성할 수 있습니다. 일부 백업은 기준 백업으로 선택할 수 없습니다. 기준 백업에 대한 자세한 설명은 기준 백업을 참고합니다.

자동 백업

수동으로 백업을 수행하는 경우 외에도 복원 작업을 위해 필요한 경우 또는 예정된 자동 백업 설정에 따라 자동 백업이 수행될 수 있습니다. 자동 백업 시에 적용되는 설정 항목은 자동 백업 설정을 참고합니다.

백업 방식

전체 백업 방식과 증분 백업 방식이 제공됩니다.

전체 백업

DB 인스턴스의 모든 데이터를 백업합니다.

증분 백업

기준 백업이 수행된 이후의 데이터 변경분만을 증분 방식으로 백업합니다. 변경이 잘 일어나지 않는 데이터가 대부분인 경우 추천합니다. 증분 백업은 항상 기준 백업을 수행했던 DB 인스턴스에서 수행됩니다. 증분 백업으로 복원 시 최초 생성된 전체 백업 복원을 진행하고, 선택한 증분 백업에 도달할 때까지의 모든 증분이 순차적으로 반영됩니다.

[주의] 증분 백업으로 복원 시에는 전체 백업으로 복원할 때보다 더 많은 시간이 소요될 수 있으며 이는 복원에 필요한 증분 백업들의 용량의 합에 비례합니다.

기준 백업

증분 백업에는 데이터 변경 사항의 기준이 될 백업이 필요합니다. 증분 백업도 새로운 증분 백업의 기준 백업이 될 수 있습니다.

증분 백업의 기준이 되는 백업에는 다음 제약 사항이 존재합니다. 수동 및 자동으로 증분 백업 시에 공통으로 적용됩니다. * 에러 상태의 백업은 기준 백업이 될 수 없습니다. * 마지막 장애 조치 이전에 생성된 백업은 기준 백업이 될 수 없습니다. * 마지막 DB 엔진 버전 업그레이드 이전에 생성된 백업은 기준 백업이 될 수 없습니다. * 이미 해당 백업을 기준으로 한 증분 백업이 존재하는 경우 기준 백업이 될 수 없습니다. 단, 이전 증분이 실패한 경우에는 동일한 백업을 기준으로 증분이 가능합니다. * 해당 백업을 수행했던 DB 인스턴스가 삭제되었거나 장애로 인해 백업을 수행할 수 없는 상태라면 기준 백업이 될 수 없습니다. * 2024년 9월 정기 배포 이전에 생성된 백업은 기준 백업이 될 수 없습니다.

자동 백업 전략에 따라 증분 백업이 실행되는 경우 위 제약 사항과 함께 다음 추가 제약 사항을 만족하는 기준 백업이 자동으로 선택됩니다. 제약 사항을 만족하는 기준 백업이 없는 경우 자동 백업 전략과 관계없이 전체 백업을 수행합니다. * 복제 중단 상태인 예비 마스터, 읽기 복제본에서 수행된 백업은 기준 백업이 될 수 없습니다. * 테이블 잠금을 사용하지 않은 상태에서 수행된 백업은 기준 백업이 될 수 없습니다. * 해당 백업 생성 이후에 새로운 전체 백업이 생성된 경우 기준 백업이 될 수 없습니다.

백업 설정

DB 인스턴스 생성 및 수정 시 백업에 적용될 설정 항목들을 지정할 수 있습니다.

공통 설정

다음 항목들은 자동 백업 및 수동 백업 시에 공통적으로 적용됩니다.

테이블 잠금 사용

• FLUSH TABLES WITH READ LOCK 구문의 실행 여부를 설정합니다.
• 테이블 잠금을 사용하면 백업 데이터의 일관성을 보장하기 위해 백업 시 주기적으로 FLUSH TABLES WITH READ LOCK 구문을 실행합니다. FLUSH TABLES WITH READ LOCK 구문의 실행에 실패할 경우 백업에 실패하게 됩니다.
• 백업이 수행되는 동안 DML 쿼리 부하가 많은 경우 테이블 잠금을 사용하지 않도록 설정할 수 있습니다. 테이블 잠금을 사용하지 않으면 FLUSH TABLES WITH READ LOCK 구문을 실행하지 않기 때문에 DML 부하가 많아도 백업이 실패하지 않습니다. 하지만 테이블 잠금을 사용하지 않은 백업은 백업 데이터의 일관성이 보장되지 않을 수 있으며, 이에 따라 테이블 잠금을 사용하지 않고 생성된 백업 및 테이블 잠금을 사용하지 않도록 설정된 DB 인스턴스에 대해 복원 및 복제 과정을 포함한 일부 작업을 지원하지 않습니다.

쿼리 지연 대기 시간(초)

• 테이블 잠금 사용 시 FLUSH TABLES WITH READ LOCK 구문의 대기 시간을 설정합니다. 쿼리 지연 대기 시간만큼 FLUSH TABLES WITH READ LOCK 구문이 대기하게 됩니다. 0~21,600초까지 설정 가능합니다. 길게 설정할 수록 DML 쿼리 부하로 인한 백업 실패 가능성을 줄일 수 있으나, 전체 백업 시간이 길어질 수 있습니다.

자동 백업 설정

다음 항목들은 자동 백업 시에만 적용됩니다.

자동 백업 허용

• 자동 백업을 허용하지 않을 시 모든 자동 백업의 수행이 차단되며, 필요에 의해 백업이 수행될 가능성이 있는 복원, 복제 과정을 포함한 일부 작업을 지원하지 않습니다. 또한 아래의 자동 백업 관련 항목들에 대해 설정이 불가능합니다.

자동 백업 보관 기간

• 자동 백업을 백업 스토리지에 저장하는 기간을 설정합니다. 최대 730일까지 보관할 수 있으며, 자동 백업 보관 기간이 변경되면 보관 기간이 지난 자동 백업 파일은 바로 삭제됩니다.

[주의] 증분 방식으로 생성된 백업은 자동 백업 보관 기간이 지나지 않았더라도 기준 백업이 삭제될 때 함께 삭제됩니다.

자동 백업 복제 리전

• 자동 백업 파일을 다른 리전의 백업 스토리지로 복제되도록 설정합니다. 자동 백업 복제 리전은 재해 복구(disaster recovery)를 위한 기능으로 원본 리전의 자동 백업 파일을 대상 리전으로 동일하게 복제하고 관리합니다. 복제는 백그라운드에서 일정 주기마다 진행됩니다. 자동 백업 복제 리전을 설정하면 리전 간 복제 트래픽 비용이 청구되며, 대상 리전에 백업 스토리지 사용량에 대한 비용이 추가로 청구됩니다.

자동 백업 재시도 횟수

• DML 쿼리 부하 또는 여러 다양한 이유로 자동 백업이 실패한 경우 재시도하도록 설정할 수 있습니다. 최대 10회까지 재시도할 수 있습니다. 재시도 횟수가 남아 있더라도 자동 백업 수행 시간 설정에 따라 재시도하지 않을 수 있습니다.

예정된 자동 백업 사용

• 예정된 자동 백업 사용 시 설정한 자동 백업 수행 시간에 자동으로 백업이 수행됩니다.

자동 백업 전략

• 자동 백업을 수행할 전략을 지정할 수 있습니다.
• 매일 전체 백업: 매일 전체 데이터를 백업합니다.
• 매일 전체 및 증분 백업: 매일 전체 데이터를 1회 백업하고, 수 회 증분을 백업합니다.
• 주간 전체 백업 및 일일 증분 백업: 특정 요일에 전체 데이터를 1회 백업하고, 나머지 요일에는 증분을 1회 백업합니다.

전체 데이터 백업 요일

• 주간 전체 백업 및 일일 증분 백업 전략 사용 시에만 지정 가능합니다. 최소 1개~최대 6개의 요일을 선택해야 하며, 선택한 요일에는 전체 백업이 진행되고 선택하지 않은 요일에는 증분 백업이 진행됩니다.

자동 백업 수행 시간

• 백업이 자동으로 수행되는 시간을 설정할 수 있습니다. 백업 시작 시각과 백업 윈도우로 구성됩니다. 백업 수행 시간은 겹치지 않게 여러 번 설정할 수 있습니다. 백업 시작 시각을 기준으로 백업 윈도우 안의 어느 시점에서 백업을 수행합니다. 백업 윈도우는 백업의 총 수행 시간과는 관련이 없습니다. 백업에 걸리는 시간은 데이터베이스 크기에 비례하며, 서비스 부하에 따라 달라집니다. 백업이 실패할 경우 백업 윈도우를 넘지 않았다면 백업 재시도 횟수에 따라 백업을 다시 시도합니다.

[주의] 앞선 백업이 종료되지 않는 등의 상황에서는 백업이 수행되지 않을 수 있습니다. 예정상 증분 백업을 수행할 차례이더라도 증분이 가능한 기준 백업이 존재하지 않는 경우 전체 백업이 수행될 수 있습니다. 증분 가능한 기준 백업에 대한 자세한 설명은 기준 백업 항목을 참고합니다.

백업 스토리지 및 과금

모든 백업 파일은 내부 백업 스토리지에 업로드하여 저장합니다. 수동 백업의 경우 별도로 삭제하기 전까지 영구히 저장되며 백업 용량에 따라 백업 스토리지 과금이 발생합니다. 자동 백업의 경우 설정한 보관 기간만큼 저장되며 자동 백업 파일의 전체 크기 중 DB 인스턴스의 스토리지 크기를 초과한 용량에 대해서 과금합니다. 백업 파일이 저장된 내부 백업 스토리지에 직접 접근할 수 없으며, 백업 파일이 필요한 경우 NHN Cloud의 오브젝트 스토리지로 백업 파일을 내보낼 수 있습니다.

백업 내보내기

백업을 수행하면서 파일 내보내기

백업 후 백업 파일을 사용자 오브젝트 스토리지로 내보낼 수 있습니다. 증분 백업에 대해서는 지원되지 않습니다.

❶ 백업할 DB 인스턴스를 선택한 뒤 드롭다운 메뉴에서 백업 후 오브젝트 스토리지로 백업 파일 내보내기를 클릭하면 설정 팝업 화면이 나타납니다. ❷ 백업이 저장될 오브젝트 스토리지의 테넌트 ID를 입력합니다. 테넌트 ID는 API 엔드포인트 설정에서 확인할 수 있습니다. ❸ 백업이 저장될 오브젝트 스토리지의 NHN Cloud 계정 또는 IAM 계정을 입력합니다. ❹ 백업이 저장될 오브젝트 스토리지의 API 비밀번호를 입력합니다. ❺ 백업이 저장될 오브젝트 스토리지의 컨테이너를 입력합니다. ❻ 컨테이너에 저장될 백업의 경로를 입력합니다. 폴더 이름은 최대 255바이트이고, 전체 경로는 최대 1024바이트입니다. 특정 형태(. 또는 ..)는 사용할 수 없으며 특수문자(' " < > ;)와 공백은 입력할 수 없습니다.

백업 파일 내보내기

내부 백업 스토리지에 저장된 백업 파일을 사용자 오브젝트 스토리지로 내보낼 수 있습니다. 증분 백업에 대해서는 지원되지 않습니다.

❶ 백업을 수행한 원본 DB 인스턴스의 상세 탭에서 내보낼 백업 파일을 선택한 뒤 오브젝트 스토리지로 백업 내보내기를 클릭하면 백업을 내보내기 위한 팝업 화면이 나타납니다.

❷ 또는 백업 탭에서 내보낼 백업 파일을 선택한 뒤 오브젝트 스토리지로 백업 내보내기를 클릭합니다.

[참고] 수동 백업의 경우 백업을 수행한 원본 DB 인스턴스가 삭제되었다면 백업을 내보낼 수 없습니다.

복원

백업을 이용하여 원하는 시점으로 데이터를 복원할 수 있습니다. 복원 시 항상 새로운 DB 인스턴스가 생성되며, 기존 DB 인스턴스에 복원할 수 없습니다. 백업을 수행한 원본 DB 인스턴스와 동일한 DB 엔진 버전으로만 복원할 수 있습니다. 백업이 생성된 시점으로 복원하는 스냅숏 복원, 원하는 특정 시점으로 복원하는 시점 복원을 지원합니다. RDS for MySQL에서 생성한 백업뿐만 아니라 외부 MySQL의 백업으로도 복원할 수 있습니다.

[주의] 복원할 DB 인스턴스의 데이터 스토리지 크기가 백업을 수행한 원본 DB 인스턴스의 데이터 스토리지 크기보다 작거나, 원본 DB 인스턴스의 파라미터 그룹과 다른 파라미터 그룹을 사용할 경우 복원에 실패할 수 있습니다.

스냅샷 복원

백업 파일만으로 복원을 진행해 백업을 수행한 원본 DB 인스턴스가 필요하지 않습니다. 콘솔에서 스냅샷을 복원하려면

❶ DB 인스턴스의 상세 탭에서 복원할 백업 파일을 선택한 뒤 스냅샷 복원을 클릭하면 DB 인스턴스 복원 화면으로 이동합니다.

또는

❶ 백업 탭에서 복원할 백업 파일을 선택한 뒤 스냅샷 복원을 클릭합니다.

시점 복원

시점 복원을 이용하여 원하는 특정 시점 또는 바이너리 로그(binary log)의 특정 포지션으로 복원할 수 있습니다. 시점 복원을 하기 위해서는 백업 파일과 백업을 수행한 시점으로부터 복원을 원하는 시점까지의 바이너리 로그(binary log)가 필요합니다. 바이너리 로그(binary log)는 백업이 수행되는 원본 DB 인스턴스의 스토리지에 저장됩니다. 바이너리 로그(binary log) 보관 기간이 짧으면 스토리지 용량을 더 많이 사용할 수 있지만, 원하는 시점으로 복원이 어려울 수 있습니다. 아래 나열된 경우 시점 복원에 필요한 바이너리 로그(binary log)가 없기 때문에 원하는 시점으로 복원하지 못할 수 있습니다.

• 용량 확보를 위해 원본 DB 인스턴스의 바이너리 로그(binary log)를 삭제한 경우
• 바이너리 로그(binary log) 보관 기간에 따라 MySQL에 의해 자동으로 바이너리 로그(binary log)가 삭제된 경우
• 고가용성 DB 인스턴스의 장애 조치로 인해 바이너리 로그(binary log)가 삭제된 경우
• 기타 다양한 이유로 바이너리 로그(binary log)가 손상되거나 삭제된 경우

콘솔에서 시점 복원을 하려면

❶ 시점 복원할 DB 인스턴스를 선택한 뒤 + 시점 복원을 클릭하면 시점 복원을 설정할 수 있는 페이지로 이동합니다.

Timestamp를 이용한 복원

Timestamp를 사용한 복원 시에는 선택한 시점과 가장 가까운 백업 파일을 기준으로 복원을 진행한 뒤, 원하는 시점까지의 바이너리 로그(binary log)를 적용합니다.

❶ 복원 방법을 선택합니다.

❷ 복원 시각을 선택합니다. 가장 최근 시점으로 복원하거나, 원하는 특정 시점을 직접 입력할 수 있습니다.

❸ 복원될 마지막 쿼리 확인을 클릭하면 마지막으로 복원될 쿼리를 확인할 수 있는 팝업 화면이 표시됩니다.

바이너리 로그(binary log)를 이용한 복원

바이너리 로그(binary log)를 활용한 복원 과정에서는 선택한 백업 파일로 먼저 복원을 진행한 후, 원하는 위치까지의 바이너리 로그(binary log)를 적용합니다.

❹ 바이너리 로그(binary log)로 복원을 하기 위해서는 먼저 백업 파일을 선택해야 합니다. ❺ 바이너리 로그(binary log) 파일을 선택합니다. ❻ 바이너리 로그(binary log)의 특정 위치를 입력합니다.

외부 MySQL 백업을 이용한 복원

외부 MySQL 백업 파일을 이용하여 DB 인스턴스를 생성할 수 있습니다. 외부 MySQL 백업 파일을 생성할 때 백업 항목을 참고하여 RDS for MySQL에서 사용하는 Percona XtraBackup과 동일한 버전을 사용해야 합니다.

[주의] innodb_data_file_path의 설정값이 ibdata1:12M:autoextend가 아니면 RDS for MySQL의 DB 인스턴스로 복원할 수 없습니다.

(1) MySQL이 설치된 서버에서 아래의 명령어를 이용하여 백업을 수행합니다.

XtraBackup 2.4.xx 예제

innobackupex --defaults-file={my.cnf 경로} --user {사용자} --password '{비밀번호}' --socket {MySQL 소켓 파일 경로} --compress --compress-threads=1 --stream=xbstream {백업 파일이 생성될 디렉터리} 2>>{백업 로그 파일 경로} > {백업 파일 경로}

XtraBackup 8.0.xx 예제

xtrabackup --defaults-file={my.cnf 경로} --user={사용자} --password='{비밀번호}' --socket={MySQL 소켓 파일 경로} --compress --compress-threads=1 --stream=xbstream --backup {백업 파일이 생성될 디렉터리} 2>>{백업 로그 파일 경로} > {백업 파일 경로}

(2) 백업 로그 파일의 마지막 줄에 completed OK!가 있는지 확인합니다. completed OK!가 없다면 백업이 정상적으로 종료되지 않은 것이므로 로그 파일에 있는 에러 메시지를 참고하여 백업을 다시 진행합니다.

(3) 완료된 백업 파일을 오브젝트 스토리지에 업로드합니다.

• 한 번에 업로드할 수 있는 최대 파일 크기는 5GB입니다.
• 백업 파일의 크기가 5GB보다 클 경우 split과 같은 유틸리티를 이용해 백업 파일을 5GB 이하로 자른 뒤 멀티 파트로 업로드해야 합니다.
• 자세한 사항은 멀티파트 업로드를 참고합니다.

(4) 복원할 프로젝트의 콘솔에 접속한 뒤 DB 인스턴스 탭에서 오브젝트 스토리지에 있는 백업으로 복원 버튼을 클릭합니다.

[주의] 현재 5.7.33 버전에서는 오브젝트 스토리지의 백업 파일을 이용한 DB 인스턴스 복원은 제한됩니다. 권장하는 XtraBackup 이외의 버전을 사용하면 정상으로 동작하지 않을 수 있습니다. 오브젝트 스토리지의 백업 파일과 복원하려는 MySQL의 버전은 동일해야 합니다.

RDS for MySQL 백업을 이용한 복원

RDS for MySQL의 백업 파일을 이용하여 직접 MySQL의 데이터베이스를 복원할 수 있습니다. 전체 백업에 대해서만 복원이 가능하며, 증분 백업 반영은 지원되지 않습니다. RDS for MySQL 백업 파일을 복원할 때 백업 항목을 참고하여 RDS for MySQL에서 사용하는 Percona XtraBackup과 동일한 버전을 사용해야 합니다.

(1) 백업 내보내기 항목을 참고하여 RDS for MySQL의 백업을 오브젝트 스토리지로 내보냅니다.

(2) 오브젝트 스토리지의 백업을 복원하고자 하는 서버에 다운로드합니다.

(3) MySQL 서비스를 정지합니다.

(4) MySQL 데이터 저장 경로의 모든 파일을 삭제합니다.

rm -rf {MySQL 데이터 저장 경로}/*

(5) 다운로드한 백업 파일의 압축을 해제하고 복원합니다.

XtraBackup 2.4.xx 예제

cat {백업 파일 저장 경로} | xbstream -x -C {MySQL 데이터 저장 경로}
innobackupex --decompress {MySQL 데이터 저장 경로}
innobackupex --defaults-file={my.cnf 경로} --apply-log {MySQL 데이터 저장 경로}

XtraBackup 8.0.xx 예제

cat {백업 파일 저장 경로} | xbstream -x -C {MySQL 데이터 저장 경로}
xtrabackup --decompress --target-dir={MySQL 데이터 저장 경로}
xtrabackup --prepare --target-dir={MySQL 데이터 저장 경로}
xtrabackup --defaults-file={my.cnf 경로} --copy-back --target-dir={MySQL 데이터 저장 경로}

(6) 압축 해제 후 불필요한 파일을 제거합니다.

find {MySQL 데이터 저장 경로} -name "*.qp" -print0 | xargs -0 rm

(7) MySQL 서비스를 시작합니다.