TIL - 20260820

juni·2026년 8월 20일

목록 보기

435/468

0820 데이터베이스 실무 심화 (8/N): DB Backup, Restore와 운영 장애 대응

✅ 1. DB 백업이란 무엇인가?

DB 백업은 데이터베이스의 데이터를 특정 시점 기준으로 복사해두는 것입니다.
운영 중 실수, 장애, 삭제, migration 실패, 서버 문제, 보안 사고가 발생했을 때 복구하기 위한 마지막 안전장치입니다.
백업은 “있으면 좋은 것”이 아니라 운영 서비스에서는 필수입니다.

운영 DB
  ↓
정기 백업
  ↓
장애/실수 발생
  ↓
백업 기준 복구

➕ 1-1. 백업이 필요한 상황

운영 DB 데이터 실수 삭제
잘못된 migration 실행
대량 update 조건 실수
Soft Delete 대신 Hard Delete 실행
RDS 장애 또는 스토리지 문제
보안 사고로 데이터 오염 의심
운영 서버 이전
개발/스테이징 환경 재현

장애가 발생한 뒤에 백업을 고민하면 늦습니다.
평소에 백업과 복구 절차를 만들어둬야 합니다.

✅ 2. 백업보다 중요한 것은 복구 가능성

백업 파일이 있다고 해서 안전한 것이 아닙니다.
실제로 복구할 수 있어야 백업입니다.
백업은 존재 여부보다 복구 테스트가 더 중요합니다.

백업 있음:
파일이나 snapshot이 존재함

복구 가능:
그 백업으로 실제 DB를 되살릴 수 있음

➕ 2-1. 나쁜 백업 상태

백업이 어디 있는지 모름
백업 주기가 불명확함
복구 명령어를 모름
백업 파일에 권한이 없음
암호화 키를 잃어버림
백업이 너무 오래됨
복구 테스트를 한 적 없음

➕ 2-2. 좋은 백업 상태

백업 위치가 명확함
백업 주기가 정해져 있음
복구 절차가 문서화되어 있음
복구 권한이 관리됨
복구 테스트 기록이 있음
RPO/RTO 기준이 있음

“백업은 있다”와 “복구할 수 있다”는 완전히 다릅니다.
운영자는 후자를 기준으로 봐야 합니다.

✅ 3. RPO와 RTO

백업과 복구를 이야기할 때는 RPO와 RTO를 알아야 합니다.

개념	의미	질문
RPO	복구 시 허용 가능한 데이터 손실 시간	몇 분/몇 시간 전 데이터까지 잃어도 되는가?
RTO	복구 완료까지 허용 가능한 시간	장애 후 몇 분/몇 시간 안에 복구해야 하는가?

➕ 3-1. RPO 예시

RPO 24시간:
어제 백업 시점 이후 데이터는 잃을 수 있음

RPO 1시간:
최대 1시간치 데이터 손실만 허용

RPO 5분:
거의 실시간 백업 필요

➕ 3-2. RTO 예시

RTO 4시간:
장애 후 4시간 안에 복구

RTO 30분:
30분 안에 복구 필요

RTO 5분:
고가용성 구조 필요

➕ 3-3. 현재 프로젝트 기준

상담 신청 데이터:
손실되면 매출/응대에 영향

상품/배너 데이터:
복구 가능성이 중요

관리자 로그/상태 이력:
운영 추적성에 중요

초기 기준:
일 단위 백업 + 장애 시 수동 복구 절차부터 시작

작은 서비스라도 RPO/RTO를 대략 정해두면 백업 전략을 현실적으로 잡을 수 있습니다.
처음부터 완벽한 무중단 복구보다, “최악의 상황에서 어디까지 되돌릴 수 있는가”를 아는 것이 중요합니다.

✅ 4. PostgreSQL 백업 방식

PostgreSQL 백업은 크게 논리 백업과 물리 백업으로 나눌 수 있습니다.

방식	설명	예시
논리 백업	SQL 또는 dump 형태로 데이터 추출	`pg_dump`
물리 백업	DB 파일/스토리지 수준 백업	RDS Snapshot
지속 백업	WAL 기반 시점 복구	PITR

➕ 4-1. 논리 백업

DB 내용을 SQL/dump 파일로 export

장점:
테이블 단위 복원 가능
다른 환경으로 옮기기 쉬움
로컬/스테이징 복구에 유용

단점:
대용량 DB에서 느릴 수 있음
복구 시간 오래 걸릴 수 있음

