데이터베이스 백업 파일이 실제 복구로 이어지는지 확인하는 법

백업 폴더에 날짜가 붙은 파일이 보이면 데이터가 안전하다고 생각하기 쉽습니다. 하지만 파일이 비어 있거나, 필요한 권한 정보가 빠졌거나, 현재 서버 버전과 맞지 않으면 사고가 난 뒤에야 복구가 안 된다는 사실을 알 수 있습니다.

비상용 열쇠를 서랍에 보관하는 장면을 떠올려 보세요. 열쇠 모양이 그럴듯해도 실제 자물쇠를 열어 보기 전에는 맞는 열쇠인지 확신할 수 없습니다. 데이터베이스 백업도 원본과 떨어진 시험용 자물쇠에서 열어 봐야 쓸 수 있는 백업인지 알 수 있습니다.

백업 파일과 복구 가능한 상태는 다르다

백업은 특정 시점의 데이터나 데이터베이스 구조를 다른 매체에 보존하는 일입니다. 복구는 그 자료를 이용해 다시 읽고 쓸 수 있는 데이터베이스를 만드는 일입니다. 파일 이름, 크기, 생성 시각은 백업 작업이 무언가를 남겼다는 단서일 뿐 복구 성공의 증거는 아닙니다.

PostgreSQL 공식 문서는 백업 방식을 SQL 덤프, 파일 시스템 수준 복사, 연속 보관으로 나누며 각각 전제와 장단점이 다르다고 설명합니다. 어떤 방식으로 만들었는지 모르면 어떤 도구와 순서로 되살려야 하는지도 정할 수 없습니다. 먼저 제품 이름과 버전, 백업 방식, 포함 범위, 생성 시각을 한 줄씩 기록합니다.

어떤 시점과 범위를 되찾을지 먼저 정한다

복구의 목표는 단순히 명령이 끝나는 것이 아닙니다. 장애 직전까지 필요한지, 전날 마감 시점이면 되는지, 한 데이터베이스만 필요한지, 사용자와 권한까지 필요한지에 따라 준비가 달라집니다. PostgreSQL의 pg_dump는 한 데이터베이스를 내보내지만 역할과 테이블스페이스 같은 클러스터 전체 정보는 별도로 다뤄야 합니다.

다음 네 질문에 답하지 못하면 복원 명령을 고르지 않습니다.

• 백업은 어느 서비스와 어느 데이터베이스에서 만들어졌나요?
• 데이터가 어느 시점까지 들어 있어야 하나요?
• 표와 데이터 외에 사용자, 권한, 확장 기능도 필요한가요?
• 복구 뒤 어떤 화면이나 조회가 정상이어야 하나요?
• 실패하면 시험 환경을 어떻게 버리고 처음부터 다시 시작하나요?

만든 형식과 되살리는 도구를 맞춘다

덤프는 데이터베이스 내용을 다시 만들 수 있는 파일로 내보낸 결과입니다. PostgreSQL의 일반 텍스트 덤프는 SQL 문장으로 되어 있어 psql로 읽고, custom·directory·tar 같은 아카이브 형식은 pg_restore로 복원합니다. 확장자만 보고 형식을 단정하지 말고 백업을 만든 기록과 공식 문서를 함께 확인해야 합니다.

pg_restore --list는 아카이브의 목차를 보여 주는 기능이지만, 낯선 파일을 운영 서버에서 바로 열 필요는 없습니다. 암호화된 백업이라면 복호화 키의 보관 위치와 접근 담당자가 따로 있어야 합니다. 파일은 있는데 키가 없거나, 키는 있는데 어느 백업과 짝인지 모르는 상태도 복구 준비가 끝난 것이 아닙니다.

운영 원본과 분리된 빈 환경에서 연습한다

복구 훈련은 실제 운영 데이터베이스를 덮어쓰지 않는 빈 시험 환경에서 진행합니다. 서버 버전, 필요한 확장 기능, 문자 인코딩, 저장 공간을 먼저 확인하고, 운영과 헷갈리지 않는 이름과 접근 주소를 사용합니다. 연결 문자열 하나를 잘못 붙여 넣으면 시험 명령이 운영 자료를 바꿀 수 있으므로 대상 주소를 사람이 다시 읽는 단계가 필요합니다.

다음은 실행 명령이 아니라 복구 계획을 적는 짧은 입력 예시입니다.

백업 파일: shop-sample.backup
백업 기준 시점: 2026-10-01 00:00 KST
복구 대상: 비어 있는 연습용 데이터베이스
확인 표: customers, orders
성공 기준: 대표 주문 조회와 고객 연결 확인
중단 기준: 운영 주소 발견, 권한 오류, 예상 밖 삭제 요청

