📌`mysqldump`를 활용한 백업

mysqldump는 MySQL에서 제공하는 기본 백업 도구로, 데이터베이스의 구조와 데이터를 SQL 형태로 덤프하여 백업합니다. 이는 논리적 백업 방식으로, 백업된 SQL 파일을 통해 데이터베이스를 복구할 수 있습니다.

사용 예시:

mysqldump -u [사용자명] -p[비밀번호] [데이터베이스명] > [백업파일명].sql

장점:

이식성: 백업 파일이 SQL 스크립트 형태이므로, 다양한 플랫폼에서 복구가 가능합니다.
선택적 백업: 특정 테이블만 선택하여 백업할 수 있습니다.

단점:

성능 저하: 대용량 데이터베이스의 경우 백업 및 복구 시 시간이 많이 소요될 수 있습니다.
락 발생: 백업 과정에서 테이블 락이 발생하여 다른 작업에 영향을 줄 수 있습니다.
비유: mysqldump를 활용한 백업은 마치 도서관의 책을 하나씩 읽어가며 모든 내용을 노트에 필사하는 것과 같습니다. 이 방법은 책의 내용을 정확하게 기록할 수 있지만, 시간이 많이 걸리고 그동안 다른 사람이 그 책을 이용하기 어려울 수 있습니다.

🛠️ `XtraBackup`을 활용한 백업

XtraBackup은 Percona에서 제공하는 오픈 소스 백업 도구로, MySQL과 MariaDB에서 사용할 수 있습니다. 이는 물리적 백업 방식을 사용하여 데이터 파일을 그대로 백업하며, 핫 백업(Hot Backup)을 지원하여 서비스 중단 없이 백업을 수행할 수 있습니다.

사용 예시:

xtrabackup --backup --target-dir=/backup/mysql/

장점:

무중단 백업: 서비스 중단 없이 백업을 수행할 수 있습니다.
빠른 백업 및 복구 속도: 데이터 파일을 직접 복사하므로 대용량 데이터베이스에서도 효율적입니다.

단점:

복잡한 설정: 설치 및 설정 과정이 다소 복잡할 수 있습니다.
공간 요구 사항: 백업 시 원본 데이터와 동일한 크기의 저장 공간이 필요합니다.
비유: XtraBackup을 활용한 백업은 도서관의 책장을 통째로 복사하는 것과 같습니다. 이 방법은 책의 내용을 빠르게 복사할 수 있고, 다른 사람들이 그 책을 계속 이용할 수 있지만, 복사된 책장을 보관할 충분한 공간이 필요합니다.

⏳ PITR(Point-in-Time Recovery) 심화 개념 정리

🎞️ 비유: 영화 촬영과 되감기

생각해볼까요?

당신이 영화를 촬영하는 감독이라고 가정해봅시다.

매일 매일 새로운 장면을 찍고 있는데,

어느 날 촬영하다 실수해서 중요한 장면이 잘못 찍혔어요.

그런데 다행히도!

*매일 찍은 장면을 테이프에 저장(백업)**해 두었고,
*촬영할 때마다 찍은 내용이 시간순으로 기록(로그 파일)**되어 있어요.

PITR은 마치 촬영한 영화를 특정 장면까지 되감기(복구)해서 실수하기 전 상태로 돌리는 것과 똑같아요!

📌 PITR 핵심 개념 쉽게 풀기

단계	영화 비유	DB에서는
1. 기초 백업	매일 테이프에 촬영 내용 저장	DB 전체 백업 수행
2. 로그 파일 보관	촬영할 때마다 일지에 어떤 장면 찍었는지 기록	바이너리 로그에 변경 사항 기록
3. 복구 시점 결정	“어제 점심 전에 찍은 장면까지만 살리고 싶다”	복구할 정확한 시간/트랜잭션 결정
4. 로그 재생	테이프 돌리고, 일지 보며 장면 순서대로 복원	전체 백업 복원 후 로그를 시점까지 재적용