➕ 4-2. 물리 백업

스토리지 또는 DB 인스턴스 수준 백업

장점:
전체 DB 복구에 유리
RDS Snapshot으로 관리 쉬움

단점:
세밀한 테이블 단위 복구는 불편
환경 종속적일 수 있음

➕ 4-3. PITR

Point-In-Time Recovery

특정 시점으로 DB를 복원하는 방식
예: 2026-08-20 10:25 직전 상태로 복구

초기에는 RDS 자동 백업과 pg_dump 수동 백업을 함께 이해하면 충분합니다.
데이터가 커지고 장애 대응 요구가 높아지면 PITR까지 고려합니다.

✅ 5. pg_dump 기본

pg_dump는 PostgreSQL의 대표적인 논리 백업 도구입니다.
DB 내용을 파일로 저장할 수 있습니다.

➕ 5-1. 기본 백업 명령어

pg_dump \
  --host=localhost \
  --port=5432 \
  --username=together \
  --dbname=together \
  --format=custom \
  --file=together_backup.dump

➕ 5-2. 환경변수 사용

PGPASSWORD="password" pg_dump \
  -h localhost \
  -p 5432 \
  -U together \
  -d together \
  -Fc \
  -f together_backup.dump

➕ 5-3. 옵션 의미

-h:
host

-p:
port

-U:
username

-d:
database

-Fc:
custom format

-f:
output file

-Fc custom format으로 백업하면 pg_restore를 사용해 복구하기 좋습니다.
운영 비밀번호를 명령어에 직접 쓰면 shell history에 남을 수 있으므로 주의해야 합니다.

✅ 6. pg_restore 기본

pg_restore는 pg_dump -Fc로 만든 백업 파일을 복구할 때 사용합니다.

➕ 6-1. 복구 명령어

pg_restore \
  --host=localhost \
  --port=5432 \
  --username=together \
  --dbname=together_restore \
  --clean \
  --if-exists \
  together_backup.dump

➕ 6-2. 새 DB에 복구하는 흐름

createdb together_restore

pg_restore \
  -h localhost \
  -p 5432 \
  -U together \
  -d together_restore \
  together_backup.dump

➕ 6-3. 주의

운영 DB에 바로 복구하지 않기
먼저 새 DB에 복구 테스트
복구 대상 DB 이름 확인
--clean 옵션은 기존 객체 삭제 가능
권한/extension 차이 확인

복구는 백업보다 위험할 수 있습니다.
운영 DB에 바로 restore하지 말고, 새 DB나 스테이징에서 먼저 확인해야 합니다.

✅ 7. RDS 자동 백업

AWS RDS를 사용한다면 자동 백업과 snapshot 기능을 활용할 수 있습니다.
자동 백업은 특정 보존 기간 동안 DB를 복구할 수 있게 해줍니다.

➕ 7-1. RDS 백업 구성 요소

Automated Backup:
자동 백업과 로그 기반 복구

Manual Snapshot:
사용자가 직접 만든 시점 백업

Backup Retention Period:
자동 백업 보존 기간

PITR:
특정 시점 복구

➕ 7-2. 운영 전 확인할 것

자동 백업이 켜져 있는가?
보존 기간은 며칠인가?
수동 snapshot 생성 방법을 아는가?
복구 시 새 RDS 인스턴스로 복원되는가?
복구 후 애플리케이션 DATABASE_URL 변경이 필요한가?

➕ 7-3. 주의

snapshot은 비용이 발생할 수 있음
복구는 기존 DB를 덮어쓰기보다 새 인스턴스로 생성되는 경우가 많음
복구 후 보안그룹/파라미터/권한 확인 필요
운영 연결 전 데이터 검증 필요

RDS 백업은 매우 중요하지만, 복구 절차를 모르면 장애 때 당황합니다.
“snapshot이 있다”가 아니라 “snapshot에서 새 DB를 만들고 앱을 붙일 수 있다”까지 알아야 합니다.

✅ 8. 백업 대상 정리

DB만 백업한다고 운영 전체가 복구되는 것은 아닙니다.
서비스 복구에는 DB, 파일, 환경변수, 배포 artifact, 코드가 함께 필요합니다.

PostgreSQL/RDS
S3 업로드 이미지
SSM Parameter/환경변수 목록
GitHub repository
배포 artifact
운영 문서/Runbook

➕ 8-1. DB와 함께 봐야 하는 이유