이 메모에서 대상이 비어 있는 시험 환경인지 설명할 수 없다면 실행하지 않습니다. 특히 --clean 옵션은 복구 전에 대상 객체를 지울 수 있고, --create와 함께 쓰면 데이터베이스를 다시 만들 수 있으므로 의미와 대상을 모른 채 복사해 실행하면 안 됩니다.

복구 뒤에는 데이터와 관계와 권한을 함께 본다

명령이 오류 없이 끝났다는 사실만으로 충분하지 않습니다. 필요한 표가 있는지, 대표 행이 읽히는지, 주문이 고객과 올바르게 연결되는지, 날짜와 한글이 깨지지 않았는지 확인합니다. 예상 행 수는 정확한 기준 시점과 비교하고, 결제 합계처럼 중요한 값은 미리 정한 표본으로 대조합니다.

권한도 확인해야 합니다. 복구한 사용자가 지나치게 많은 표를 수정할 수 있거나 애플리케이션 계정이 필요한 표를 읽지 못하면 서비스는 정상으로 돌아오지 않습니다. PostgreSQL 문서도 SQL 덤프를 되살리기 전에 원래 객체 소유자와 권한 대상 사용자가 존재해야 할 수 있다고 안내합니다. 확장 기능, 예약 작업, 외부 파일처럼 덤프 밖에 있는 의존성도 별도 목록으로 점검합니다.

복구 기록은 다음 사고의 안내서가 된다

훈련 날짜, 사용한 백업, 시작과 종료 시각, 만난 오류, 확인한 표, 남은 문제를 기록합니다. 백업 파일 크기만 늘어나는지 보는 감시와 실제 복구 훈련은 서로 다른 점검입니다. 정기 백업이 성공해도 최근 복구 훈련이 계속 실패한다면 안전하다고 표시할 수 없습니다.

복구에 걸린 시간은 다음 계획을 현실적으로 만드는 자료가 됩니다. 다만 작은 시험 자료의 시간을 운영 데이터에 그대로 곱해 예상하지 않습니다. 데이터 양, 네트워크, 인덱스 생성, 동시 작업에 따라 달라질 수 있으므로 실제 환경과 비슷한 조건에서 승인된 훈련을 별도로 설계합니다.

비밀키와 결제와 삭제 경계를 지킨다

데이터베이스 주소, 사용자 이름, 비밀번호, 암호화 키를 문서나 AI 대화에 붙이지 않습니다. 고객 개인정보와 결제 자료가 든 실제 백업을 개인 노트북이나 온라인 변환기에 올리지 말고, 조직의 승인된 저장 위치와 접근 기록을 사용합니다. 실습용 데이터에는 실제 사람의 값을 복사하지 않습니다.

복구 명령은 새 자료를 추가하거나 기존 객체를 지울 수 있습니다. dropdb, DROP, --clean, 덮어쓰기 옵션처럼 삭제가 포함된 동작은 대상, 영향, 승인자, 되돌릴 방법을 모두 설명할 수 있을 때만 실행합니다. 운영 주소인지 시험 주소인지 확신이 없거나 저장 공간과 비용 영향을 모르면 멈추고 담당자에게 확인하세요.

오늘 바로 해볼 작은 실습

데이터베이스 명령을 실행하지 않고 10분 동안 종이 복구 훈련표를 만듭니다.

1. 연습용 서비스 하나를 정하고 잃어버리면 안 되는 표 두 개를 적습니다.
2. 백업 파일 이름, 생성 시점, 제품 버전, 저장 위치를 적을 칸을 만듭니다.
3. 운영과 분리된 빈 시험 환경의 이름과 확인 담당자를 적습니다.
4. 복구 뒤 확인할 대표 데이터, 표 관계, 권한을 각각 하나 고릅니다.
5. 운영 주소 발견, 비밀키 노출, 삭제 옵션 발견을 중단 조건으로 씁니다.
6. 성공과 실패를 기록할 시작 시각, 종료 시각, 오류 칸을 만듭니다.
7. 실제 비밀번호, 고객 이름, 결제 값은 적지 않았는지 다시 봅니다.
8. 복원, 삭제, 덮어쓰기 명령은 이번 실습에서 실행하지 않습니다.

완성된 표에서 “어느 백업을 어디에 되살리고 무엇을 확인해야 성공인가”를 한 문장으로 말할 수 있으면 첫 준비가 된 것입니다. 실제 복구 훈련은 데이터베이스 담당자와 빈 시험 환경을 확인한 뒤, 사용하는 제품과 버전의 공식 절차를 따라 별도로 진행하세요.