---
title: "백업 압축과 암호화: CPU, 공간, 키 관리의 균형"
description: "MySQL 백업의 압축·암호화 순서, CPU와 복구 시간의 균형, 키 보존 정책을 실제 덤프 왕복 검증과 함께 정리한다."
tags: [ MySQL, 백업복구, 보안, 운영 ]
image: "mysql-report-bg.png"
published: "2026-09-28"
updated: "2026-09-28"
author: "MySQL 기술 노트"
source_url: ""
---

백업 압축은 저장 비용만 줄이는 작업이 아니며, 암호화는 암호 옵션 하나로 끝나는 작업이 아니다. 압축 때문에 원본 조회가 느려지면 백업 창이 길어지고, 암호화 키에 접근하지 못하면 정상적인 백업 파일도 복구할 수 없다. 따라서 백업 정책은 **읽기·압축·암호화·보관·키 접근·복원**을 하나의 경로로 설계해야 한다.

이 글은 MySQL 8.0/8.4의 논리 백업을 중심으로 원리를 설명하고, 물리 백업과 Aurora의 경계를 구분한다. 실습은 폐기용 MySQL 8.0 인스턴스에서 생성한 덤프에 Zstandard 압축과 GnuPG 공개키 암호화를 적용한 뒤 다른 스키마로 복원한다. 운영 데이터나 실제 고객 키는 사용하지 않는다.

## 1. 무엇을 압축하고 무엇을 암호화하는가

같은 ‘압축’ 또는 ‘암호화’라는 단어라도 적용 계층이 다르면 보호 범위가 다르다.

| 계층 | 목적 | 백업 파일에 대한 보장 |
| --- | --- | --- |
| MySQL 연결 압축 | 서버와 클라이언트 사이 전송량 감소 | 덤프 출력 파일의 압축을 뜻하지 않음 |
| TLS | 네트워크 전송 중 기밀성과 무결성 보호 | 저장한 SQL 파일은 별도로 보호해야 함 |
| InnoDB 저장 데이터 암호화 | 테이블스페이스 등 지원 대상의 저장 데이터 보호 | 논리 조회 결과와 덤프가 자동으로 암호화되지는 않음 |
| 백업 파일 압축 | 보관·전송 바이트 감소 | 기밀성이나 공격자에 대한 진본성 보장 없음 |
| 백업 파일 암호화 | 백업 사본을 얻은 주체의 무단 해독 방지 | 키·권한·무결성 검증·보존 정책이 함께 필요 |
| 저장소 서버 측 암호화 | 저장소 계층의 저장 데이터 보호 | 읽기 권한이 탈취되었을 때의 위험까지 제거하지는 않음 |

특히 `mysqldump`의 연결 압축 옵션을 켜고 `.sql`로 저장했다고 해서 압축 백업이 만들어진 것은 아니다. MySQL 클라이언트가 받은 행을 SQL 문장으로 직렬화하는 단계와, 그 출력을 압축기로 전달하는 단계는 별개다.

### 압축 후 암호화가 기본 순서인 이유

압축기는 반복되는 값과 패턴을 이용한다. 암호화된 바이트는 이러한 규칙성이 드러나지 않도록 만들어지므로 일반적으로 다시 압축해도 거의 줄지 않는다. 따라서 논리 백업은 **SQL 생성 → 압축 → 암호화** 순서가 자연스럽다. 복원은 그 반대다.

```mermaid
flowchart LR
    A["일관된 원본 읽기"] --> B["SQL 덤프 생성"]
    B --> C["압축"]
    C --> D["공개키로 암호화"]
    D --> E["암호문 보관 및 목록 확정"]
    E --> F["복구 권한 및 개인키 확보"]
    F --> G["복호화와 무결성 확인"]
    G --> H["압축 검사 및 해제"]
    H --> I["격리된 DB로 복원"]
    I --> J["행과 업무 조건 검증"]
```

이미 압축된 이미지·영상·압축 BLOB이나 암호화된 페이지가 많은 물리 백업은 SQL 텍스트와 다른 압축률을 보인다. 원본 테이블 크기나 데이터 타입 이름만으로 절감률을 예측하지 말고 실제 백업 바이트를 측정해야 한다. 백업 도구가 자체 압축·암호화를 제공한다면 도구가 정한 생성 및 복원 순서, 버전 호환성을 우선한다.

## 2. 압축률보다 먼저 병목과 복구 목표를 정한다

