DBAtlas · 데이터베이스 운영 아틀라스

Percona XtraBackup을 이용한 백업, 복원 및 PITR

MySQL난이도: 중급소요 시간: 45–90분

Percona XtraBackup을 이용한 물리 백업: 호환되는 XtraBackup 버전 설치, auth_socket 기반 백업 사용자, 압축/암호화 full + incremental 백업 스크립트, systemd timer 또는 cron 스케줄링, binlog 복사, 복원 리허설을 다룹니다. 시나리오 카드에서는 전체 복원, incremental 체인 복원, 특정 시점 복구(PITR), 단일 테이블 복원, 백업으로 replica 구성, 다른 서버로의 복원을 수행합니다. 대용량 데이터베이스의 일일 백업과 재해 복구에는 이 가이드를, 이관, 단일 스키마/테이블 덤프, 버전 간 이전에는 논리 백업(mysqldump / MySQL Shell) 가이드를 사용합니다.

구성: 서버 1대(단일 서버, source, replica 또는 InnoDB Cluster secondary), 백업 저장소는 로컬 디스크 또는 NFS

시나리오

  • 백업 구성, 스케줄링 및 복원 테스트(전체 흐름) — XtraBackup 설치, 백업 사용자, full + incremental 백업 스크립트, 스케줄링, 복원 리허설(PITR 포함)을 수행합니다. 처음 구성하는 경우 이 항목을 선택합니다. 백업은 서버가 가동 중인 상태에서 수행되므로 다운타임은 없고 디스크/CPU 부하만 늘어납니다.
  • 전체 복원: 최신 full 백업으로 되돌리기 — 데이터 디렉터리가 유실/손상되었거나 서버가 기동되지 않으며, 체인의 full 백업으로 되돌리는 것으로 충분한 경우입니다. 복원하는 동안 MySQL은 중지된 상태입니다.
  • full + incremental 체인으로 복원(최신 incremental까지) — 최신 incremental 백업 시점(또는 선택한 incremental 시점)으로 되돌리려는 경우입니다. full 백업 위에 incremental을 --apply-log-only로 순서대로 적용합니다. 복원하는 동안 MySQL은 중지된 상태입니다.
  • 특정 시점 복구(PITR): 잘못된 DELETE / DROP 직전으로 — 실수로 삭제되거나 손상된 데이터: 최신 백업을 복원하고 binlog를 문제 transaction 직전까지(시간, 위치 또는 GTID 기준) 적용합니다. 복원하는 동안 MySQL은 중지되며, 문제 발생 이후의 쓰기도 함께 되돌려집니다. 테이블 하나만 영향을 받았다면 먼저 단일 테이블 시나리오를 검토합니다.
  • 단일 테이블 복원(--export + IMPORT TABLESPACE) — 테이블 하나의 백업 시점 데이터만 필요한 경우입니다. 서버 전체를 복원하지 않고 해당 테이블을 백업에서 t_restore라는 이름으로 가져온 뒤 그 데이터로 수정합니다. 서버는 계속 가동됩니다.
  • 백업으로 새 replica 구성 — 새로 구성하거나 재구성할 replica를 네트워크 clone 대신 기존 XtraBackup 백업으로 준비하여 source에 연결하려는 경우입니다(대용량 데이터, source 부하). source는 영향을 받지 않으며, 대상 서버의 데이터는 교체됩니다.
  • 다른 서버로 백업 복원(이관, 테스트, 복제) — 운영 백업을 테스트/개발 서버에서 열거나, 서버를 이관하거나, 백업이 실제로 복원되는지 별도 서버에서 검증하려는 경우입니다. 원본 서버는 영향을 받지 않습니다.

시작하기 전에

  • MySQL …이 실행 중이며(DBAtlas MySQL 단일 서버 설치 가이드로 설치했다면 경로가 동일합니다), 운영체제 root가 mysql 명령으로 비밀번호 없이 접속할 수 있습니다(auth_socket 또는 ~/.mylogin.cnf).
  • 백업 디렉터리 …는 별도 디스크/NFS에 있으며 최소 (데이터 크기 × 체인 수)만큼의 공간이 있습니다…(zstd로 보통 3–6배 줄어듭니다)…. 복원에는 … 아래에 데이터 크기의 최소 2배 여유 공간이 필요합니다(압축 해제 + prepare).
  • Binary log가 켜져 있고 GTID가 활성화되어 있습니다(PITR 및 incremental 일관성 확보).
  • 서버가 HTTPS로 repo.percona.com에 접근할 수 있거나 사내 미러가 설정되어 있습니다.
  • 암호화 키 사본을 서버 외부의 안전한 곳(금고, 비밀번호 관리자)에 보관할 준비가 되어 있습니다. 키를 잃으면 백업을 열 수 없습니다.
  • 복원 테스트용으로 가급적 별도의 테스트 서버(같은 MySQL 버전, 같은 my.cnf로 설치)가 있습니다. 복원 단계는 실행되는 서버의 데이터 디렉터리를 교체합니다.
  • 이 서버는 정상 상태의 replica입니다. IO 및 SQL thread가 Yes이고 지연이 작습니다. binlog를 복사한다면(PITR) log_replica_updates가 켜져 있어야 합니다(8.x 기본값은 켜짐). 그렇지 않으면 replica의 binlog에 source에서 받은 transaction이 포함되지 않습니다.
  • 이 서버는 InnoDB Cluster 멤버이며 현재 SECONDARY / ONLINE입니다. 백업은 이 멤버에 스케줄링되며, 나중에 멤버가 primary가 되면 스크립트는 경고를 기록하고 백업을 계속 받습니다.
  • 복원할 백업 체인은 … 아래…(… 서버)…에 있고 완전합니다. full과 사용할 incremental이 -lsn 메타 디렉터리와 함께 있습니다…. 암호화 키는 …….
  • 이 서버에 MySQL …과 XtraBackup …이 설치되어 있고, MySQL 마이너 버전은 백업을 받은 서버와 같거나 더 최신입니다(백업의 server_version 값은 진단 단계에서 표시됩니다).
  • …대상 서버에 보존할 데이터가 없습니다. 데이터 디렉터리는 백업으로 교체됩니다(기존 디렉터리는 .old-<timestamp>로 옮겨 둡니다).…유지보수 시간과 애플리케이션 중단이 승인되었습니다. 복원하는 동안 MySQL은 중지되며, 애플리케이션은 이 서버에 접속하지 않아야 합니다.…
  • 테이블은 InnoDB이며 innodb_file_per_table = ON(8.x 기본값)으로 자체 .ibd 파일에 있습니다. 테이블 구조(컬럼, 인덱스)는 백업 이후 변경되지 않았습니다. 서버는 계속 가동됩니다.

