소개
시스템 관리에서 데이터 손실은 발생 여부가 아니라 발생 시점의 문제입니다. 하드웨어 장애, 소프트웨어 버그, 사람의 실수 등 어떤 원인으로든 중요한 데이터를 잃으면 치명적인 결과가 발생할 수 있습니다. 따라서 백업과 복구는 데이터베이스 관리에서 가장 중요한 기술 중 하나입니다.
이 실습에서는 완전한 "재해 복구"를 시뮬레이션합니다. 먼저 정상적으로 작동하는 데이터베이스를 안전하게 백업한 다음, 데이터베이스를 삭제하여 재해를 시뮬레이션하고 백업을 사용해 데이터베이스를 복구합니다.
다음 방법을 배웁니다.
mysqldump유틸리티를 사용해 논리적 백업을 만듭니다.- 데이터베이스를 삭제하여 치명적인 장애를 시뮬레이션합니다.
- 백업 파일에서 데이터베이스를 원래 상태로 복원합니다.
논리적 백업은 스키마와 데이터를 다시 만들 수 있는 SQL 문을 저장합니다. 이는 데이터베이스 원본 파일을 그대로 복사하는 물리적 백업과 다릅니다. 두 방식 모두 사용되지만, 논리적 백업은 초보자가 읽고 이해하기 쉽습니다.
이 차이가 중요한 이유는 백업 유형마다 해결하는 문제가 조금씩 다르기 때문입니다. 논리적 백업은 이식성이 높고 사람이 읽을 수 있지만, 물리적 백업은 일반적으로 스토리지 엔진과 복구 내부 구조에 더 가깝습니다.
백업 만들기
먼저 보존할 가치가 있는 데이터베이스가 있는지 확인합니다. 사용자 데이터가 미리 입력된 app_db라는 데이터베이스가 준비되어 있습니다.
현재 데이터를 확인합니다.
sudo mysql -e "SELECT * FROM app_db.users;"
사용자 목록 (Alice, Bob, Charlie) 이 표시되어야 합니다.
이제 mysqldump 도구를 사용해 논리적 백업을 만듭니다. 논리적 백업은 데이터베이스를 처음부터 다시 구축하는 데 필요한 모든 SQL 명령 (CREATE TABLE, INSERT 등) 이 들어 있는 텍스트 파일을 내보내는 방식입니다.
따라서 백업 파일은 정체를 알 수 없는 바이너리 데이터가 아닙니다. 일반적으로 나중에 데이터베이스 서버에서 다시 실행하여 스키마와 데이터를 복구할 수 있는 SQL 스크립트입니다.
다음 명령을 실행해 데이터베이스를 backup.sql이라는 파일로 저장합니다.
sudo mysqldump app_db > ~/project/backup.sql
명령 분석:
mysqldump: 데이터베이스 내용을 내보내는 데 사용하는 유틸리티입니다.app_db: 백업할 특정 데이터베이스입니다.>: 명령의 출력을 파일로 보내는 Linux 리디렉션 연산자입니다.~/project/backup.sql: 백업 파일의 저장 경로입니다.
백업 파일이 생성되었는지 확인합니다.
ls -l ~/project/backup.sql
파일을 열어 SQL 명령을 확인할 수도 있습니다.
head -n 20 ~/project/backup.sql
데이터 손실 시뮬레이션
이제 긴장되는 작업을 진행합니다. 복구 계획을 테스트하려면 재해 상황이 필요하므로, 운영 데이터베이스를 실수로 삭제하는 상황을 시뮬레이션합니다.
경고: 아래 명령은 데이터를 영구적으로 삭제합니다. 실제 운영 환경에서는 데이터를 삭제하려는 것이 확실하지 않은 한 절대 실행하면 안 됩니다.
실제 데이터 손실 후에도 복구가 작동하는지 확인해야 백업의 의미가 있습니다. 한 번도 테스트하지 않은 백업 전략은 가정에 불과합니다.
app_db 데이터베이스를 삭제합니다 (drop).
sudo mysql -e "DROP DATABASE app_db;"
데이터베이스에 접근해 재해가 발생했는지 확인합니다.
sudo mysql -e "USE app_db;"
다음 오류가 표시되어야 합니다: ERROR 1049 (42000): Unknown database 'app_db'.
이 메시지는 데이터베이스가 삭제되었음을 의미합니다. 백업이 없는 실제 운영 서버였다면 매우 심각한 상황입니다.
데이터베이스 복원
다행히 backup.sql 파일이 있습니다. 이 파일을 사용해 데이터를 복원할 수 있습니다.
하지만 mysqldump는 기본적으로 데이터베이스의 내용만 내보내며, 데이터베이스 자체를 생성하는 명령은 내보내지 않습니다. app_db를 완전히 삭제했으므로 먼저 데이터를 저장할 빈 데이터베이스를 만들어야 합니다.
이 점을 통해 백업에 실제로 어떤 내용이 포함되었는지 이해할 수 있습니다. 선택한 명령과 옵션에 해당 부분을 명시적으로 포함하지 않는 한, 백업이 모든 것을 담은 마법 같은 스냅샷은 아닙니다.
빈 데이터베이스를 만듭니다.
sudo mysql -e "CREATE DATABASE app_db;"
백업 파일의 데이터를 가져옵니다.
sudo mysql app_db < ~/project/backup.sql
복원 명령 분석:
sudo mysql: 데이터베이스 서버에 연결합니다.app_db: MySQL 에 대상 데이터베이스로 사용할 데이터베이스를 지정합니다.<: Linux 입력 리디렉션 연산자입니다. 파일의 내용을 읽어 사용자가 직접 입력하는 것처럼mysql명령에 전달합니다.
명령이 아무 출력 없이 종료되었다면 일반적으로 성공한 것입니다.
복원 과정은 SQL 문을 서버에 다시 전달하는 작업입니다. 즉, 복구는 논리적 백업에 저장된 지침을 제어된 방식으로 다시 실행하는 작업인 경우가 많습니다.
데이터 복구 확인
모든 백업 계획에서 마지막이자 가장 중요한 단계는 확인입니다. 복원 명령에서 오류가 발생하지 않았다고 해서 데이터가 올바르다는 의미는 아닙니다. 반드시 확인해야 합니다.
이는 모든 시스템 작업에서 가장 중요한 운영 습관 중 하나입니다. 성공은 "명령이 끝났다"는 뜻이 아니라 "그 후 시스템 상태가 올바르다"는 뜻입니다.
다시 users 테이블을 조회합니다.
sudo mysql -e "SELECT * FROM app_db.users;"
성공 기준:
원래 데이터가 표시되어야 합니다.
+----+---------+---------------------+
| id | name | email |
+----+---------+---------------------+
| 1 | Alice | alice@example.com |
| 2 | Bob | bob@example.com |
| 3 | Charlie | charlie@example.com |
+----+---------+---------------------+
Alice, Bob, Charlie 가 표시되면 재해 상황에서 데이터를 성공적으로 복구한 것입니다.
요약
이 실습에서는 전체 재해 복구 주기를 성공적으로 완료했습니다. 다음 방법을 배웠습니다.
- 백업:
mysqldump를 사용해 데이터베이스를 파일로 내보냅니다. - 삭제:
DROP DATABASE를 사용해 데이터 손실 상황을 시뮬레이션합니다. - 복원: 입력 리디렉션
<을 사용해 SQL 덤프 파일을 가져옵니다. - 확인: 복구된 데이터의 무결성을 확인합니다.
정기적인 백업은 데이터 손실에 대비하는 가장 중요한 방어 수단입니다. 실제 환경에서는 이 과정을 자동화하고 복원을 자주 테스트해야 합니다.
