백업 파일이 있어도 복구에 실패하는 이유: 개인 웹사이트 백업·복구 점검법

👤 인스피

조회 수 9

1. 코드 백업과 데이터 백업은 다르다

프로젝트 코드에는 게시판을 보여주는 로직과 화면 템플릿이 들어 있습니다. 하지만 실제 게시글이 외부 데이터베이스에 저장되어 있다면 코드 폴더를 복사해도 게시글 데이터까지 복사되지는 않습니다. 업로드 폴더를 Git에서 제외했다면 저장소를 복제할 때 이미지도 따라오지 않습니다.

반대로 데이터베이스만 복원해도 프로그램이 자동으로 실행되는 것은 아닙니다. 어떤 코드 버전이 해당 데이터 구조와 호환되는지, 실행에 필요한 설정을 어디서 가져오는지 알아야 합니다. 백업 범위를 정할 때는 파일 확장자보다 자료가 저장되는 위치를 기준으로 구분하세요.

대상	담긴 정보	복구 때 필요한 확인
소스 코드·템플릿	화면과 처리 로직	동작했던 버전·실행 명령
데이터베이스	글·댓글·회원·파일 경로	스키마·데이터·권한
업로드 파일	본문 이미지·첨부 자료	실제 파일과 DB 경로의 일치
실행 설정	DB 연결·저장소·외부 서비스 설정	안전한 보관 위치·복원 방법
운영 메모	도메인·배포·복구 순서	장애 때 바로 따라 할 수 있는가?

이 표를 자신의 사이트에 맞춰 채우면 백업 목록을 만들 수 있습니다. 외부 파일 저장소를 쓴다면 버킷과 경로도 기록하고, 데이터베이스 자동 백업이 파일 저장소까지 포함하는지는 서비스 안내에서 따로 확인하세요. “클라우드에 있다”는 사실과 “내가 원하는 시점으로 복원할 수 있다”는 사실은 다릅니다.

2. 백업 성공을 세 단계로 나눠 확인하기

백업 확인은 파일 생성, 자료 확인, 서비스 확인으로 나눌 수 있습니다. 첫 단계는 백업 작업이 종료되고 결과 파일이 생겼는지 확인하는 것입니다. 두 번째는 그 파일이 읽히고 필요한 자료를 포함하는지 확인하는 것입니다. 마지막은 자료를 별도 환경에 복원해 기능이 동작하는지 확인하는 것입니다.

파일 단계: 작업 종료 상태, 파일 존재, 크기, 압축 검사 결과를 확인합니다.
자료 단계: 표본 게시글, 댓글 관계, 이미지·첨부 파일의 존재를 확인합니다.
서비스 단계: 목록·본문·로그인·검색 등 필요한 동작을 확인합니다.

파일 크기만 확인하면 빈 백업을 놓칠 수 있고, 압축 검사만 통과해도 필요한 이미지가 빠졌을 수 있습니다. DB의 행 수가 맞아도 글과 첨부 자료의 연결이 틀릴 수 있습니다. 각 단계의 결과를 따로 기록해야 원인을 찾기 쉽습니다.

운영자가 정한 완료 조건도 구체적이어야 합니다. “서버 실행 성공”보다 “최신 글과 예전 글 각각 한 편이 열리고, 본문 이미지가 표시되며, 테스트 계정으로 로그인할 수 있음”처럼 실제 이용 동작으로 적어두세요.

3. 실제 실습: ZIP이 정상이지만 이미지가 빠진 경우

실습용 DB에는 게시글 세 개와 각각의 이미지 경로를 저장했습니다. 이미지는 DB 안에 넣지 않고 uploads/a.png, uploads/b.png, uploads/c.png라는 별도 파일로 만들었습니다. DB 사본은 SQLite의 Connection.backup()으로 생성했습니다.[1]

이 자료로 세 가지 ZIP을 만들었습니다. 하나는 DB만, 두 번째는 DB와 이미지 두 장, 마지막은 DB와 이미지 세 장을 포함했습니다. 각 ZIP의 DB와 포함된 이미지를 새로운 폴더에 복원한 뒤, DB를 열어 게시글 수를 읽고 이미지 경로의 파일 존재 여부를 확인했습니다.