파이프라인의 처리량은 가장 느린 단계에 제한된다. 압축 단계가 느리면 앞단의 덤프 프로세스도 파이프가 비워지기를 기다린다. 네트워크나 저장소가 병목인 환경에서는 압축이 전체 시간을 줄일 수 있지만, CPU가 부족한 환경에서는 반대가 된다.

높은 압축 수준은 일반적으로 더 많은 탐색과 CPU 시간을 소비한다. 그만큼 파일이 작아진다고 해도 백업 창, 복구 시간, 운영 쿼리의 지연을 함께 만족하지 못하면 좋은 설정이 아니다. 해제 속도는 압축 속도와 같지 않으며, 복구 호스트의 CPU·메모리·스토리지 성능도 원본 서버와 다를 수 있다.

운영 평가에서는 같은 대표 덤프를 대상으로 다음 항목을 함께 기록한다.

- 원본 덤프 바이트와 압축 후 바이트, 암호화 후 최종 바이트.
- 전체 경과 시간과 프로세스 CPU 시간. 경과 시간만으로 CPU 비용을 판단하지 않는다.
- 백업 중 업무 쿼리 지연, 디스크 대기, 네트워크 처리량, CPU 여유.
- 키 접근 승인부터 실제 서비스 검증까지의 복구 시간.
- 동시 작업 수와 메모리 상한. 압축 스레드를 늘렸을 때의 총 자원 소비.

Zstandard의 낮은 수준부터 시작해 중간 수준과 비교하고, 절감 효과가 작은데 CPU만 크게 늘면 수준을 낮추는 편이 합리적이다. `-T0`처럼 사용 가능한 CPU를 자동으로 사용하는 설정을 운영 서버에 무조건 적용하지 않는다. 백업 전용 호스트로 압축을 옮겨도 원본 읽기 부하와 전송량이 사라지는 것은 아니다.

`mysqldump --single-transaction`은 InnoDB의 일관된 읽기를 이용하지만 무료인 작업은 아니다. 느린 출력 소비로 스냅샷 수명이 길어지면 undo 정리와 공간 관리에 부담을 줄 수 있다. 또한 비트랜잭션 테이블과 백업 도중 DDL까지 일괄적으로 보호하는 옵션도 아니다. 백업 창에는 변경 정책과 객체 유형을 별도로 관리한다.

## 3. 키 관리는 백업 보존 기간 전체의 문제다

공개키 방식에서는 백업 생성 호스트가 수신자의 공개키만으로 암호화할 수 있다. 복구용 개인키는 별도 보안 경계에 둘 수 있으므로, 백업 생성 권한과 해독 권한을 분리하기 좋다. 다만 공개키 자체도 신뢰할 수 있는 경로로 배포해야 한다. 공격자가 백업 대상 공개키를 바꿀 수 있다면 정상적으로 생성된 새 백업조차 복구팀이 해독하지 못할 수 있다.

KMS 기반 설계에서는 큰 백업 전체를 KMS API로 직접 암호화하기보다 데이터 키로 본문을 암호화하고, 그 데이터 키를 KMS 키로 보호하는 envelope encryption이 일반적인 패턴이다. 이때 암호화된 데이터 키, 알고리즘·형식 정보, 필요한 encryption context, KMS 키 식별자가 복구 가능한 형태로 남아 있어야 한다. KMS를 사용한다는 말만으로 파일 형식이나 복구 절차가 완성되지는 않는다.

### 회전과 폐기를 구분한다

새 공개키로 다음 백업을 암호화해도 예전 파일이 새 키로 바뀌지는 않는다. 과거 백업이 필요하면 예전 개인키도 복구 가능해야 한다. AWS KMS의 지원되는 키 재료 회전은 같은 논리 키 안에서 과거 암호문에 맞는 키 재료를 선택하는 방식이며, 새 KMS 키로 교체하거나 기존 키를 삭제하는 작업과 다르다. 회전은 기존 데이터의 일괄 재암호화를 의미하지 않는다.

보존 정책은 다음 세 수명을 묶어 관리해야 한다.

1. **백업 수명:** 전체 백업, 증분 체인, 필요한 binlog가 언제까지 남는가.
2. **해독 수명:** 그 기간 동안 필요한 키·복호화 도구·형식을 유지하는가.
3. **권한 수명:** 장애 시 사용할 역할, 교차 계정 정책, 승인 담당자가 실제로 유효한가.