가이드 단계

  • XtraBackup 설치 — Percona 저장소 추가 · XtraBackup 설치
  • 백업 사용자 및 키 — auth_socket 플러그인 확인 · 백업 사용자 생성 · 접속 테스트 · 암호화 키 생성
  • 백업 스크립트 및 스케줄링 — 백업 디렉터리 생성 · 백업 스크립트 작성 · 스크립트 실행 권한 부여 · 첫 full 백업 받기 · Incremental 백업 시험 · systemd 서비스 작성 …
  • 복원(restore) — 체인을 작업 디렉터리로 복사 · 비밀번호 해제 / 압축 해제 · Full 백업 prepare(apply-log-only) · Incremental 순서대로 적용 · 최종 prepare · MySQL 중지 및 기존 데이터 이동 …
  • 특정 시점 복구(PITR) — 대상 시각 확인 · 대상 시각까지 binlog 적용 · 결과 확인 및 새 백업
  • 정리 — 옮겨 둔 데이터와 작업 디렉터리 삭제
  • 1. 진단: 어떤 백업, 어떤 방법? — 서버 상태 및 버전 확인 · 백업 체인과 내용 나열
  • 2. 안전장치 — 현재 상태 및 설정 기록
  • 3. 적용: 백업 prepare — 체인을 작업 디렉터리로 복사 · 체인을 작업 디렉터리로 복사 · 비밀번호 해제 / 압축 해제 · Full 백업 prepare(apply-log-only) · Incremental 순서대로 적용 · 최종 prepare
  • 3. 적용: 데이터 복원 — MySQL 중지 및 기존 데이터 이동 · 백업을 데이터 디렉터리로 복사(copy-back) · MySQL 기동 및 확인 · 백업에서 복원된 복제 설정 확인
  • 3. 적용: 대상 지점까지 binlog 적용(PITR) — 문제 transaction과 대상 지점 확인 · 대상 지점까지 binlog 적용
  • 4. 검증 — 문제 transaction이 되돌려졌는지 확인 · 데이터 확인
  • 5. 사후 작업 — 새 full 백업 받기 · 옮겨 둔 데이터와 작업 디렉터리 삭제 · 근본 원인과 토폴로지
  • 1. 진단: 테이블과 백업이 적합한가? — 테이블의 현재 상태와 구조 표시 · 백업 체인과 내용 나열
  • 2. 안전장치 — 테이블의 현재 상태 백업
  • 3. 적용: --export로 백업 prepare — 체인을 작업 디렉터리로 복사 · 비밀번호 해제 / 압축 해제 · Full 백업 prepare(apply-log-only) · Incremental 순서대로 적용 · 최종 prepare(--export)
  • 3. 적용: 테이블을 중간 테이블로 가져오기 — 중간 테이블 생성 및 tablespace 분리 · 백업의 파일 복사 및 가져오기(IMPORT TABLESPACE)
  • 4. 검증 — 중간 테이블 확인 및 원래 테이블과 비교
  • 5. 사후 작업: 데이터 옮기기 및 정리 — 필요한 행을 원래 테이블로 옮기기 · 중간 테이블과 작업 디렉터리 삭제
  • 1. 진단: 대상 서버와 백업이 적합한가? — 대상 서버의 버전, 식별 정보, 디스크 확인 · 백업 체인과 내용 나열(…)
  • 2. 안전장치 — 현재 상태 및 설정 기록
  • 3. 적용: 백업 가져오기 및 prepare — 백업 서버에서 체인 가져오기 · 체인을 작업 디렉터리로 복사 · 비밀번호 해제 / 압축 해제 · Full 백업 prepare(apply-log-only) · Incremental 순서대로 적용 · 최종 prepare
  • 3. 적용: 데이터 복원 — MySQL 중지 및 기존 데이터 이동 · 백업을 데이터 디렉터리로 복사(copy-back) · MySQL 기동 및 확인 · 백업에서 복원된 복제 설정 확인
  • 3. 적용: 백업 지점에서 복제 시작 — 시작 지점 확인 · 복제 설정 및 시작
  • 4. 검증 — 데이터 확인
  • 5. 사후 작업 — 옮겨 둔 데이터와 작업 디렉터리 삭제 · 서버를 새 역할로 운영 투입
내 환경에 맞춘 단계별 계획 열기 →