MySQL 백업 전략 개요: 논리·물리·스냅샷과 binlog 조합

백업 작업이 성공했다는 사실과 서비스를 복구할 수 있다는 사실은 다르다. 백업 파일이 있어도 복호화 키가 없거나, 기준 백업 이후의 binlog 한 구간이 사라졌거나, 복원에 예상보다 오래 걸리면 업무 요구를 만족하지 못한다. 백업 전략은 도구를 고르는 작업이 아니라 어떤 장애에서 어느 시점의 데이터를 얼마 만에 다시 제공할 것인지를 정하는 작업이다.

이 글에서는 MySQL 8.0 이상을 기준으로 logical, physical, snapshot, binlog를 하나의 복구 체계로 묶는다. SQL과 소규모 논리 백업·복원은 MySQL 8.0에서 실행 검증하며, 물리 백업 도구·스토리지 스냅샷·Aurora 복원은 설계 원칙과 검증 항목을 다룬다. 이들 모두를 실제 장애 환경에서 시험한 결과로 해석해서는 안 된다.

1. 백업 종류보다 먼저 복구 요구를 정의한다

RPO(Recovery Point Objective)는 장애 때 허용할 데이터 손실 구간이다. RTO(Recovery Time Objective)는 업무가 허용하는 복구 시간이다. 전날 백업을 확보해도 그 이후 로그가 없으면 전날 이후의 변경을 잃을 수 있다. 반대로 최신 로그가 전부 있어도 기준 백업 복원과 로그 재생이 오래 걸리면 RTO를 만족하지 못한다.

두 목표를 다음과 같이 나누어 검증한다.

• RPO: 장애 직전까지 커밋된 변경 중, 격리된 복구 환경에서 실제로 재현 가능한 마지막 지점을 확인한다. 백업 작업의 종료 시각만 보지 않는다.
• RTO: 장애 판단, 복구 자원 확보, 파일 전송·복호화, 기준 백업 복원, 로그 적용, 데이터 검증, 접속 전환, 캐시 준비에 걸리는 전체 시간을 측정한다.
• 복구 범위: 전체 인스턴스, 특정 데이터베이스, 일부 테이블, 개별 업무 데이터 중 무엇을 복구해야 하는지 구분한다.
• 장애 범위: 서버 고장뿐 아니라 잘못된 배포, 대량 삭제, 스토리지 손상, 계정 탈취, 암호화 키 상실을 포함한다.

동일 계정에서 삭제 가능한 백업만 여러 개 보관하는 것은 계정 탈취에 대한 격리가 아니다. 같은 스토리지 풀 안의 스냅샷만으로는 그 풀 전체의 손실에 대비하기 어렵다. 복구 목표에는 데이터 보존과 접근 권한의 장애 영역 분리가 함께 들어가야 한다.

2. 네 가지 방식은 서로 다른 계층을 담당한다

이 분류는 완전히 독립적이지 않다. 스냅샷은 물리 상태를 얻는 수단으로 쓰일 수 있고, 논리 백업과 물리 백업 모두 PITR의 기준점이 될 수 있다. binlog만 있다고 전체 데이터를 재구성할 수 있는 것은 아니다. 일반적인 운영 복구에는 복구 가능한 기준 백업과 그 기준점에 정확히 연결되는 변경 이력이 필요하다.

논리 백업: 읽을 수 있는 데이터가 복원 작업으로 바뀐다

mysqldump는 메타데이터와 행을 읽어 SQL 형태로 기록한다. --single-transaction은 InnoDB 데이터에 대해 일관된 읽기 스냅샷을 사용하고, --quick은 큰 결과를 클라이언트 메모리에 모두 모으지 않도록 한다. 두 옵션은 데이터베이스 전체의 쓰기를 영구히 중단시키지 않고 덤프하려는 기본 조합이다.

그러나 일관성의 범위를 확대 해석하면 안 된다. MyISAM 같은 비트랜잭션 테이블은 같은 보장을 받지 않는다. 덤프 도중 ALTER TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE 같은 DDL이 겹치면 일관된 읽기만으로 안전한 결과를 보장하지 못한다. DDL 작업을 통제하고, 필요한 메타데이터 잠금과 백업 옵션의 상호작용을 확인해야 한다.