키를 백업 파일과 같은 디렉터리에 평문으로 두거나, 셸 인수에 실제 비밀을 쓰거나, 작업 로그에 개인키를 출력해서는 안 된다. 반대로 키를 지나치게 격리하여 비상 복구 권한을 아무도 행사하지 못하는 설계도 실패다. 정상 계정의 성공 시험뿐 아니라 비상 복구 역할의 키 접근 시험을 해야 한다.

## 4. 작은 논리 백업으로 압축·암호화 왕복 확인하기

다음은 운영 스키마가 아닌 **비어 있는 폐기용 인스턴스**에서 실행하는 준비 SQL이다. 반복 문자열이 많은 데이터를 의도적으로 넣었으므로 뒤의 압축률을 운영 데이터의 예상 절감률로 사용하면 안 된다. `backup_codec_lab`과 `restore_codec_lab`이 없는 환경에서 실행한다.

```sql
CREATE DATABASE backup_codec_lab;
CREATE DATABASE restore_codec_lab;
CREATE TABLE backup_codec_lab.sample_rows (
    id INT PRIMARY KEY,
    group_no INT NOT NULL,
    payload VARCHAR(600) NOT NULL
) ENGINE=InnoDB;
INSERT INTO backup_codec_lab.sample_rows (id, group_no, payload)
WITH RECURSIVE seq(n) AS (
    SELECT 1
    UNION ALL
    SELECT n + 1 FROM seq WHERE n < 1000
)
SELECT n, MOD(n, 7),
       REPEAT(CONCAT('account=', LPAD(n, 4, '0'), ';type=backup;'), 20)
FROM seq;
SELECT COUNT(*) AS row_count,
       SUM(OCTET_LENGTH(payload)) AS payload_bytes
FROM backup_codec_lab.sample_rows;
```

실행 결과(MySQL 8.0.x):

```text
mysql> CREATE DATABASE backup_codec_lab;

Query OK, 1 row affected (0.00 sec)

mysql> CREATE DATABASE restore_codec_lab;

Query OK, 1 row affected (0.00 sec)

mysql> CREATE TABLE backup_codec_lab.sample_rows (
    ->     id INT PRIMARY KEY,
    ->     group_no INT NOT NULL,
    ->     payload VARCHAR(600) NOT NULL
    -> ) ENGINE=InnoDB;

Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO backup_codec_lab.sample_rows (id, group_no, payload)
    -> WITH RECURSIVE seq(n) AS (
    ->     SELECT 1
    ->     UNION ALL
    ->     SELECT n + 1 FROM seq WHERE n < 1000
    -> )
    -> SELECT n, MOD(n, 7),
    ->        REPEAT(CONCAT('account=', LPAD(n, 4, '0'), ';type=backup;'), 20)
    -> FROM seq;

Query OK, 1000 rows affected (0.04 sec)
Records: 1000  Duplicates: 0  Warnings: 0

mysql> SELECT COUNT(*) AS row_count,
    ->        SUM(OCTET_LENGTH(payload)) AS payload_bytes
    -> FROM backup_codec_lab.sample_rows;

+-----------+---------------+
| row_count | payload_bytes |
+-----------+---------------+
|      1000 |        500000 |
+-----------+---------------+
1 row in set (0.00 sec)
```

### 실행 환경과 파일 생성

실제 검증에서는 MySQL 8.0.46, Zstandard 1.5.5, GnuPG 2.3.7을 사용했다. MySQL 접속은 폐기용 컨테이너의 로컬 소켓으로 수행했다. 아래 셸 명령은 같은 처리 옵션을 사용하되, 독자 환경의 인증 정보는 미리 설정한 `backup_lab`·`restore_lab` login path로 표현한 것이다. 따라서 해당 login path와 접속 대상은 실습 환경에 맞게 준비해야 한다. 원격 접속에는 인증서 검증을 포함한 TLS 정책도 적용한다.

GnuPG 예제의 `$RECIPIENT`는 신뢰된 경로로 확인한 **전체 공개키 지문**이다. 백업 호스트의 전용 키 저장소에는 해당 공개키를 준비하고, 복구 측에는 대응하는 개인키를 안전하게 제공한다. 실험에서 생성한 무암호 폐기용 개인키는 검증 편의를 위한 것이며 운영 키 관리 방식이 아니다.

아래는 Bash에서 새 작업 디렉터리를 사용한다는 전제다. 평문을 디스크에 남기는 방식이므로 권한이 제한된 암호화 작업 영역을 사용한다. `umask`는 접근 권한을 좁힐 뿐 저장 데이터 암호화가 아니다.