DB에는 fileUrl만 있고 실제 파일은 S3에 있음
DB 복구 후 환경변수가 없으면 앱 실행 불가
코드 버전과 DB schema가 맞아야 함
Runbook이 없으면 복구 절차를 모름

➕ 8-2. 현재 프로젝트 기준

상담/주문 DB:
PostgreSQL/RDS 백업

상품 이미지:
S3 versioning 또는 별도 백업

환경변수:
SSM 경로 목록 문서화

프론트 배포:
Git commit + build 가능 상태

백엔드 배포:
Git commit + migration 이력

복구는 DB 하나만 살린다고 끝나지 않습니다.
코드, schema, 파일, env가 맞아야 서비스가 정상으로 돌아옵니다.

✅ 9. 백업 파일 보안

백업 파일은 운영 DB의 복사본입니다.
개인정보, 상담 메모, 전화번호, 주문 정보가 들어 있을 수 있습니다.
따라서 백업 파일은 원본 DB만큼 조심해야 합니다.

➕ 9-1. 백업 파일 위험

개인정보 전체 포함 가능
운영 데이터 외부 유출 위험
로컬 Mac에 방치될 수 있음
S3 public 설정 실수 가능
공유 링크 유출 가능

➕ 9-2. 보안 기준

백업 파일 Git 커밋 금지
공용 폴더 저장 금지
권한 제한된 위치에 저장
필요 시 암호화
사용 후 삭제 또는 안전 보관
다운로드 이력 기록
운영 백업을 AI에게 제공 금지

➕ 9-3. 로컬 복구 시 주의

운영 DB dump를 개인 Mac에 오래 보관하지 않기
개인정보 포함 dump는 별도 폴더와 권한 관리
테스트 후 삭제
가능하면 익명화된 dump 사용

백업은 보안 사고의 또 다른 통로가 될 수 있습니다.
특히 운영 DB dump를 로컬에 내려받는 작업은 신중해야 합니다.

✅ 10. 운영 DB 덤프를 로컬에서 사용할 때

운영 데이터를 로컬 개발환경에 그대로 복원하는 것은 위험합니다.
개인정보와 실제 고객 데이터가 로컬에 남기 때문입니다.
가능한 경우 익명화된 데이터나 staging 데이터를 사용하는 것이 좋습니다.

➕ 10-1. 위험한 방식

운영 RDS dump 다운로드
  ↓
개인 Mac 로컬 DB에 복구
  ↓
전화번호/상담 메모 그대로 존재
  ↓
보안 사고 시 전체 유출 위험

➕ 10-2. 더 안전한 방식

운영 DB 백업
  ↓
별도 환경에서 개인정보 익명화
  ↓
익명화 dump 생성
  ↓
로컬 개발용으로 사용

➕ 10-3. 익명화 대상

customerName
phone
phoneNormalized
memo
ipAddress
userAgent
address
birthdate
token

로컬 개발에 꼭 운영 데이터가 필요한지 먼저 판단해야 합니다.
단순 화면/쿼리 테스트라면 seed 데이터나 익명화 데이터가 더 안전합니다.

✅ 11. 백업 주기 설계

백업 주기는 데이터 중요도와 변경 빈도에 따라 정해야 합니다.

➕ 11-1. 주기 후보

매일:
기본 운영 DB 백업

배포 전:
DB migration 전 snapshot

대량 작업 전:
대량 update/delete 전 수동 백업

장애 대응 전:
복구 작업 전 현재 상태 snapshot

월별:
장기 보관 snapshot

➕ 11-2. 현재 프로젝트 기준 추천

RDS 자동 백업:
매일 + 보존 기간 설정

수동 snapshot:
DB migration 전
대량 수정 전
중요 배포 전

pg_dump:
필요 시 스테이징/로컬 복구 테스트용

➕ 11-3. 주의

백업이 너무 드물면 데이터 손실 큼
백업이 너무 많으면 비용/관리 부담 증가
수동 snapshot은 만든 뒤 정리 기준 필요

migration 전 snapshot은 운영 안정성 측면에서 매우 중요합니다.
특히 컬럼 삭제, enum 변경, 대량 update 전에는 반드시 복구 기준을 확인해야 합니다.

✅ 12. DB Migration 전 백업

DB migration은 운영 데이터 구조를 바꾸는 작업입니다.
실패하면 앱 오류뿐 아니라 데이터 정합성 문제로 이어질 수 있습니다.
중요한 migration 전에는 백업 또는 snapshot을 확인해야 합니다.

