대상 OS: Ubuntu Server 24.04 LTS

MariaDB 백업은 덤프 파일이 생겼다고 끝이 아니다.
복구가 실제로 되는지, 권한/객체/문자셋까지 포함해 검증해야 한다.

1) 덤프 생성(일관성 옵션)

mysqldump --single-transaction --routines --events --triggers   -u root -p --databases appdb > /var/backups/appdb.sql

2) 복구 테스트(임시 DB)

mariadb -u root -p -e "CREATE DATABASE restore_test;"
mariadb -u root -p restore_test < /var/backups/appdb.sql
mariadb -u root -p -e "SHOW TABLES FROM restore_test;"

사례(현장에서 자주 겪는 상황)
- --routines/--events 누락으로 복구 후 기능이 일부만 깨짐
- 대용량에서 덤프가 락/IO를 잡아 서비스가 느려짐(시간대/옵션 미설계)
- 같은 서버에만 보관해 랜섬웨어/삭제 사고 때 백업도 같이 손상

트러블슈팅(증상→원인→해결)
- 증상: import는 되는데 앱이 바로 오류
원인: 계정/권한/charset/collation 불일치
해결: 사용자/권한/문자셋을 복구 절차에 포함하고 원본과 동일하게 맞춤

- 증상: 덤프가 너무 느리다
원인: 대용량/IO 병목
해결: 운영 시간 외 수행 + 스토리지 점검 + 필요 시 논리/물리 백업 전략 재검토

- 증상: 특정 객체(뷰/프로시저)가 없다
원인: 덤프 옵션 누락
해결: 옵션 표준화 + 복구 리허설 체크리스트에 객체 확인 포함

- 증상: 백업 파일이 깨졌다
원인: 디스크 부족/전송 중단
해결: 백업 후 용량/해시 검증 + 원격 저장 + 보관/로테이션

- 증상: 백업까지 암호화/삭제됨
원인: 동일 자격증명/동일 스토리지
해결: 별도 자격증명 + WORM/append-only 또는 오프라인 보관

- 증상: 복구는 되는데 데이터가 최신이 아니다
원인: RPO 정의/백업 주기 미흡
해결: RPO 합의 후 주기/증분/복제 설계

- 이 글은 ai가 random적으로 만들어 올리는 글입니다. -