```bash
set -euo pipefail
umask 077

mysqldump --login-path=backup_lab \
  --single-transaction --quick --routines --events --triggers \
  --no-tablespaces --set-gtid-purged=OFF \
  backup_codec_lab > backup.sql.partial
mv backup.sql.partial backup.sql

zstd -q -3 -T1 backup.sql -o backup.sql.zst.partial
mv backup.sql.zst.partial backup.sql.zst

gpg --batch --yes --trust-model always \
  --recipient "$RECIPIENT" --compress-algo none \
  --output backup.sql.zst.gpg.partial --encrypt backup.sql.zst
mv backup.sql.zst.gpg.partial backup.sql.zst.gpg

sha256sum backup.sql.zst.gpg > backup.sql.zst.gpg.sha256
```

`--trust-model always`는 여기서 이미 대역 외로 검증한 지문을 사용할 때의 실습 설정이다. 키의 신원을 자동으로 검증해 주는 옵션이 아니므로, 운영에서는 조직의 공개키 신뢰·승인 정책 없이 그대로 적용하지 않는다. `--compress-algo none`은 이미 Zstandard로 압축한 데이터를 GnuPG가 다시 압축하지 않도록 한다.

`.partial`을 성공 후 같은 파일시스템 안에서 이름 변경하면 불완전 파일이 최종 이름으로 노출되는 위험을 줄일 수 있다. 그러나 파일 이름 변경이 원격 업로드 완료나 내구성까지 보장하지는 않는다. 저장소 업로드, 크기·해시 확인, 보존 정책 적용이 완료된 후에 백업 목록을 완료 상태로 확정해야 한다. 해시 목록 역시 신뢰된 별도 경로나 서명으로 보호해야 한다. 암호문과 해시를 함께 바꿀 수 있는 공격자에게 단순 SHA-256 파일은 진본성 증명이 아니다.

이 덤프는 단일 테스트 스키마의 왕복 검증을 위해 `--set-gtid-purged=OFF`를 사용했다. GTID·binlog 경계를 포함한 복제 초기화나 PITR 기준 백업을 완성했다는 뜻은 아니다.

### 복호화 검증을 끝낸 후에 복원한다

큰 암호문을 복호화하면서 즉시 `mysql`에 파이프로 넣는 방식은 주의해야 한다. 복호화 도구가 마지막 무결성 검사에서 실패하더라도 앞부분의 SQL이 이미 적용되었을 수 있다. `pipefail`은 실패를 감지하지만, 먼저 실행된 DDL/DML을 되돌리지 않는다.

이 예제는 작업 공간을 더 쓰더라도 복호화 종료 코드와 압축 무결성 검사를 먼저 확인한다. 실패한 `.partial` 파일은 절대 복원 입력으로 사용하지 않는다.

```bash
sha256sum -c backup.sql.zst.gpg.sha256

gpg --batch --yes --output recovered.sql.zst.partial \
  --decrypt backup.sql.zst.gpg
mv recovered.sql.zst.partial recovered.sql.zst
zstd -t recovered.sql.zst
zstd -q -d recovered.sql.zst -o recovered.sql.partial
mv recovered.sql.partial recovered.sql
cmp backup.sql recovered.sql

mysql --login-path=restore_lab restore_codec_lab < recovered.sql
```

GnuPG의 암호문 무결성 검사가 성공했다는 사실과 파일 생성자의 서명이 검증되었다는 사실은 다르다. 공개키를 아는 사람은 누구나 해당 수신자를 위한 새 암호문을 만들 수 있다. 출처까지 확인해야 한다면 서명된 백업 목록 또는 별도의 서명 검증 체계를 설계한다.

### 실제 왕복 검증 결과

검증 결과는 압축 파일 생성, 암호화, 복호화, 덤프 바이트 비교와 복원된 전체 행 비교를 포함한다. 단순히 `COUNT(*)`만 같다고 성공 처리하지 않고, 기본키 순서로 모든 열을 읽어 원본과 복원본을 바이트 단위로 비교했다. 또한 대응하는 개인키가 없는 별도 키 저장소와 변조한 암호문으로 복호화가 실패하는지 확인했다.