➕ 12-1. 백업이 필요한 migration

컬럼 삭제
컬럼 rename
enum 값 변경
unique constraint 추가
not null 제약 추가
대량 데이터 backfill
테이블 구조 변경
관계/foreign key 변경

➕ 12-2. 배포 전 확인

현재 자동 백업 상태 확인
수동 snapshot 필요 여부 판단
staging에서 migration 테스트
rollback 또는 forward fix 계획
migration 예상 시간 확인
lock 발생 가능성 확인

➕ 12-3. 위험한 습관

운영에서 바로 migrate 실행
backup 확인 없이 schema 변경
대량 update를 한 번에 실행
Prisma migrate reset 사용
migration 실패 후 감으로 SQL 수정

운영 DB에서 migrate reset은 절대 쓰면 안 됩니다.
migration은 항상 “되돌릴 수 있는가?”를 먼저 봐야 합니다.

✅ 13. 복구 전략의 종류

장애 상황에 따라 복구 방식이 달라집니다.

상황	복구 방식
전체 DB 장애	RDS snapshot/PITR로 새 인스턴스 복구
일부 데이터 삭제	백업 DB에서 일부 데이터 추출
잘못된 migration	forward fix 또는 snapshot 복원
잘못된 update	백업 기준으로 affected row 복구
S3 파일 삭제	S3 versioning 또는 백업에서 복구

➕ 13-1. 전체 복구

snapshot 또는 PITR
  ↓
새 DB 인스턴스 생성
  ↓
데이터 확인
  ↓
앱 DATABASE_URL 전환

➕ 13-2. 일부 데이터 복구

백업 파일 또는 snapshot에서 임시 DB 복구
  ↓
필요한 row 확인
  ↓
운영 DB에 안전하게 재삽입/수정
  ↓
정합성 확인

➕ 13-3. 주의

전체 복구는 최근 정상 데이터가 덮일 수 있음
부분 복구는 정합성 확인이 중요
운영 DB 직접 수정 전 SQL 검토
복구 작업도 Audit Log/작업 기록 필요

전체 복구가 항상 답은 아닙니다.
일부 실수 삭제는 임시 DB에 복구한 뒤 필요한 데이터만 가져오는 방식이 더 안전할 수 있습니다.

✅ 14. 전체 DB 복구 Runbook

# Runbook: 전체 DB 복구

## 상황
- 운영 DB 장애
- 잘못된 migration으로 전체 서비스 영향
- 특정 시점으로 DB를 되돌려야 함

## 즉시 확인
- 장애 발생 시각:
- 마지막 정상 시각:
- 최근 배포:
- 최근 migration:
- 데이터 손실 허용 범위:
- 현재 DB snapshot 필요 여부:

## 복구 절차
1. 현재 운영 DB 상태 snapshot 생성 여부 판단
2. 복구할 시점 선택
3. RDS snapshot 또는 PITR로 새 DB 인스턴스 생성
4. 새 DB 접속 확인
5. 핵심 데이터 확인
   - 상담 신청
   - 상품
   - 관리자 계정
   - 상태 이력
6. 애플리케이션 연결 정보 준비
7. 점검 시간 또는 트래픽 전환 계획 수립
8. DATABASE_URL 전환
9. 백엔드 재시작
10. Health Check
11. 고객/관리자 Smoke Test
12. 로그 확인
13. 장애 기록 작성

## 주의
- 기존 운영 DB를 바로 덮어쓰지 않기
- 복구 시점 이후 데이터 손실 가능성 안내
- env 전환 후 되돌릴 수 있는지 확인
- 복구 후 migration 상태 확인

전체 DB 복구는 큰 작업입니다.
가능하면 기존 DB를 직접 덮어쓰기보다 새 DB를 만들고 검증한 뒤 전환하는 방식이 안전합니다.

✅ 15. 일부 데이터 복구 Runbook

# Runbook: 일부 데이터 복구

## 상황
- 특정 상품을 실수로 삭제
- 일부 상담 상태가 잘못 변경
- 대량 update 조건 실수
- 특정 row만 복구 필요

## 절차
1. 장애/실수 발생 시각 확인
2. 영향받은 테이블과 row 범위 확인
3. 백업 또는 snapshot에서 임시 DB 복구
4. 임시 DB에서 복구 대상 row 조회
5. 운영 DB 현재 상태와 비교
6. 복구 SQL 작성
7. SQL 리뷰
8. 가능하면 transaction으로 실행
9. 정합성 점검
10. Audit Log 또는 작업 기록 남기기