백업 구성	ZIP 검사	복원된 글	포함 이미지	누락 이미지
DB만 포함	통과	3개	0장	3장
DB + 이미지 2장	통과	3개	2장	1장
DB + 이미지 3장	통과	3개	3장	0장

ZIP 검사는 세 경우 모두 통과했지만 이미지 누락은 각각 3장, 1장, 0장으로 나타난 복구 실험 결과

실습에서 확인한 결과를 직접 제작한 도표로 정리했습니다. 실제 운영 서버의 화면이나 장애 기록은 아닙니다.

세 파일 모두 Python의 ZipFile.testzip() 검사에 통과했습니다. 이 함수는 아카이브에 들어 있는 파일의 CRC와 헤더를 검사합니다. 정상일 때 None을 반환하지만, 애플리케이션에 필요한 파일이 전부 포함되었는지는 판단하지 않습니다.[2]

즉 “압축 파일이 손상되지 않았다”와 “사이트 복구에 필요한 자료가 모두 있다”는 별개입니다. 이 실습은 파일과 DB의 연결을 확인한 것이며, 웹 서버·로그인·외부 서비스 연결까지 복구한 시험은 아닙니다. 마지막 구성에서 이미지 누락이 없었다고 전체 서비스 복구가 검증된 것은 아닙니다.

4. DB와 파일의 백업 시점을 맞추기

실제 사이트에서는 백업 중에도 새 글과 이미지가 올라올 수 있습니다. DB 사본에는 새 글의 이미지 경로가 들어갔지만 파일 사본에는 이미지가 아직 없을 수도 있습니다. 반대 순서라면 이미지는 있는데 DB가 그 글을 모를 수 있습니다.

그래서 백업 묶음에는 DB 백업 시간과 파일 복사 시간을 함께 적는 편이 좋습니다. 소규모 사이트라면 쓰기 작업을 잠시 제한한 유지보수 시간에 묶음을 만들 수 있습니다. 계속 운영해야 한다면 저장소 스냅샷, 버전 관리, 파일 보존 정책 등을 자신의 환경에 맞게 설계해야 합니다.

PostgreSQL의 pg_dump는 DB 안의 일관된 내보내기를 제공하지만, 애플리케이션이 별도로 저장한 서버 이미지 폴더까지 함께 묶어주지는 않습니다.[3] 데이터베이스의 일관성과 사이트 전체 자료의 일관성을 같은 의미로 보지 마세요.

복구 기록에는 백업 시점 이후에 생성된 자료가 어디까지 포함되는지도 적어두세요. 최신 백업이 어제 것이라면 오늘 작성된 글을 복구할 수 있는 별도 방법이 있는지 확인해야 합니다. 백업 간격은 감당할 수 있는 자료 손실 범위에 맞춰 결정하는 것이 합리적입니다.

5. PostgreSQL 백업 예제를 읽는 방법

다음 명령은 접속 설정이 준비된 환경에서 site_db라는 데이터베이스를 custom 형식으로 내보내는 예제입니다. 파일 이름과 DB 이름은 설명용이며, 실제 환경의 연결 방식·버전·권한에 맞춰 바꿔야 합니다.

pg_dump -Fc -f site-2026-10-01.dump site_db

-Fc는 custom 아카이브 형식, -f는 결과 파일을 지정합니다. pg_dump는 단일 데이터베이스를 대상으로 합니다. 공통 역할과 테이블스페이스처럼 클러스터 차원의 자료는 별도 검토가 필요합니다.[3]

생성한 custom 아카이브의 항목 목록은 다음과 같이 확인할 수 있습니다.

pg_restore --list site-2026-10-01.dump

목록 확인은 형식과 구성 항목을 살펴보는 단계이며 실제 복구 성공을 증명하지 않습니다. 공식 문서에 따라 준비한 별도의 빈 테스트 DB에 복원하고 결과를 확인해야 합니다.[4]

# 별도로 준비한 빈 테스트 DB에 복원하는 예제
pg_restore --exit-on-error --dbname=site_restore_test site-2026-10-01.dump

위 명령은 site_restore_test가 이미 만들어져 있다는 전제입니다. 원본 역할·확장 기능·소유권 등 복구 전제도 맞아야 합니다. 평문 SQL 덤프는 같은 방식이 아니므로 파일 형식과 복원 도구를 구분하세요.[4]