장시간 스냅샷은 오래된 행 버전의 정리를 지연시킬 수 있다. 덤프가 CPU를 적게 쓰더라도 undo 보존, 스토리지 읽기, 버퍼 풀 오염 때문에 운영 지연이 늘 수 있다. 복제본에서 덤프하면 writer의 직접 부하는 줄지만, 복제 지연과 그 복제본의 실제 적용 경계를 새로 검증해야 한다.

논리 복원은 파일을 복사하는 일이 아니다. SQL을 파싱하고 행을 넣고 인덱스를 구성하는 작업이다. 백업 속도만으로 복원 시간을 추정하지 말고, 실제 데이터 크기·인덱스 수·제약조건·병렬 적재 방식을 반영한 복원 시험을 수행한다.

물리 백업: 파일 복사에 복구 프로토콜이 추가된다

온라인 상태의 데이터 파일은 서로 다른 시점에 변경된다. 단순히 데이터 디렉터리를 차례로 복사하면 페이지와 로그의 시점이 어긋날 수 있다. 온라인 물리 백업 도구는 복사 중 발생한 변경을 추적하고, 도구가 요구하는 준비 단계에서 복구 가능한 상태로 만든다. 도구에 따라 redo 적용과 미완료 트랜잭션 정리 방식·시점이 다르므로 절차를 섞어 쓰지 않는다.

Community MySQL에서도 정상 종료 후의 완전한 파일 집합 복사나 호환성이 확인된 외부 물리 백업 도구를 검토할 수 있다. 다만 'MySQL 8 계열 지원'이라는 표현만으로 충분하지 않다. 정확한 서버 버전, 페이지 형식, 암호화·키 관리 방식, 도구 버전, 복원 대상 버전을 지원 표와 실제 시험으로 확인한다. 물리 백업을 임의의 상위·하위 버전에 바로 올리는 것은 일반적인 버전 이관 절차가 아니다.

스냅샷: 빠른 생성과 복구 일관성은 별개다

스토리지 스냅샷이 순식간에 생성되어도 MySQL 관점에서 필요한 파일들이 같은 복구 지점에 있어야 한다. 데이터, redo, undo, 별도 테이블스페이스가 여러 볼륨에 나뉘어 있으면 볼륨 집합을 원자적으로 캡처하는지 확인한다. 키 관리 자료도 복구 시 사용할 수 있어야 한다.

crash-consistent 스냅샷은 갑작스러운 전원 차단과 같은 상태에서 시작해 엔진의 crash recovery를 거치는 방식이다. application-consistent 백업은 애플리케이션·데이터베이스와 협력해 더 강한 정합성 경계를 만든다. InnoDB의 crash recovery가 있다고 해서 임의로 얻은 일부 파일 사본이나 비트랜잭션 테이블까지 안전해지는 것은 아니다.

스냅샷 생성 완료, 외부 저장소로의 내보내기 완료, 독립된 환경에서의 복원 성공도 서로 다른 단계다. 복원 직후 지연 로딩이나 캐시 미적중이 발생할 수 있으므로 서비스 성능이 회복되는 시간까지 측정한다.

3. 기준 백업과 binlog는 경계가 맞아야 연결된다

flowchart LR
    A[일관된 기준 백업] --> B[격리된 서버에 복원]
    M[백업 메타데이터와 복구 키] --> B
    C[기준 경계 이후의 연속 binlog] --> D[선택한 트랜잭션까지 재생]
    B --> D
    D --> E[데이터와 업무 규칙 검증]
    E --> F[접속 전환과 서비스 확인]
    G[사고 트랜잭션 식별] --> D

기준 백업에 이미 포함된 변경을 다시 재생하면 중복 적용될 수 있고, 시작 위치를 너무 앞으로 잡으면 변경이 누락된다. 덤프가 끝난 뒤 별도 연결에서 조회한 binlog 위치는 덤프의 일관된 스냅샷 경계와 같다고 보장할 수 없다. 백업 방식과 결합된 절차로 좌표를 얻어야 한다.

MySQL 8.0.26 이상 mysqldump에서는 --source-data=2로 복제 좌표를 주석 형태로 기록할 수 있다. 이전 8.0 클라이언트의 옵션 명칭과 구분한다. --single-transaction과 함께 써도 시작 단계의 짧은 전역 읽기 잠금과 추가 권한이 필요할 수 있다. '온라인 백업'을 '잠금이 전혀 없는 백업'으로 해석하지 않는다.