## 주의
- 백업 row를 무작정 운영 DB에 덮어쓰지 않기
- 관련 테이블도 함께 확인
- 상태 이력/Audit Log 정합성 확인
- 복구 후 관리자 화면에서 확인

➕ 15-1. 일부 복구가 어려운 이유

row 하나가 여러 테이블과 연결될 수 있음
현재 운영 DB에는 이후 변경 데이터가 있을 수 있음
백업 시점 데이터로 덮으면 최신 변경이 사라질 수 있음
상태 이력과 현재 상태가 불일치할 수 있음

일부 복구는 기술보다 판단이 어렵습니다.
“백업 값을 그대로 넣으면 된다”가 아니라 현재 상태와 비교해야 합니다.

✅ 16. 잘못된 UPDATE 대응

운영에서 가장 무서운 실수 중 하나는 where 조건이 잘못된 update입니다.

➕ 16-1. 위험한 SQL

UPDATE consults
SET status = 'CANCELED';

문제:

where 조건 없음
모든 상담 상태가 CANCELED로 변경
상태 이력 없이 현재 상태만 변경

➕ 16-2. 안전한 습관

SELECT COUNT(*)
FROM consults
WHERE status = 'NEW'
  AND created_at < '2026-08-01';

그다음:

UPDATE consults
SET status = 'CANCELED'
WHERE status = 'NEW'
  AND created_at < '2026-08-01';

➕ 16-3. 더 안전한 방식

1. SELECT로 대상 row 수 확인
2. 샘플 row 확인
3. transaction 시작
4. UPDATE 실행
5. 변경 row 수 확인
6. 이상하면 rollback
7. 정상이라면 commit

운영 DB에서 update/delete는 무조건 먼저 select로 범위를 확인해야 합니다.
대량 변경은 가능하면 스크립트와 리뷰를 거쳐야 합니다.

✅ 17. Transaction으로 수동 복구하기

수동 복구 SQL을 실행할 때는 transaction으로 감싸는 것이 안전합니다.

➕ 17-1. 예시

BEGIN;

UPDATE consults
SET status = 'NEW'
WHERE id IN (10, 11, 12);

INSERT INTO audit_logs (
  actor_type,
  actor_id,
  action,
  target_type,
  target_id,
  created_at
)
VALUES
  ('ADMIN', 1, 'MANUAL_RESTORE', 'CONSULT', '10', NOW()),
  ('ADMIN', 1, 'MANUAL_RESTORE', 'CONSULT', '11', NOW()),
  ('ADMIN', 1, 'MANUAL_RESTORE', 'CONSULT', '12', NOW());

-- 결과 확인
SELECT id, status
FROM consults
WHERE id IN (10, 11, 12);

COMMIT;

➕ 17-2. 중간에 이상하면

ROLLBACK;

➕ 17-3. 주의

긴 transaction 유지 금지
결과 확인 후 빠르게 commit/rollback
상태 이력도 함께 복구할지 판단
Audit Log 남기기
작업 전 백업/snapshot 확인

수동 복구는 최대한 작게, 명확하게, 기록을 남기면서 해야 합니다.
운영 DB 콘솔에서 감으로 실행하면 안 됩니다.

✅ 18. 삭제된 데이터 복구

Soft Delete라면 복구가 비교적 쉽습니다.
Hard Delete라면 백업에서 복구해야 합니다.

➕ 18-1. Soft Delete 복구

UPDATE products
SET deleted_at = NULL,
    deleted_by_admin_id = NULL,
    delete_reason = NULL
WHERE id = 10;

➕ 18-2. Hard Delete 복구

백업 DB 복구
  ↓
삭제된 row 조회
  ↓
관련 row 확인
  ↓
운영 DB에 insert
  ↓
FK/상태/이력 정합성 확인

➕ 18-3. 주의

같은 id를 재사용할 수 있는지 확인
sequence 값 충돌 확인
관련 child row도 복구 필요
복구 후 unique 충돌 확인

Hard Delete 복구는 생각보다 복잡합니다.
그래서 운영 데이터에는 Soft Delete가 유리한 경우가 많습니다.

✅ 19. Sequence 복구 주의

PostgreSQL에서 SERIAL 또는 autoincrement를 사용하면 sequence가 따로 관리됩니다.
수동 insert로 id를 지정해 복구하면 sequence 값이 꼬일 수 있습니다.

