WordPress 백업이 오류 없이 끝났다면 무엇까지 안심할 수 있을까요? 2026년 4월 18일의 제 기록에는 파일 크기와 실행 결과가 있었지만 복구 시험 결과는 없었습니다. 이 글은 백업 생성, 자료 확인, 실제 복구를 서로 다른 완료 단계로 읽는 방법을 정리합니다.
2026년 4월 18일 새벽 백업은 약 2분 만에 끝났습니다. 기록에는 데이터베이스 덤프 4.0M, 총 저장 용량 829M, 실행 오류 없음이 남아 있습니다.
당시 일기는 이 결과를 서버가 안전하게 유지된다는 이야기로 이어갔습니다. 지금 그 기록을 다시 읽으면, 성공 보고 옆에 비어 있는 항목이 하나 보입니다. 이 백업으로 실제 복구를 해봤는가입니다.
백업이 실행됐다는 증거는 있었습니다. 하지만 그날 복구 테스트까지 했다는 기록은 없습니다. 이 글은 그 차이에서 출발해, WordPress 백업 결과를 어떻게 읽고 무엇을 추가로 확인해야 할지 정리합니다.
성공 로그가 알려준 것과 알려주지 않은 것
당시 기록된 백업 범위는 데이터베이스 덤프, 사용자 작업 파일, 웹사이트 파일, Nginx 설정, SSL 인증서였습니다. 30일이 지난 백업을 정리하는 절차도 포함되어 있었습니다.
여기서 4.0M과 829M은 원문의 표기 그대로입니다. 바이트 단위로 다시 측정한 값이나 백업 무결성을 입증하는 수치는 아닙니다.
| 기록에서 확인한 사실 | 그 사실만으로 확인할 수 없는 것 |
|---|---|
| 백업 작업이 오류 없이 종료됨 | 필요한 자료가 빠짐없이 포함됐는지 |
| 데이터베이스 덤프가 생성됨 | 다른 환경에서 가져올 수 있는지 |
| 파일과 설정이 백업 범위에 있음 | 데이터베이스와 같은 시점의 상태인지 |
| 총 용량이 기록됨 | 파일 손상 여부와 복구 가능성 |
| 오래된 백업을 정리함 | 최근 백업이 실패했을 때 남을 복구 지점 |
따라서 당시 결과를 가장 정확하게 표현하면 “백업 생성 작업이 성공했다”입니다. “복구가 검증됐다”는 별도의 근거가 필요합니다.
WordPress는 데이터베이스와 파일을 함께 봅니다
WordPress 공식 문서는 일반적인 사이트 복구에 데이터베이스와 파일이 모두 필요하다고 설명합니다. 웹 디렉터리를 복사했다고 데이터베이스까지 백업되는 것은 아닙니다. 글과 설정이 있어도 업로드 이미지나 테마 파일이 없으면 원래 상태를 충분히 되살리지 못할 수 있습니다. WordPress 백업 안내
백업을 확인할 때는 하나의 압축 파일보다, 서로 대응하는 자료 묶음이라는 관점이 유용합니다.
- 어느 사이트와 환경의 백업인지
- 데이터베이스와 파일의 생성 시점이 언제인지
- 복구에 필요한 설정이 어디에 있는지
- 그 자료를 읽을 권한을 어떻게 확보하는지
설정과 인증서 관련 자료에는 비밀값이 들어갈 수 있습니다. 공개 Git 저장소나 블로그 첨부파일에 보관하지 않고, 접근이 제한된 위치에서 관리해야 합니다. 파일 소유자만 읽게 만드는 것과 암호화하는 것도 서로 다른 보호 조치입니다.
다음 백업부터 함께 남길 기록
아래는 이번 사례를 바탕으로 제안하는 점검표입니다. 기존 백업 시스템에 모두 구현되어 있다는 뜻은 아닙니다.
| 항목 | 남길 내용 |
|---|---|
| 생성 | 시작·종료 시각, 작업 성공 여부, 오류 요약 |
| 범위 | DB, 업로드, 테마, 플러그인, 필요한 설정 |
| 무결성 | 파일 목록, 크기, 체크섬과 확인 결과 |
| 보관 | 원본 서버 장애에도 접근할 수 있는 별도 보관 위치 |
| 복구 | 마지막 복구 시험 시각, 사용한 묶음, 확인한 기능 |
| 미확인 | 접근 권한, 외부 연동, 누락 가능성이 있는 항목 |
체크섬이 일치하면 보관한 파일이 바뀌었는지 확인하는 데 도움이 됩니다. 하지만 내용이 올바른 백업인지까지 증명하지는 않습니다. 필요한 테이블이 빠진 덤프도 체크섬은 만들 수 있습니다.
복구 시험은 운영 사이트와 분리합니다
복구 가능성을 확인하려고 운영 서버에 덤프를 덮어쓰면 백업 점검이 새로운 장애가 될 수 있습니다. 먼저 격리된 환경과 시험 범위를 정해야 합니다.
- 복구할 백업 묶음과 목표 시점을 지정합니다.
- 테스트 환경에서 이메일 발송, 예약 작업, 결제 등 외부 동작을 차단합니다.
- 해당 환경의 복구 절차에 따라 파일과 데이터베이스를 복원합니다.
- 홈페이지뿐 아니라 대표 글, 이미지, 관리자 접근, 필요한 설정을 확인합니다.
- 복구에 걸린 시간, 확인하지 못한 기능, 누락된 자료를 기록합니다.
이는 앞으로 수행할 수 있는 시험 절차입니다. 이 글을 위해 복구 시험을 실행한 것은 아닙니다. 데이터베이스를 가져오는 작업 자체도 기존 데이터를 바꿀 수 있으므로 별도 승인과 실행 계획이 필요합니다. WordPress 데이터베이스 복구 안내
복구 시험의 합격선은 무엇으로 정할까요
시험을 계획할 때는 “홈페이지가 열린다”보다 작고 구체적인 확인 대상을 정하는 편이 좋겠습니다. 이번 백업이라면 DB와 웹사이트 파일뿐 아니라 Nginx 설정과 인증서 자료도 목록에 있으므로, 복원할 것과 별도로 다시 설정할 것을 미리 나누겠습니다.
- 자료 선택: 어느 날짜의 DB와 파일을 한 묶음으로 사용할지 식별할 수 있어야 합니다.
- 콘텐츠 대조: 선택한 시점의 대표 글과 첨부 이미지가 서로 맞는지 확인할 대상으로 지정합니다.
- 기능 확인: 관리자 접근과 필요한 설정을 확인하되, 차단한 외부 연동은 통과가 아니라 미시험으로 남깁니다.
- 결과 판정: 시험한 범위만 복구 확인으로 보고하고, 자료 누락이나 권한 문제는 별도 후속 작업으로 기록합니다.
WordPress 공식 백업 문서도 파일과 데이터베이스를 하나의 백업 묶음으로 다루는 관점을 설명합니다. 여기서는 그 자료가 실제로 복원됐다는 새 결과를 추가하지 않았습니다.
새 서버를 준비하는 단계라면 OCI WordPress 구축과 운영 시작 전 점검의 인수 기준으로 연결해 볼 수 있습니다. 백업 보관 위치와 복구 담당자를 정하지 못했다면 설치 완료와 운영 준비 완료를 구분해 두세요.
오래된 백업을 지우기 전에 확인할 것
원문에는 30일 초과 백업 정리가 포함되어 있습니다. 이 기간이 모든 사이트에 적절한 정답은 아닙니다. 문제를 발견하는 데 얼마나 걸리는지, 어느 시점까지 되돌아갈 필요가 있는지에 따라 달라집니다.
특히 새 백업이 실패했는데 날짜만 보고 오래된 묶음을 지우는 흐름은 피해야 합니다. 보관 기간뿐 아니라 마지막으로 확인된 복구 지점이 남아 있는지도 살펴야 합니다.
새벽에 자동으로 생성된 파일은 중요합니다. 다만 다음 성공 보고에는 파일 크기 옆에 “마지막 복구 시험”을 함께 적으려고 합니다. 아직 시험하지 않았다면 미실시라고 쓰는 편이, 안전하다는 막연한 문장보다 다음 행동을 정하기 쉽습니다.
사례 기준일: 2026-04-18. 당시 백업 작업 기록을 2026-09-03에 재구성했습니다. 백업 생성 기록과 복구 검증은 별개이며, 이 글은 복구 성공을 주장하지 않습니다.
편집 보완: 2026-09-10. 당시 경험과 기록은 유지하고 읽기 흐름과 판단 기준을 보강했습니다. 이번 편집을 위해 새로운 실행·측정·복구 시험을 수행하지 않았습니다.