GTID는 실행 이력을 식별하지만 데이터 파일이나 데이터 일치 증명서는 아니다. 부분 데이터베이스 덤프에 기록된 서버 전체 GTID 집합을 전체 데이터 복구 완료의 근거로 사용해서는 안 된다. 복제본 재구축용 덤프인지, 테이블 이관용 덤프인지에 따라 --set-gtid-purged 정책을 구분한다.

binlog는 파일 번호의 연속성뿐 아니라 동일 이력의 올바른 순서와 트랜잭션 경계를 보존해야 한다. 보관 주기가 길면 서버가 손실될 때 아직 외부로 보내지 않은 구간을 잃는다. 서버의 자동 만료 시간보다 수집 지연과 장애 대응 시간을 충분히 짧게 관리하고, 서버가 로그를 지우기 전에 외부 사본의 완전성을 검증한다.

사고 복구에서는 시각을 탐색의 단서로 쓰되, 최종 중단점은 실제 이벤트와 커밋 경계를 확인한다. 잘못된 삭제 트랜잭션까지 다시 적용하면 백업을 복원하고도 같은 사고를 재현한다. 시간대와 시계 차이, 여러 트랜잭션이 같은 초에 커밋하는 경우를 고려한다. 세부 mysqlbinlog 재생 절차는 PITR 전용 실습에서 다루는 편이 안전하다.

로그·내구성 관련 설정을 먼저 확인한다

SELECT VERSION() AS mysql_version,
       @@global.log_bin AS log_bin,
       @@global.binlog_format AS binlog_format,
       @@global.gtid_mode AS gtid_mode;
SELECT @@global.sync_binlog AS sync_binlog,
       @@global.innodb_flush_log_at_trx_commit AS flush_at_commit,
       @@global.binlog_expire_logs_seconds AS binlog_retention_seconds;

실행 결과(MySQL 8.0.x):

mysql> SELECT VERSION() AS mysql_version,
    ->        @@global.log_bin AS log_bin,
    ->        @@global.binlog_format AS binlog_format,
    ->        @@global.gtid_mode AS gtid_mode;

+---------------+---------+---------------+-----------+
| mysql_version | log_bin | binlog_format | gtid_mode |
+---------------+---------+---------------+-----------+
| 8.0.46        |       0 | ROW           | OFF       |
+---------------+---------+---------------+-----------+
1 row in set (0.00 sec)

mysql> SELECT @@global.sync_binlog AS sync_binlog,
    ->        @@global.innodb_flush_log_at_trx_commit AS flush_at_commit,
    ->        @@global.binlog_expire_logs_seconds AS binlog_retention_seconds;

+-------------+-----------------+--------------------------+
| sync_binlog | flush_at_commit | binlog_retention_seconds |
+-------------+-----------------+--------------------------+
|           1 |               1 |                  2592000 |
+-------------+-----------------+--------------------------+
1 row in set (0.00 sec)

위 결과는 예제용 인스턴스의 설정이며, 조회 시 발생한 형식 변수의 폐기 예정 경고 표시는 생략했다. 이 실습에서는 binlog를 비활성화했으므로 이 상태만으로 PITR을 수행할 수 없다. MySQL 8.4에서는 ROW 형식 중심으로 운영하며, 형식 관련 변수의 지원·폐기 예정 여부도 해당 버전 문서에서 확인한다.

sync_binlog와 innodb_flush_log_at_trx_commit은 커밋 내구성에 관련되지만 원격 백업 완료 여부를 나타내지 않는다. 둘을 강하게 설정해도 서버와 저장소를 함께 잃는 사고에 대비하려면 별도 보관이 필요하다. binlog_expire_logs_seconds 역시 로컬 자동 만료 정책일 뿐, 외부 아카이브의 보존 기간이나 수집 성공 지표가 아니다.

4. 작은 논리 백업으로 복원 검증의 최소 단위를 만든다

다음은 별도 실습 인스턴스에서만 수행하는 예제다. backup_lab과 restore_lab이라는 비어 있는 새 스키마를 사용한다. 같은 서버의 다른 스키마에 복원하므로 덤프·적재와 데이터 비교의 검증이며, 서버 전체 손실·다른 버전 복원·계정 복구·PITR 시험은 아니다.