➕ 19-1. 문제 상황

현재 max(id) = 100

수동 insert:
id = 150

sequence는 아직 101

다음 자동 insert:
id = 101부터 생성

미래에 충돌 가능

➕ 19-2. sequence 조정

SELECT setval(
  'products_id_seq',
  (SELECT MAX(id) FROM products)
);

➕ 19-3. 주의

테이블별 sequence 이름 확인
수동 id insert 후 sequence 점검
Prisma autoincrement와 연결 확인
복구 후 새 데이터 생성 테스트

수동 복구 후에는 autoincrement가 정상인지 확인해야 합니다.
sequence 충돌은 나중에 갑자기 insert 실패로 나타날 수 있습니다.

✅ 20. S3 파일과 DB 복구 정합성

DB에는 보통 이미지 URL이나 파일 key만 저장됩니다.
실제 파일은 S3에 있습니다.
그래서 DB만 복구해도 파일이 없으면 화면이 깨질 수 있습니다.

➕ 20-1. 문제 예시

DB 복구:
product.imageUrl = /products/10/main.png

S3 상태:
main.png 삭제됨

결과:
상품 이미지는 DB에 있지만 화면에서 404

➕ 20-2. 대응

S3 versioning 검토
중요 이미지 삭제 시 soft delete처럼 처리
DB 복구 시 S3 파일 존재 확인
파일 삭제 작업도 Audit Log 기록

➕ 20-3. 점검 대상

상품 이미지
배너 이미지
엑셀 Export 파일
첨부 파일
알림톡 이미지

파일과 DB는 항상 함께 봐야 합니다.
DB 복구 후 이미지가 안 뜨는 문제는 흔하게 발생할 수 있습니다.

✅ 21. 복구 후 검증 Smoke Test

DB를 복구한 뒤에는 서비스가 정상적으로 동작하는지 반드시 확인해야 합니다.
단순히 DB 접속만 되면 끝이 아닙니다.

➕ 21-1. 백엔드 확인

GET /health
DB connection 확인
Prisma migration 상태 확인
주요 API 200 확인
로그에 error 없는지 확인

➕ 21-2. 고객 화면 확인

메인 접속
상품 목록 접속
상품 상세 접속
상품 이미지 표시
상담 신청 모달
상담 신청 저장 테스트

➕ 21-3. 관리자 화면 확인

관리자 로그인
상담 목록 조회
상담 상세 조회
상태 변경
상품 관리 조회
Audit Log 확인

➕ 21-4. 데이터 정합성 확인

consults.status와 마지막 상태 이력 일치
상품 참조 관계 정상
관리자 ID 참조 정상
알림톡/ExportJob 상태 이상 없음
sequence 정상

복구 후 검증은 배포 후 Smoke Test보다 더 중요합니다.
복구된 DB와 현재 코드가 맞는지 반드시 확인해야 합니다.

✅ 22. 백업/복구 문서화

백업과 복구는 기억에 의존하면 안 됩니다.
장애 상황에서는 침착하게 문서를 따라갈 수 있어야 합니다.

➕ 22-1. 문서에 포함할 것

백업 방식
백업 주기
백업 위치
접근 권한
복구 절차
복구 테스트 기록
RPO/RTO 기준
장애 시 연락/보고 기준
주의사항

➕ 22-2. 문서 구조 예시

docs/
  db/
    backup-policy.md
    restore-runbook.md
    partial-restore-runbook.md
    migration-backup-checklist.md
    anonymized-dump-guide.md

➕ 22-3. 복구 테스트 기록

# DB 복구 테스트 기록

## 테스트 일시
- 

## 백업 소스
- RDS snapshot / pg_dump

## 복구 대상
- local / staging

## 복구 절차
- 

## 확인 항목
- [ ] DB 접속
- [ ] Prisma migration 상태
- [ ] 상담 목록 조회
- [ ] 상품 목록 조회
- [ ] 관리자 로그인
- [ ] 상태 변경 테스트

## 문제점
- 

## 개선 TODO
-

복구 문서는 실제로 한 번 실행해보면서 작성해야 합니다.
머리로만 적은 복구 문서는 장애 때 틀릴 가능성이 큽니다.

✅ 23. 운영 장애 대응 흐름

DB 장애가 발생하면 먼저 장애 범위와 최근 변경을 확인해야 합니다.
바로 restore부터 하면 오히려 상황을 악화시킬 수 있습니다.

