MySQL · PostgreSQL · MongoDB의 논리 백업을 준비하고, 복구 절차까지 확인하세요.
아래 예제는 실제 계정·비밀번호가 없는 시작값입니다. 서버에 맞게 바꾼 후 스크립트를 다운로드하세요.
bash -n backup-mysql.sh로 문법을 먼저 확인하세요. 이 검사는 DB 접속이나 파일 생성 없이 셸 문법만 검사합니다. 엔진에 따라 파일명의 mysql 부분이 달라집니다.
실제 실행 전 인증 파일을 서버에서 만들고 접근 권한을 제한하세요. 다운로드 파일에는 입력한 경로·호스트·DB 이름이 포함됩니다. 실행 권한을 주기 전에 내용을 읽고 별도 환경에서 복구까지 검증하세요. 생성은 자동 실행이나 예약 등록을 하지 않습니다.
광고 · 쿠팡 파트너스 추천 상품
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
엔진, 호스트, 포트, 백업 계정과 DB 이름을 입력하면 하나의 데이터베이스를 논리 덤프로 내보내는 Bash 스크립트를 만듭니다. 세 엔진 모두 DB 이름을 필수로 받아 ‘빈칸이면 전체 백업’이라는 모호한 동작을 없앴습니다. 서버 전체 이미지, 운영체제 파일, 사용자 권한 체계까지 모두 복구해 주는 도구는 아닙니다.
작은 화면에서는 표를 좌우로 스크롤할 수 있습니다.
| 엔진 | 생성 결과 | 복구 시 고려할 사항 |
|---|---|---|
| MySQL | mysqldump → gzip 압축 SQL | InnoDB에 --single-transaction을 적용합니다. 비트랜잭션 테이블이나 동시 DDL까지 일관성을 보장하지는 않습니다. |
| PostgreSQL | pg_dump → gzip 압축 일반 SQL | 선택한 DB 하나를 백업합니다. 클러스터 전역 역할·테이블스페이스는 별도로 준비해야 합니다. |
| MongoDB | mongodump → gzip BSON 아카이브 | mongorestore로 복구합니다. 운영 중 쓰기 전체에 대한 특정 시점 일관성이나 샤딩 환경을 자동 처리하지 않습니다. |
MySQL, 계정 backup_user, DB app_db, 저장 경로 /var/backups/app-mysql, 확인 기준 30일을 입력해 보세요. 인증 파일은 서버의 /etc/db-backup/mysql.cnf에 따로 준비합니다. 웹페이지에는 파일 경로만 넣고 비밀번호는 넣지 않습니다.
생성된 스크립트는 전용 하위 폴더 안의 임시 작업 디렉터리에 덤프를 쓰고, 압축 검사가 통과한 결과만 완료 파일로 옮깁니다. 같은 DB의 작업을 동시에 실행하지 않도록 운영 스케줄을 구성하세요. 자동 실행 전에 직접 한 번 실행하고 테스트 DB에 복구할 수 있는지 확인해야 합니다.
set -euo pipefail로 덤프 또는 압축 실패 시 중단합니다. 실패한 임시 파일은 정리하고 성공 파일로 게시하지 않습니다.이 생성기는 Linux Bash, GNU 기본 도구, 해당 DB의 백업 클라이언트를 전제로 합니다. Windows PowerShell에 그대로 붙여 넣지 마세요. 경로에 공백이나 작은따옴표가 있어도 셸 인자로 묶지만, 계정 권한·DB 버전·복구 호환성은 실제 서버에서 점검해야 합니다. MariaDB는 배포판에 따라 mariadb-dump를 사용하므로 MySQL 명령을 그대로 호환된다고 가정하지 마세요.
압축 파일이 존재하는 것만으로 복구 가능성을 판단할 수 없습니다. gzip 검사는 압축 구조만 확인합니다. 테스트 DB에 가져온 뒤 주요 테이블 수, 샘플 레코드와 애플리케이션 조회까지 확인해야 합니다. 압축률도 데이터 특성에 따라 달라집니다.
모든 백업이 성공하고 복구 가능하다는 전제에서만 그 간격을 논할 수 있습니다. 마지막 작업이 실패했다면 실제 손실 가능 구간은 더 길어집니다. 마지막 실행 시간이 아닌 마지막 복구 검증 완료 시각을 함께 기록하세요.
같은 권한으로 수정 가능한 복사본은 계정 침해나 잘못된 삭제의 영향을 함께 받을 수 있습니다. 보관 기간, 접근 분리, 다른 위치의 사본, 복원에 필요한 인증 자료를 별도로 계획해야 합니다.