CREATE DATABASE backup_lab CHARACTER SET utf8mb4;
CREATE DATABASE restore_lab CHARACTER SET utf8mb4;
CREATE TABLE backup_lab.orders (
    order_id BIGINT PRIMARY KEY,
    amount DECIMAL(12,2) NOT NULL,
    status VARCHAR(16) NOT NULL
) ENGINE=InnoDB;
INSERT INTO backup_lab.orders VALUES
    (1, 10000.00, 'PAID'),
    (2, 20000.00, 'PAID'),
    (3, 30000.00, 'NEW');
SELECT TABLE_NAME, ENGINE
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'backup_lab' AND TABLE_TYPE = 'BASE TABLE';
SELECT COUNT(*) AS row_count, SUM(amount) AS total_amount
FROM backup_lab.orders;

실행 결과(MySQL 8.0.x):

mysql> CREATE DATABASE backup_lab CHARACTER SET utf8mb4;

Query OK, 1 row affected (0.00 sec)

mysql> CREATE DATABASE restore_lab CHARACTER SET utf8mb4;

Query OK, 1 row affected (0.00 sec)

mysql> CREATE TABLE backup_lab.orders (
    ->     order_id BIGINT PRIMARY KEY,
    ->     amount DECIMAL(12,2) NOT NULL,
    ->     status VARCHAR(16) NOT NULL
    -> ) ENGINE=InnoDB;

Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO backup_lab.orders VALUES
    ->     (1, 10000.00, 'PAID'),
    ->     (2, 20000.00, 'PAID'),
    ->     (3, 30000.00, 'NEW');

Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

mysql> SELECT TABLE_NAME, ENGINE
    -> FROM information_schema.TABLES
    -> WHERE TABLE_SCHEMA = 'backup_lab' AND TABLE_TYPE = 'BASE TABLE';

+------------+--------+
| TABLE_NAME | ENGINE |
+------------+--------+
| orders     | InnoDB |
+------------+--------+
1 row in set (0.01 sec)

mysql> SELECT COUNT(*) AS row_count, SUM(amount) AS total_amount
    -> FROM backup_lab.orders;

+-----------+--------------+
| row_count | total_amount |
+-----------+--------------+
|         3 |     60000.00 |
+-----------+--------------+
1 row in set (0.00 sec)

이어지는 명령은 접속 설정을 환경에 맞춰 사용하는 Bash 예시다. backup과 restore는 미리 준비한 MySQL login path 이름이며, 실제 운영 비밀번호를 명령행 인자로 넣지 않는다. 시험에서는 같은 덤프 옵션을 사용하고 폐기용 컨테이너의 로컬 인증으로 접속했다. 클라이언트는 MySQL 8.0 계열을 사용했다.

set -euo pipefail
umask 077
mysqldump --login-path=backup \
  --single-transaction --quick \
  --routines --events --triggers --no-tablespaces \
  --set-gtid-purged=OFF \
  --result-file=backup_lab.sql backup_lab
test -s backup_lab.sql

mysql --login-path=backup \
  -e 'DELETE FROM backup_lab.orders WHERE order_id = 2;'
mysql --login-path=restore restore_lab < backup_lab.sql
mysql --login-path=restore --table -e "
SELECT 'source_after_delete' AS dataset,
       COUNT(*) AS row_count, SUM(amount) AS total_amount
FROM backup_lab.orders
UNION ALL
SELECT 'restored_backup', COUNT(*), SUM(amount)
FROM restore_lab.orders;
SELECT order_id, amount, status
FROM restore_lab.orders ORDER BY order_id;"

삭제 명령은 기준 백업 이후의 사고를 흉내 내는 실습 전용이다. 운영 원본에는 실행하지 않는다. 같은 서버에서 비교하므로 예제의 복원 접속에는 양쪽 스키마 조회 권한이 필요하다. restore_lab은 앞서 만든 빈 스키마여야 한다. 실제 복원은 기존 운영 테이블을 덮어쓰지 않도록 분리된 대상에서 시작한다.

복원 비교 결과(MySQL 8.0.46):

덤프와 적재 명령 모두 종료 코드 0을 확인했다. 아래는 실제 비교 결과이며, 첫 번째 조회의 긴 SQL 프롬프트만 줄였다.

mysql> SELECT ... UNION ALL SELECT ...;
+---------------------+-----------+--------------+
| dataset             | row_count | total_amount |
+---------------------+-----------+--------------+
| source_after_delete |         2 |     40000.00 |
| restored_backup     |         3 |     60000.00 |
+---------------------+-----------+--------------+
2 rows in set (0.00 sec)