1. 증상 확인
2. 영향 범위 파악
3. 최근 배포/migration/수동 SQL 확인
4. 현재 DB 상태 snapshot 여부 판단
5. 로그 확인
6. 임시 대응
7. 복구 전략 결정
8. 복구 실행
9. 검증
10. 장애 기록

➕ 23-1. 먼저 확인할 것

DB 접속 가능한가?
특정 API만 실패하는가?
전체 API가 실패하는가?
최근 migration이 있었는가?
최근 대량 update/delete가 있었는가?
RDS CPU/Storage/Connection 문제인가?
애플리케이션 DATABASE_URL 문제인가?

➕ 23-2. 바로 하면 위험한 것

운영 DB에 바로 restore
원인 모르고 migration 재실행
where 조건 없이 update
백업 없이 수동 delete
migrate reset 실행
로그 없이 서버만 반복 재시작

DB 장애는 침착하게 원인을 좁혀야 합니다.
복구는 마지막 수단일 수도 있고, 일부 데이터 보정이 더 나은 선택일 수도 있습니다.

✅ 24. 장애 기록 Postmortem

DB 장애나 복구 작업 후에는 반드시 기록을 남겨야 합니다.
기록이 없으면 같은 실수를 반복합니다.

# DB 장애/복구 기록

## 요약
- 

## 발생 시간
- 시작:
- 감지:
- 복구:

## 영향 범위
- 고객 화면:
- 관리자 화면:
- API:
- 데이터:

## 원인
- 

## 최근 변경
- 배포:
- migration:
- 수동 SQL:
- 환경변수:

## 대응
- 

## 복구 방식
- 전체 복구 / 일부 복구 / forward fix / 수동 보정

## 데이터 손실 여부
- 

## 검증 결과
- [ ] Health Check
- [ ] 상담 신청
- [ ] 관리자 로그인
- [ ] 상담 목록
- [ ] 상태 변경
- [ ] 정합성 점검

## 재발 방지
- [ ] migration 전 snapshot
- [ ] 수동 SQL 리뷰
- [ ] Runbook 수정
- [ ] 권한 제한
- [ ] 모니터링 추가

Postmortem은 잘못한 사람을 찾는 문서가 아닙니다.
다음 장애를 줄이기 위한 운영 자산입니다.

✅ 25. 실무 체크리스트

➕ 25-1. 백업 체크리스트

RDS 자동 백업이 켜져 있는가?
백업 보존 기간이 정해져 있는가?
수동 snapshot 생성 방법을 아는가?
DB migration 전 백업 기준이 있는가?
pg_dump 사용 방법을 알고 있는가?
백업 파일 저장 위치와 권한이 정해져 있는가?
백업 파일에 개인정보가 포함됨을 인지하고 있는가?
백업 비용과 보관 정책을 확인하는가?

➕ 25-2. 복구 체크리스트

snapshot에서 새 DB를 복구해본 적 있는가?
pg_restore로 로컬/스테이징에 복구해본 적 있는가?
전체 복구 Runbook이 있는가?
일부 데이터 복구 Runbook이 있는가?
복구 후 Smoke Test 항목이 있는가?
복구 후 sequence 점검 방법을 아는가?
DB와 S3 파일 정합성을 확인하는가?
복구 작업 기록을 남기는가?

➕ 25-3. 운영 DB 작업 체크리스트

update/delete 전 select로 대상 count를 확인하는가?
대량 변경 전 snapshot을 고려하는가?
수동 SQL은 transaction으로 감싸는가?
운영에서 migrate reset을 절대 사용하지 않는가?
migration 전 staging에서 테스트하는가?
migration 실패 시 forward fix 계획이 있는가?
수동 보정 작업도 Audit Log 또는 작업 기록에 남기는가?
복구 후 정합성 점검 쿼리를 실행하는가?

➕ 25-4. 보안 체크리스트

운영 DB dump를 Git에 올리지 않는가?
운영 DB dump를 개인 Mac에 오래 보관하지 않는가?
백업 파일 접근 권한이 제한되어 있는가?
익명화 dump를 사용할 수 있는가?
백업 파일을 AI 도구에 업로드하지 않는가?
S3 백업 파일이 public으로 열려 있지 않은가?
백업 다운로드 이력이 기록되는가?
복구 권한이 최소화되어 있는가?

✅ 26. AI에게 DB 백업/복구 전략을 물어볼 때 좋은 질문법