| 산출물 | 실제 크기(바이트) | 원본 덤프 대비 남은 비율 |
| --- | ---: | ---: |
| 원본 SQL 덤프 | 512,958 | 기준 |
| `zstd -1 -T1` | 10,764 | 2.10% |
| `zstd -3 -T1` | 6,477 | 1.26% |
| `zstd -9 -T1` | 5,913 | 1.15% |
| `zstd -3` 후 GnuPG 암호화 | 6,655 | 1.30% |

| 검증 항목 | 실제 결과 |
| --- | --- |
| 정상 개인키를 사용한 복호화 | 종료 코드 0 |
| 압축 파일 검사 및 해제 | 성공 |
| 원본 덤프와 해제한 덤프의 전체 바이트 | 일치 |
| 원본과 복원본의 기본키 순서 전체 행 | 1,000행 모두 일치 |
| 개인키가 없는 키 저장소에서 복호화 | 종료 코드 2로 실패 |
| 암호문의 마지막 바이트를 바꾼 뒤 복호화 | 종료 코드 2, `Checksum error` 확인 |

전체 행 비교를 독자 환경에서 반복하려면 다음처럼 같은 순서와 출력 형식으로 추출한다. 이 실습의 문자열에는 탭이나 줄바꿈이 없으므로 두 결과 파일을 직접 비교할 수 있다. 일반 업무 데이터에서는 구분자·NULL·바이너리 표현을 포함해 손실 없는 비교 형식을 먼저 정해야 한다.

```bash
mysql --login-path=backup_lab --batch --raw --skip-column-names \
  -e 'SELECT id, group_no, payload FROM backup_codec_lab.sample_rows ORDER BY id' \
  > source.rows
mysql --login-path=restore_lab --batch --raw --skip-column-names \
  -e 'SELECT id, group_no, payload FROM restore_codec_lab.sample_rows ORDER BY id' \
  > restored.rows
cmp source.rows restored.rows
```

실험 중 원본 데이터는 변경하지 않았다. 실제 운영에서는 백업 이후 원본이 달라질 수 있으므로 현재 원본과의 비교만으로 일관된 백업 여부를 판단하지 않고, 백업 경계에 맞는 검증 기준을 사용한다. 검증이 끝난 평문 파일과 폐기용 키는 정리하되, 운영 백업용 키까지 실습 정리 대상으로 혼동하지 않는다.

압축률 시험은 작은 반복 데이터와 덤프 헤더를 포함한 단일 파일에 대한 결과다. CPU 비용이나 최대 처리량을 평가할 규모의 벤치마크가 아니며, 같은 서버의 다른 스키마로 복원했으므로 서버 유실 복구·교차 버전 이관·PITR·KMS 장애 시험으로 확대 해석하지 않는다.

## 5. 물리 백업과 Aurora에서는 경계가 달라진다

물리 백업 도구의 압축·암호화는 SQL 덤프의 외부 필터와 동일한 절차가 아니다. 예를 들어 XtraBackup 계열에서는 사용 버전에 맞는 해독·압축 해제·prepare 순서를 확인해야 하고, 암호화된 InnoDB 테이블스페이스를 복구하려면 백업 파일 암호화 키와 별개로 해당 데이터 암호화에 필요한 keyring 구성이 요구될 수 있다. 백업 컨테이너의 포장을 푸는 키와 데이터베이스 내부의 키를 혼동하지 않는다.

복구 공간도 최종 암호문 크기로만 계산하면 안 된다. 암호문, 압축 해제 중간 파일, prepare 대상, 복구 datadir, 필요한 로그가 동시에 존재하는 구간을 기준으로 용량을 확보한다. 스트리밍이나 청크 처리로 공간을 줄일 수 있지만, 청크 누락 검증·인증 완료 경계·부분 실패 처리까지 함께 설계해야 한다.

Aurora의 자동 백업·스냅샷은 관리형 스토리지 계층의 기능이다. 사용자가 해당 백업에 `zstd -9`나 GnuPG 옵션을 직접 적용하는 구조가 아니다. Aurora의 저장 데이터 암호화는 로그·자동 백업·스냅샷을 포함하며, 고객 관리형 KMS 키를 사용한다면 키 정책과 복구 역할의 접근 권한도 복구 가능성의 일부다.

반면 Aurora에서 `mysqldump`로 추출한 SQL 파일은 별도의 외부 산출물이다. 원본 클러스터의 암호화가 이 파일에 자동으로 이어지지 않는다. 파일·작업 디렉터리·외부 저장소의 보호 정책을 새로 적용해야 한다. 다른 리전이나 계정으로 사본을 옮길 때도 백업 공유 가능 여부, 대상 리전의 키와 정책, 실제 복원 권한을 현재 AWS 문서와 복원 시험으로 확인한다. 이 글에서는 Aurora나 AWS KMS의 실제 복구를 실행하지 않았다.