mysql> SELECT order_id, amount, status FROM restore_lab.orders ORDER BY order_id;
+----------+----------+--------+
| order_id | amount   | status |
+----------+----------+--------+
|        1 | 10000.00 | PAID   |
|        2 | 20000.00 | PAID   |
|        3 | 30000.00 | NEW    |
+----------+----------+--------+
3 rows in set (0.00 sec)

원본에서는 삭제된 행이 복원본에는 남아 있다. 별도 검증에서 백업 직전 원본의 모든 행과 복원본의 기본 키·금액·상태를 비교해 일치함을 확인했다. 이 결과는 백업 시점의 상태를 복원했다는 뜻이지, 백업 이후의 정상 변경까지 복구했다는 뜻은 아니다.

--databases를 붙이지 않은 이유는 선택한 데이터베이스 덤프를 별도 기본 스키마에 적재하기 위해서다. 다만 뷰·루틴·트리거 본문에 원래 스키마를 명시한 참조가 있으면 자동 치환되지 않는다. 이 실습은 그런 객체가 없는 단일 테이블에 한정한다.

--routines, --events, --triggers는 누락하기 쉬운 객체를 명시적으로 다루기 위한 옵션이다. 해당 객체가 있는 운영 환경에서는 정의와 실행 권한, DEFINER, 스케줄러 활성화 여부를 별도로 점검해야 한다. 복원한 이벤트가 외부 시스템에 중복 작업을 실행하지 않도록 격리한다. --no-tablespaces는 테이블스페이스 생성 정보의 덤프를 생략하는 것이지 테이블 행을 제외하는 옵션이 아니다.

이 예제의 --set-gtid-purged=OFF는 부분 스키마의 단순 복원에서 GTID 이력을 주입하지 않으려는 선택이다. binlog 좌표를 확보하지 않았으므로 PITR 기준 백업이나 복제본 초기화 절차로 그대로 사용하지 않는다. 사용자 계정·권한, 서버 설정, 플러그인, 키 관리 자료도 이 덤프 하나에 모두 포함되지 않는다.

행 수와 금액 합계가 맞는 것은 유용한 시작점이지만 완전한 데이터 동일성을 증명하지 않는다. 운영 복원 시험에서는 기본 키 구간별 검증, 중요 행 비교, 참조 무결성, 업무 집계, 객체 정의와 권한, 애플리케이션 읽기·쓰기 시험을 함께 수행한다. 검증이 끝난 실습 스키마와 덤프 파일은 보관 정책에 따라 정리한다.

5. 도구의 속도가 아니라 복구 경로를 조합한다

모든 방식에서 다음과 같은 백업 목록과 복구 경계 메타데이터를 함께 보관한다.

1. 백업 식별자, 서버·도구 버전, 원본 식별 정보, 대상 스키마·객체 범위.
2. 작업 시작·종료 시각과 일관성 기준점. 두 시각을 기준점으로 대체하지 않는다.
3. binlog 파일·위치 또는 해당 방식이 제공하는 GTID·복구 경계 정보.
4. 파일 목록, 크기, 체크섬, 압축·암호화 방식, 필요한 키의 식별자와 접근 절차.
5. 물리 증분 백업의 부모 관계, 준비 완료 여부, 의존하는 전체 백업의 위치.
6. 최근 복원 시험의 데이터 검증 결과, 소요 시간, 사용한 환경과 남은 제한.

파일 체크섬은 전송·보관 중 바이트 손상을 탐지하는 데 도움을 준다. 백업이 일관되게 생성됐는지, 필요한 객체를 모두 포함하는지, 키로 복호화할 수 있는지까지 증명하지는 않는다. '파일 생성', '외부 보관', '무결성 확인', '복원 성공', '업무 검증 통과'를 분리된 상태로 관리한다.

로그를 오래 보관한다고 항상 좋은 전략은 아니다. 오래된 기준 백업 이후의 로그를 모두 재생하면 RTO가 늘어날 수 있다. 전체·증분 백업 주기와 로그 보관 주기는 데이터 증가량, 변경량, 저장 비용, 실제 재생 처리량을 함께 보고 정한다. 증분 체인의 중간 파일이나 키 하나를 잃으면 후속 파일만 있어도 복구가 불가능할 수 있다.

6. Aurora MySQL에서는 관리형 복구 경계를 사용한다