🚚 택배 회사 비유!

3월 1일: 창고 물류 전체 목록 스캔해 복사본 보관 (전체 백업)
3월 2일~5일: 매일 택배 추가, 이동 기록서 작성 (바이너리 로그)
3월 6일 오후 2시: 실수로 잘못된 택배 출고! 😱

📢 → “3월 6일 오후 1시까지만 정상 데이터로 돌려줘!”

복구 절차:

3월 1일 스캔해둔 복사본 복원
3월 2일부터 3월 6일 오후 1시까지만 기록서(로그)를 차근히 반영
이후 잘못된 택배 출고는 반영하지 않음

🛠️ 실제 SQL 예시로 정리하기 (MariaDB 기준)

🔹 1. 전체 백업 수행

mysqldump -u root -p --all-databases > full_backup_20250301.sq

🔹 2. 바이너리 로그 활성화 (my.cnf 설정)

[mysqld]
log-bin=mysql-bin
server-id=1

바이너리 로그 자동 기록 시작

🔹 3. 장애 발생 & 복구 시점 결정

예: 장애 발생 시간 = 2025-03-06 14:00:00

복구 목표: 2025-03-06 13:59:59 상태까지 되돌리기

🔹 4. 복구 절차

(1) 전체 백업 복원

mysql -u root -p < full_backup_20250301.sql

(2) 바이너리 로그 적용 (PITR)

mysqlbinlog --stop-datetime="2025-03-06 13:59:59" mysql-bin.000001 | mysql -u root -p

➡️ 지정한 시점까지의 변경 사항만 반영

✅ PITR의 핵심 장점

특징	설명
정확한 시점 복구 가능	실수나 장애가 발생하기 직전까지의 데이터만 살릴 수 있음
데이터 무결성 보장	트랜잭션 순서대로 재생, 데이터 일관성 유지
부분적 복구 가능	전체 복구뿐 아니라 특정 시간만 선택 가능

🎯 PITR을 잘 활용하려면?

바이너리 로그 주기적으로 백업해두기
서버 시간 동기화(NTP) 필수 (정확한 시점 맞추기)
테스트 환경에서 복구 연습 꼭 해보기!
복구 스크립트 만들어 자동화 가능 (shell + cron)

🚀 실무 팁 & 주의사항

바이너리 로그 보관 주기 잘 설정 (7일~30일 등 정책에 따라)
저장 공간 충분히 확보 (로그 파일 용량 커질 수 있음)
복구 시 시간 단위가 아닌 트랜잭션 ID 기준으로도 복구 가능

📢 정리

단계	설명
1. 전체 백업	데이터베이스 스냅샷
2. 바이너리 로그 보관	변경 내역 시간순 기록
3. 복구 시점 결정	장애 직전 원하는 시간 선택
4. 로그 재생	백업 + 로그로 정확한 시점 복구

📦 로그 파일을 활용한 데이터 복구 및 장애 복구 전략 심화 개념 정리

🚚 비유: 택배 회사의 물류 시스템에 비유해보기

생각해봅시다.

당신이 택배 회사의 운영 책임자라고 해요.

매일 수백만 개의 택배가 전국을 돌아다니고 있습니다.

그런데, 가끔 창고 화재, 시스템 오류, 도난 등의 사고가 발생할 수 있어요.

그래서 택배 회사는 여러 기록(log) 시스템을 사용해서 문제가 생겼을 때 빠르게 복구할 수 있도록 해요.

DB에서 로그 파일과 복구 전략이 하는 역할이 바로 이것과 같아요!

📄 1. 주요 로그 파일 = 택배 회사의 기록 시스템