## 6. 실패 양상별 판단 기준

| 관측 현상 | 먼저 확인할 원인 | 판단과 조치 |
| --- | --- | --- |
| 백업 파일은 작아졌지만 완료가 늦어짐 | 압축 프로세스 CPU 포화, 파이프 역압, 긴 원본 읽기 | 낮은 압축 수준과 제한된 스레드 수로 다시 측정 |
| 압축 전후 크기 차이가 거의 없음 | 이미 압축·암호화된 입력, 데이터 특성 | 중복 압축을 제거하고 전송·저장 비용과 CPU 비교 |
| 파일이 존재하지만 복원 실패 | 앞단 덤프 실패, 잘린 파일, 잘못된 키·형식 | 모든 단계의 종료 코드와 최종 목록 확정 조건 확인 |
| 해시 검증은 성공하지만 해독 불가 | 키 삭제·비활성화, 권한 변경, 잘못된 개인키 | 백업 보존 기간 전체의 키와 역할 이력 확인 |
| 복호화 실패 후 일부 테이블이 생김 | 검증 완료 전 DB에 스트리밍 입력 | 격리 대상 재생성, 인증·압축 검증 후 적재 |
| 복구 호스트에서만 메모리·공간 부족 | 압축 해제 메모리, 중간 파일, prepare 공간 | 실제 복구 호스트 기준으로 상한과 여유 공간 산정 |

백업 작업이 실패했을 때 기존 정상 백업을 먼저 지우거나 새 파일 이름만 보고 성공 처리해서는 안 된다. 정상본의 보존과 새 작업의 완료 여부를 별도로 관리해야 한다. 압축과 암호화는 손상·오삭제·랜섬웨어에 대한 불변 보관 정책을 대체하지도 않는다.

## 7. 운영 적용 전 점검표

- [ ] 연결 압축, TLS, DB 저장 데이터 암호화, 백업 파일 암호화의 범위를 구분했는가.
- [ ] 실제 백업 바이트로 압축 수준별 크기·CPU·경과 시간·업무 지연을 비교했는가.
- [ ] 운영 서버와 복구 서버 각각의 CPU·메모리·작업 공간 상한을 정했는가.
- [ ] 일관된 읽기의 범위, 비트랜잭션 테이블, 백업 중 DDL 정책을 확인했는가.
- [ ] 공개키 지문 또는 KMS 키 식별자와 필요한 암호화 메타데이터를 보존하는가.
- [ ] 키 회전 후에도 보존 중인 가장 오래된 백업을 실제로 해독할 수 있는가.
- [ ] 평문 임시 파일과 복호화된 파일의 접근 권한·저장 암호화·수명 정책이 있는가.
- [ ] 앞단 실패와 암호문 변조를 감지하고, 실패한 출력은 복원에 사용하지 않는가.
- [ ] 해시·서명·백업 목록의 신뢰 경계를 보호하고 모든 청크의 완전성을 확인하는가.
- [ ] 비상 복구 역할로 키 접근부터 DB 검증까지 시험하고 RTO 안에 완료했는가.

## 마무리

좋은 압축 설정은 가장 작은 파일을 만드는 값이 아니라 업무 부하와 복구 목표를 함께 만족하는 값이다. 좋은 암호화 정책은 강한 알고리즘만 고르는 것이 아니라, 백업을 보존하는 동안 필요한 키와 권한을 유지하고 실패를 적재 이전에 감지하는 정책이다.

다음 복구 설계에서는 이렇게 보호한 백업을 실제 복구 사슬의 시작점으로 삼아, binlog 보존과 시점 복구 경계까지 연결해야 한다. 파일의 보호와 복구 시점의 정확성은 서로 보완하는 별도의 검증 대상이다.

## 참고 문서

- [MySQL 8.4: mysqldump](https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html)
- [Zstandard: 압축 수준과 속도 특성](https://facebook.github.io/zstd/)
- [GnuPG: OpenPGP 옵션과 무결성 보호](https://www.gnupg.org/documentation/manuals/gnupg/OpenPGP-Options.html)
- [Amazon Aurora: 암호화 범위와 제약](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.Encryption.html)
- [AWS KMS: 키 회전과 과거 암호문의 해독](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)