이 예제만으로 모든 운영 DB의 백업 정책이 완성되지는 않습니다. 데이터 크기, 변경량, 복구 시점 요구에 따라 파일 시스템 백업이나 지속적 아카이빙 등 다른 전략이 필요할 수 있습니다. PostgreSQL 공식 문서도 여러 백업 방식을 별도로 설명합니다.[5]

6. 운영 환경과 분리해서 복구 시험하기

첫 복구 시험은 운영 데이터베이스를 덮어쓰는 대신 새 DB와 별도 파일 폴더에서 진행하세요. 애플리케이션의 연결 설정도 테스트 대상으로 바꿉니다. 그렇지 않으면 복구가 잘 된 것처럼 보여도 실제로는 운영 DB를 읽고 있을 수 있습니다.

외부 서비스 연결도 구분해야 합니다. 테스트 서버가 실제 이메일을 보내거나 운영 저장소에 파일을 쓰지 않도록 설정을 확인하세요. 로그인 상태를 공유하는 쿠키나 외부 콜백 주소가 있다면 테스트 환경에서 예상대로 동작하는지도 점검합니다.

복구 대상 DB·파일 저장 위치가 운영 환경과 분리되어 있는지 확인합니다.
백업을 복원하고, 맞는 코드 버전과 실행 환경을 준비합니다.
목록과 표본 게시글을 열어 제목·본문·작성 시각을 확인합니다.
본문 이미지와 첨부 파일의 실제 존재 및 다운로드를 확인합니다.
테스트 계정으로 로그인하고 필요한 읽기·쓰기 기능을 확인합니다.
실행 시간과 발견한 문제를 기록한 뒤 테스트 자료를 정리합니다.

전체 데이터가 많다면 표본 검사와 자동 검사를 함께 사용하세요. 최신 글만 검사하면 예전 경로 체계로 저장된 이미지를 놓칠 수 있습니다. 최근 자료, 오래된 자료, 첨부가 많은 글을 나눠 선택하면 점검 범위를 넓히는 데 도움이 됩니다.

7. 복구 메모에는 무엇을 남길까?

장애가 발생하면 평소 기억하던 작업 순서도 헷갈릴 수 있습니다. 백업 폴더에 복구 메모를 함께 남기되, 공개될 수 있는 문서에는 실제 비밀번호와 API 키를 적지 마세요. 설정 이름과 안전한 보관 위치를 기록하고 값 자체는 별도로 관리하세요.

기록 항목	예시
묶음 식별자	site-backup-2026-10-01-0200
포함 범위	DB 덤프·업로드 폴더·코드 버전
백업 시작·완료 시각	날짜·시각·시간대 함께 기록
실행 조건	Python·DB·주요 라이브러리 버전
복구 순서	DB → 파일 → 설정 → 실행 → 기능 확인
최근 시험 결과	표본 글·이미지·로그인 확인 결과

복구 순서 예시는 출발점일 뿐입니다. 실제로는 DB 확장 기능, 파일 권한, 서비스 설정 등 선행 조건이 달라질 수 있으므로 자신의 서버에서 확인한 순서로 갱신하세요. 자동 배포만 가능하고 복구 실행 방법이 없다면 운영 메모가 아직 충분하지 않은 것입니다.

8. 백업은 원본과 다른 장애 범위에 보관하기

원본과 백업이 같은 디스크에만 있으면 디스크 고장으로 둘 다 사라질 수 있습니다. 항상 연결된 저장소는 잘못된 삭제나 공격의 영향을 함께 받을 수 있습니다. 복사본 개수뿐 아니라 어떤 장애를 따로 견딜 수 있는지 확인해야 합니다.

CISA는 중요한 자료의 오프라인·암호화 백업과 정기적인 복구 시험을 권고합니다.[6] 개인 사이트에서는 별도 저장 위치, 접근 권한 분리, 가능한 경우 변경 불가능한 보존 기능을 검토할 수 있습니다. 실제 저장소 기능과 계정 설정을 확인한 뒤 적용하세요.

암호화된 백업은 복호화에 필요한 키를 확보할 수 있어야 복구됩니다. 보관 위치만 알고 비밀번호나 복구 키를 잃어버리면 백업 파일이 있어도 사용할 수 없습니다. 복구 시험에는 접근 권한과 복호화 절차도 포함하세요.