Aurora의 자동 백업은 클러스터 볼륨을 대상으로 연속·증분 방식으로 수행된다. AWS 문서 기준 자동 백업 보존 기간은 1~35일이며, 수동 DB 클러스터 스냅샷은 자동으로 만료되지 않아 별도의 수명 관리가 필요하다. 오래 보관해야 하는 사본과 일상적인 PITR을 같은 보존 규칙으로 취급하지 않는다.

Aurora의 관리형 PITR을 사용하기 위해 Community MySQL처럼 사용자가 binlog 아카이브 체계를 직접 만드는 것은 아니다. binlog 기반 외부 복제나 별도 변경 데이터 수집의 요구와 Aurora 자동 백업을 구분한다. 자동 백업이 있다고 외부 소비자의 binlog 보존 요구까지 자동 충족되는 것도 아니다.

AWS가 설명하는 최신 복원 가능 시각은 일반적으로 현재 시각에 가까우나, 현재 커밋 시각과 동일하다고 보장할 수 없다. 콘솔·API가 제공하는 실제 earliest/latest restorable time을 기준으로 복원 가능 범위를 확인한다. '연속 백업'이라는 표현을 손실 구간이 항상 0이라는 뜻으로 사용하지 않는다.

스냅샷 또는 특정 시점 복원은 새 DB 클러스터를 대상으로 하는 절차다. 복원된 데이터만 보지 말고 DB 인스턴스 구성, 네트워크, 보안 그룹, 파라미터 그룹, 인증·암호화 키 권한, 접속 엔드포인트, 애플리케이션 전환을 확인한다. 새 환경이 원래의 운영 설정을 모두 그대로 물려받는다고 가정하지 않는다.

Aurora reader는 고가용성과 읽기 확장 수단이지, 논리적 사고를 차단하는 독립 백업이 아니다. 삭제가 공유 데이터 상태에 반영되면 reader도 그 영향을 받는다. Backtrack도 지원 조건과 되돌릴 수 있는 범위를 확인해야 하며, 장기·독립 보관을 대체하는 일반 백업으로 취급하지 않는다. 이 글에서는 실제 Aurora 복원 시간을 측정하지 않았다.

7. 흔한 실패를 운영 점검 항목으로 바꾼다

운영 체크리스트

• 장애 유형별 RPO·RTO와 복구 범위를 업무 담당자와 합의했는가?
• 테이블 엔진, DDL 작업, 오래 유지되는 스냅샷의 운영 영향을 확인했는가?
• 계정·권한·루틴·이벤트·트리거·설정·암호화 키까지 복구 범위를 정의했는가?
• 기준 백업의 일관성 경계와 binlog 시작점이 하나의 절차로 확보되는가?
• binlog 또는 증분 체인의 빠진 구간을 탐지하고 외부 보관 완료를 확인하는가?
• 원본의 장애·오삭제·계정 탈취가 백업과 키까지 함께 파괴하지 못하는가?
• 원본과 격리된 환경에서 최근 백업을 복원하고 데이터·업무 규칙을 검사했는가?
• 복원 후 이벤트·배치·복제·외부 전송이 뜻하지 않게 시작되지 않는가?
• 복호화·전송·검증·접속 전환·캐시 준비까지 포함해 RTO를 측정했는가?
• Aurora라면 실제 복원 가능 시각과 새 클러스터 전환 절차를 확인했는가?

8. 정리

논리 백업은 객체와 행의 재구성에, 물리 백업은 큰 데이터의 복원에, 스냅샷은 스토리지 시점 확보에 강점이 있다. binlog는 이 기준점 이후의 변경을 연결한다. 어느 하나의 성공 신호만으로 전체 복구 가능성을 판단해서는 안 된다.

실무의 기준은 일관된 기준 백업, 끊기지 않은 변경 이력, 독립된 보관과 키, 검증된 복원 절차다. 다음 단계에서는 논리 백업의 옵션과 권한, 물리 백업의 준비·복원, binlog 이벤트 경계를 이용한 PITR을 각각 실제 복원 절차로 확장할 수 있다.

참고 자료

• MySQL 8.4 Reference Manual — 백업과 복구 유형
• MySQL 8.4 Reference Manual — mysqldump 옵션과 일관성 주의사항
• MySQL 8.4 Reference Manual — 특정 시점 복구
• Amazon Aurora User Guide — 백업을 통한 보호와 복원