로그 파일	택배 회사 비유	설명
바이너리 로그	택배 이동 기록서: 어떤 택배가 언제, 어디서, 어디로 이동했는지 전부 기록	데이터 변경 사항 (INSERT, UPDATE, DELETE 등) 기록. 데이터베이스 복구 시 핵심 역할.
에러 로그	사고 일지: 창고 화재, 사고 발생 시 보고서	DB 서버에서 에러, 경고 메시지 기록. 장애 원인 파악에 필요.
일반 쿼리 로그	통화 기록: 고객이 콜센터에 전화한 모든 기록	모든 클라이언트 요청을 기록. 주로 디버깅, 문제 원인 분석 시 사용.

🔥 2. 장애 복구 전략 = 위기 대응 매뉴얼

📌 정기적인 백업 = 창고에 물건 스캔 & 복사본 보관

정기적으로 창고 내의 모든 택배를 스캔해서 다른 창고(백업)에 복사본을 저장.
DB에서는 전체 백업 + 증분 백업을 통해 손실 최소화.

예시

매일 새벽 2시: 전체 데이터 백업

매시간: 변경된 부분만 증분 백업

📌 로그 파일 모니터링 = CCTV & 실시간 경보 시스템

창고 내부에 CCTV가 있고, 관리자가 계속 확인.
사고(화재, 침입 등) 발생 시 경보음 발생.

DB에서는 로그 파일 실시간 모니터링 도구로 이상 징후(에러, 비정상 쿼리)를 조기에 탐지.

📌 복구 절차 마련 = 재난 매뉴얼 만들기 & 직원 훈련

화재나 시스템 다운 시, 정해진 절차에 따라 대피하고 시스템 복구하는 매뉴얼을 미리 만들어 놓음.
DB에서도 복구 시나리오 문서화:
1. 백업 데이터 불러오기
2. 바이너리 로그로 최근까지 변경 사항 반영 (Point-In-Time Recovery)
3. 시스템 정상 작동 확인

📌 테스트 환경 구축 = 가상 사고 훈련

실제 사고가 나기 전에 모의 훈련을 해서 문제점을 찾고 보완.
DB에서는 테스트 서버에서 정기적으로 복구 테스트.

🎯 Point-In-Time Recovery(PITR) 예제로 이해하기

🚚 택배 회사 비유 예시

3월 1일: 창고 내 모든 택배 목록 스캔 (전체 백업)
3월 2~5일: 매일 새로운 택배 추가/이동 기록서 작성 (바이너리 로그)
3월 6일 오후 3시: 창고 화재 발생!

🔥 복구 절차:

3월 1일 백업된 택배 목록 복원 → 창고 원래 상태 복원
3월 2일~6일 오후 3시까지 기록된 이동 기록서를 보고 택배 이동 경로, 추가된 택배 다시 반영 → PITR 성공!

📊 SQL 실제 예제

-- 1. 전체 백업에서 복원 (mysqldump 사용)
mysql -u root -p < full_backup_20250301.sql

-- 2. 바이너리 로그를 특정 시점까지 적용
mysqlbinlog --stop-datetime="2025-03-06 15:00:00" binlog.000001 | mysql -u root -p

이렇게 하면 3월 6일 오후 3시 이전 상태로 완벽 복구!

✅ 핵심 정리

개념	쉽게 말하면	예시
바이너리 로그	데이터 변경 내역 기록서	택배 이동 기록서
에러 로그	사고 보고서	창고 화재, 시스템 문제
정기 백업	창고 전체 스캔 및 복사본 저장	mysqldump로 정기 백업
PITR	사고 이전 상태로 되돌리기	전체 백업 + 바이너리 로그 재적용
테스트 환경	가상 훈련장	복구 시나리오 테스트 서버에서 주기적 테스트

🚀 실무에서의 활용 팁

백업 스케줄 자동화 (cron + 스크립트)
에러 로그 & 바이너리 로그 실시간 모니터링 도구 (ex: Prometheus + Grafana 연동)
주기적인 복구 리허설을 통해 실제 장애 대비

📌mysqldump를 활용한 백업

🛠️ XtraBackup을 활용한 백업