이전 백업을 곧바로 모두 지우는 정책도 피해야 합니다. 누락이나 잘못된 삭제를 뒤늦게 발견할 수 있기 때문입니다. 일별·주별 등 여러 시점을 어떻게 보관할지는 데이터 변경 빈도와 저장 공간에 맞춰 정하고, 삭제 기준을 문서에 남기세요.

9. 간단한 ZIP 검사 코드와 그 한계

Python 표준 라이브러리만으로 ZIP 내부 검사와 목록 확인을 시작할 수 있습니다. 다음 코드는 압축을 풀지 않고 검사 결과를 출력합니다. 이 검사는 필요한 이미지가 모두 있는지나 서비스가 정상 동작하는지는 확인하지 않습니다.[2]

from pathlib import Path
import zipfile

backup = Path("site-backup.zip")

with zipfile.ZipFile(backup) as archive:
    broken = archive.testzip()
    print("archive check:", "PASS" if broken is None else "FAIL")
    if broken is not None:
        print("first broken member:", broken)
    print("archive members:", len(archive.namelist()))

검사 결과가 PASS이면 다음 단계로 DB 복원과 참조 파일 확인을 진행합니다. 파일 목록에 이미지가 많다고 모든 글의 이미지가 있다고 단정하지 마세요. DB가 참조하는 경로와 복원된 파일을 비교해야 누락을 확인할 수 있습니다.

자주 묻는 질문

Q. GitHub에 코드가 있으면 별도 백업은 필요 없나요?

저장소에 포함되지 않은 DB·업로드 파일·실행 설정은 따로 확보해야 합니다. 저장소를 복제했을 때 실제로 무엇이 따라오는지 확인하는 것이 먼저입니다.

Q. 자동 DB 백업이 있으면 이미지는 신경 쓰지 않아도 되나요?

이미지가 DB 외부에 저장된다면 별도 대상입니다. 백업 서비스의 포함 범위를 확인하고, 파일 경로와 실제 저장 자료를 함께 복구할 수 있는지 시험하세요.

Q. 매일 백업하면 오늘 자료도 복구할 수 있나요?

마지막 백업 이후 생성된 자료는 포함되지 않을 수 있습니다. 필요한 복구 시점을 정한 뒤 백업 간격과 추가 복구 방법을 결정해야 합니다.

Q. ZIP 검사에 통과했는데 왜 복구 실패라고 하나요?

ZIP 검사는 들어 있는 파일의 상태를 확인합니다. 누락된 이미지나 맞지 않는 실행 설정까지 판단하지 않습니다. 실습에서도 세 ZIP 모두 통과했지만 두 구성에서는 이미지가 빠져 있었습니다.

Q. 복구 시간은 파일을 복사하는 시간만 재면 되나요?

서비스를 다시 사용할 수 있는 시점까지 기록하는 편이 유용합니다. DB 복원, 설정 준비, 실행, 기능 확인에 걸린 시간도 포함해야 운영 계획에 사용할 수 있습니다.

Q. 얼마나 자주 복구를 시험해야 하나요?

자료의 중요도와 변경 빈도에 따라 주기를 정하세요. 정기 시험 외에도 저장소 이전, DB 업그레이드, 백업 방식 변경 뒤에는 복구 절차가 여전히 맞는지 확인하는 것이 좋습니다.

다음 백업을 만들 때는 결과 파일 이름만 기록하지 말고, 포함된 자료와 최근 복구 시험 결과도 함께 남겨보세요. 실제로 복원해 본 기록이 있으면 장애 때 필요한 작업과 빠진 항목을 훨씬 구체적으로 판단할 수 있습니다.

참고 자료와 검증 범위

공식 문서 확인일: 2026년 10월 1일. 실습은 임시 SQLite DB의 게시글 세 개와 로컬 PNG 세 장을 대상으로 진행했습니다. ZIP에서 DB와 파일을 별도 폴더에 복원하고 행 수·참조 파일 존재 여부를 확인했습니다. PostgreSQL 운영 복구, 외부 저장소, 인증 기능, 복구 소요 시간은 실습 검증 범위에 포함하지 않았습니다.