NestJS + Prisma + PostgreSQL/RDS 기반 온라인 휴대폰 판매몰의 DB 백업/복구 전략을 정리하려고 해.

서비스 상황:
1. 고객 상담 신청, 상품, 관리자 계정, 상태 변경 이력, Audit Log가 DB에 저장됨
2. 상품 이미지는 S3에 저장되고 DB에는 fileUrl 또는 key가 있음
3. 운영 DB에는 이름, 전화번호, 상담 메모, IP 같은 개인정보가 포함될 수 있음
4. Prisma migration을 운영에 적용해야 함
5. DB migration 전 snapshot 기준을 만들고 싶음
6. 운영 실수로 일부 row가 삭제되거나 잘못 update될 수 있음
7. 전체 DB 복구와 일부 데이터 복구 Runbook이 필요함
8. 로컬 개발에는 운영 dump를 그대로 쓰기보다 익명화 dump를 쓰고 싶음

요청:
- PostgreSQL 백업 방식 정리
- pg_dump/pg_restore 기본 명령어
- RDS snapshot과 PITR 개념
- migration 전 백업 체크리스트
- 전체 DB 복구 Runbook
- 일부 데이터 복구 Runbook
- 잘못된 update/delete 대응법
- sequence 복구 주의사항
- S3 파일과 DB 정합성 확인
- 백업 파일 보안 기준
- 익명화 dump 기준
- 복구 후 Smoke Test
- 장애 기록 템플릿
을 실무 기준으로 정리해줘.

➕ 26-1. AI 답변 검증 기준

백업보다 복구 테스트가 중요하다고 설명하는가?
운영 DB에 바로 restore하지 말라고 경고하는가?
RDS snapshot 복구가 새 인스턴스 기반일 수 있음을 고려하는가?
pg_dump/pg_restore 명령어를 구분하는가?
운영 DB dump 개인정보 위험을 강조하는가?
migration 전 snapshot 기준을 제안하는가?
부분 복구 시 현재 운영 데이터와 비교해야 함을 설명하는가?
sequence setval 같은 수동 복구 주의점을 언급하는가?
DB와 S3 파일 정합성을 함께 보는가?
migrate reset 같은 위험 명령을 금지하는가?

📌 요약

DB 백업은 운영 DB를 특정 시점 기준으로 복사해두는 것이며, 실수 삭제, migration 실패, 장애, 보안 사고에 대비하는 최후의 안전장치입니다.
중요한 것은 백업 파일의 존재가 아니라 실제로 복구할 수 있는지이며, 복구 테스트와 Runbook이 없으면 반쪽짜리 백업입니다.
RPO는 허용 가능한 데이터 손실 시간, RTO는 복구 완료까지 허용 가능한 시간을 의미하며, 서비스 중요도에 따라 현실적인 기준을 정해야 합니다.
PostgreSQL 백업은 pg_dump 같은 논리 백업, RDS snapshot 같은 물리 백업, PITR 같은 특정 시점 복구로 나눌 수 있습니다.
pg_dump -Fc로 백업하면 pg_restore로 복구하기 좋지만, 운영 비밀번호와 dump 파일 보안에 주의해야 합니다.
RDS 자동 백업과 snapshot은 반드시 켜져 있는지, 보존 기간은 얼마인지, snapshot에서 새 DB를 복구하는 절차를 알고 있는지 확인해야 합니다.
운영 DB dump에는 개인정보가 들어 있을 수 있으므로 Git 커밋, 공용 폴더 보관, AI 업로드, 로컬 장기 보관을 피해야 합니다.
Prisma migration 전에는 자동 백업 상태, 수동 snapshot 필요 여부, staging 테스트, rollback/forward fix 계획을 확인해야 합니다.
전체 DB 복구는 기존 DB를 바로 덮어쓰기보다 snapshot/PITR로 새 DB를 만들고 검증한 뒤 앱 연결을 전환하는 방식이 안전합니다.
일부 데이터 복구는 백업 DB에서 필요한 row를 확인한 뒤 현재 운영 DB와 비교하여 transaction으로 조심스럽게 반영해야 합니다.
수동 insert 복구 후에는 PostgreSQL sequence가 꼬이지 않았는지 setval로 확인해야 할 수 있습니다.
DB 복구 후에는 백엔드 health check, 고객 상담 신청, 관리자 로그인/목록/상태 변경, 상태 이력 정합성, S3 파일 존재 여부까지 Smoke Test해야 합니다.

juni

이전 포스트

TIL - 20260819

다음 포스트