워드프레스 백업과 복원은 장애가 난 뒤 파일을 찾는 작업이 아니라, 평소에 복구 가능성을 확인하는 운영 체계입니다. 업데이트 실패, 플러그인 충돌, 해킹, 서버 장애, 관리자 실수는 예고 없이 생길 수 있습니다. 백업 파일이 존재해도 범위가 빠졌거나 암호를 잃었거나 복원 절차를 모르면 실제 사고 때 사용할 수 없습니다.
완전한 워드프레스 백업에 포함할 것
워드프레스 사이트는 크게 파일과 데이터베이스로 나뉩니다. 둘 중 하나만 저장하면 원래 상태를 완전하게 복원하기 어렵습니다. WordPress 공식 백업 문서도 파일과 데이터베이스를 함께 백업해야 한다고 안내합니다.
| 구성 요소 | 주요 내용 | 빠졌을 때 생길 수 있는 문제 |
|---|---|---|
| 데이터베이스 | 글, 페이지, 댓글, 사용자, 설정 | 최신 콘텐츠와 설정을 복원하지 못함 |
| wp-content | 테마, 플러그인, 업로드 이미지 | 디자인·기능·미디어가 사라짐 |
| 핵심 설정 파일 | wp-config.php, 서버 설정 | 데이터베이스 연결과 보안 설정 누락 |
| 운영 정보 | 도메인, DNS, 호스팅, 관리자 접근 | 복원 후 사이트 연결과 접근이 지연됨 |
백업 방식 선택: 호스팅, 플러그인, 수동 백업
하나의 방식이 모든 사이트에 맞지는 않습니다. 호스팅 백업은 서버 전체 복구가 편리하지만 보관 기간과 다운로드 가능 여부를 확인해야 합니다. 플러그인 백업은 WordPress 관리자에서 일정과 원격 저장소를 설정하기 쉽지만, 사이트가 완전히 열리지 않을 때 복원 방법을 미리 알아야 합니다. 수동 백업은 통제 범위가 넓지만 파일과 데이터베이스를 빠뜨리지 않을 지식이 필요합니다.
- 호스팅 백업: 자동 생성 주기, 보관 개수, 복원 비용, 서버 밖 다운로드 가능 여부를 확인합니다.
- 백업 플러그인: 전체 파일 포함 여부, 원격 저장소 연결, 암호화, 실패 알림을 확인합니다.
- 수동 백업: 파일 관리자 또는 SFTP와 데이터베이스 내보내기 절차를 문서화합니다.
중요한 사이트라면 한 방식에만 의존하지 말고 호스팅 자동 백업과 별도 원격 사본처럼 독립된 경로를 조합하는 편이 좋습니다.
사이트 변화량으로 백업 주기를 정한다
주기는 사이트 규모보다 ‘잃어도 되는 데이터의 양’으로 정합니다. 하루에 글 한 편과 댓글이 여러 개 추가된다면 일주일 전 데이터로 돌아가는 손실을 감수하기 어렵습니다. 반대로 거의 바뀌지 않는 정보형 사이트는 주간 전체 백업과 변경 직전 수동 백업을 조합할 수 있습니다.
| 사이트 변화 | 권장 시작점 | 추가 시점 |
|---|---|---|
| 변화가 적은 개인 블로그 | 주간 전체 백업 | 업데이트·테마 수정 직전 |
| 댓글과 글이 자주 추가됨 | 일간 데이터베이스, 주간 전체 | 대량 편집 직전 |
| 회원·주문·예약 데이터가 있음 | 변화량에 맞춘 더 짧은 간격 | 배포와 설정 변경 직전 |
| 개발·테스트 중인 사이트 | 작업 단위 스냅샷 | 플러그인·코드 변경 직전 |
이 표는 출발점입니다. 실제 주기는 저장 공간, 복원 목표, 데이터 중요도, 호스팅 기능을 함께 고려해 조정하세요.
3-2-1 원칙으로 보관 위치를 분리한다
널리 쓰이는 3-2-1 원칙은 데이터 사본을 3개 유지하고, 2가지 서로 다른 저장 매체에 보관하며, 1개는 사이트 서버와 다른 위치에 두는 방식입니다. 모든 소규모 블로그가 정확히 같은 구성을 갖출 필요는 없지만 원본 서버 안에만 백업을 두는 것은 피해야 합니다.
- 운영 서버의 자동 백업
- 다른 클라우드 저장소 또는 로컬 암호화 사본
- 중요 변경 전 별도로 표시한 장기 보관본
서버가 손상되거나 호스팅 계정이 잠기면 같은 계정 안의 백업에도 접근하지 못할 수 있습니다. 원격 저장소 계정에는 다단계 인증을 켜고 복구 코드를 별도로 보관하세요.
백업 파일 이름과 보관 정책
파일 이름만 보고 사이트, 생성 시각, 백업 범위, 환경을 식별할 수 있어야 합니다. 예를 들어 사이트명-운영환경-전체-날짜 형식처럼 일관된 규칙을 사용하세요. ‘backup-final.zip’ 같은 이름은 여러 사본이 쌓였을 때 어떤 파일이 최신인지 알기 어렵습니다.
일간 백업은 최근 7개, 주간 백업은 최근 4개, 월간 백업은 몇 개처럼 계층적으로 보관하면 저장 공간과 복구 지점을 함께 관리할 수 있습니다. 단, 삭제 주기는 자동화하기 전에 최소 한 달 동안 생성·복원 기록을 확인하는 것이 안전합니다.
백업 완료 알림만 믿으면 안 되는 이유
완료 알림은 작업이 실행됐다는 뜻일 뿐입니다. 업로드 폴더 일부가 제외됐거나 데이터베이스 파일이 비어 있거나 원격 저장소 업로드가 실패할 수 있습니다. 다음 항목을 정기적으로 확인하세요.
- 파일 크기가 이전 백업과 비교해 비정상적으로 작지 않은가?
- 압축 파일이 열리고 예상 폴더와 파일이 들어 있는가?
- 데이터베이스 내보내기 파일에 테이블과 데이터가 있는가?
- 원격 저장소에서 실제 다운로드가 가능한가?
- 백업 암호와 저장소 복구 수단을 확인할 수 있는가?
- 실패 알림이 운영자가 보는 주소로 전달되는가?
WordPress 공식 데이터베이스 백업 안내에는 phpMyAdmin, 명령줄, 플러그인 등 여러 방법이 소개되어 있습니다. 익숙하지 않은 도구를 운영 사이트에서 바로 시험하기보다 호스팅 문서와 테스트 환경을 먼저 이용하세요.
복원 전 결정해야 할 두 가지 목표
복구 시점 목표(RPO)는 얼마만큼의 최근 데이터를 잃을 수 있는지를 뜻하고, 복구 시간 목표(RTO)는 서비스를 얼마 동안 중단할 수 있는지를 뜻합니다. 전문 용어가 부담스럽다면 ‘어느 시점까지 되돌아가야 하나’와 ‘몇 시간 안에 다시 열어야 하나’로 생각하면 됩니다.
이 두 목표가 백업 빈도와 방식에 직접 영향을 줍니다. 하루치 댓글 손실도 허용하기 어렵다면 일주일에 한 번 백업으로는 부족합니다. 한 시간 안에 복원해야 하는데 수동 복원에 익숙하지 않다면 호스팅의 원클릭 복원과 지원 범위를 사전에 확인해야 합니다.
안전한 복원 순서
- 현재 상태 보존: 장애가 난 파일과 데이터베이스도 별도로 저장합니다. 원인 분석과 누락 데이터 복구에 필요할 수 있습니다.
- 복원 지점 선택: 장애 발생 시각보다 이전이면서 필요한 데이터 손실이 가장 적은 백업을 고릅니다.
- 방문자 영향 최소화: 필요하면 유지보수 안내를 표시하고 주문·댓글·편집 같은 쓰기 작업을 중지합니다.
- 파일과 데이터베이스 시점 맞추기: 서로 다른 시점의 사본을 섞으면 플러그인 버전과 설정이 맞지 않을 수 있습니다.
- 캐시 초기화: 서버, 플러그인, CDN 캐시가 이전 화면을 보여주지 않도록 갱신합니다.
- 기능 검증: 로그인, 글, 이미지, 검색, 댓글, 예약 작업, 오류 로그를 확인합니다.
복원 중 오류가 나면 같은 작업을 반복하기보다 로그와 오류 문구를 기록하고 호스팅 지원팀에 전달하세요. 데이터베이스 연결 정보나 비밀번호는 공개 게시판에 올리지 마세요.
복원 후 확인할 기능 체크리스트
- 홈과 주요 글이 로그인하지 않은 상태에서도 열리는가?
- 관리자 로그인과 글 저장이 정상인가?
- 대표 이미지와 본문 이미지가 빠지지 않았는가?
- 메뉴, 카테고리, 고정주소가 이전과 같은가?
- 댓글, 검색, 문의 폼 등 입력 기능이 동작하는가?
- 예약 글, 자동 백업, 보안 검사 같은 예약 작업이 재개됐는가?
- SSL 인증서와 HTTPS 주소가 정상인가?
- 브라우저 콘솔과 서버 오류 로그에 새 오류가 없는가?
고정주소가 예상과 다르면 바로 구조를 변경하기보다 현재 설정과 캐시를 먼저 확인하세요. 관련 기준은 워드프레스 고정주소 설정 가이드에서 확인할 수 있습니다.
스테이징에서 복원 테스트하는 방법
복원 테스트는 운영 사이트에 덮어쓰지 않고 별도의 스테이징 환경에서 진행하는 것이 안전합니다. 호스팅이 스테이징 기능을 제공한다면 새 환경을 만들고 백업을 복원한 뒤 주요 기능을 점검하세요. 스테이징 사이트는 검색엔진에 노출되지 않도록 접근 제한과 검색 차단을 확인해야 합니다.
테스트 기록에는 사용한 백업 날짜, 복원 시작·완료 시각, 누락된 파일, 오류, 수정한 절차를 남깁니다. 분기마다 한 번 또는 백업 방식이 바뀔 때 다시 연습하면 실제 장애에서 당황하지 않습니다.
자동 백업 플러그인 선택 기준
- 현재 WordPress와 PHP 버전을 지원하는가?
- 파일과 데이터베이스를 모두 포함하는가?
- 원격 저장소를 지원하고 전송 암호화를 사용하는가?
- 증분 백업 또는 큰 사이트 분할 백업을 지원하는가?
- 실패 알림과 작업 로그를 제공하는가?
- 관리자 접속이 불가능할 때 복원하는 문서가 있는가?
- 무료·유료 버전의 복원 제한이 명확한가?
백업 플러그인을 여러 개 같은 시간에 실행하면 CPU, 디스크, 데이터베이스 부하가 겹칠 수 있습니다. 하나를 주 백업 도구로 정하고 호스팅 백업과 시간을 겹치지 않게 조정하세요. 충돌이 의심될 때는 플러그인 충돌 진단 순서에 따라 확인합니다.
보안 사고에서는 깨끗한 복원이 중요하다
해킹이 의심되는 상황에서 단순히 이전 백업을 복원하면 침입 경로나 감염 파일이 그대로 남을 수 있습니다. 관리자·호스팅·데이터베이스 계정 비밀번호를 안전한 기기에서 변경하고, 알 수 없는 관리자 계정과 파일을 확인하며, WordPress 핵심·테마·플러그인을 신뢰할 수 있는 출처의 최신 버전으로 준비해야 합니다.
WordPress 공식 해킹 복구 안내를 참고하고, 원인을 판단하기 어렵다면 호스팅 또는 보안 전문가의 도움을 받으세요. 감염된 상태의 데이터와 로그는 조사 전에 무작정 삭제하지 않는 편이 좋습니다.
월간 백업 운영표
| 주기 | 할 일 | 남길 기록 |
|---|---|---|
| 매일 또는 정한 주기 | 자동 백업 성공 여부 확인 | 완료 시각, 실패 알림 |
| 매주 | 원격 저장소 사본과 파일 크기 확인 | 백업 위치, 크기 변화 |
| 매월 | 보관 정책과 접근 권한 점검 | 삭제된 사본, 계정 접근 |
| 분기 또는 방식 변경 시 | 스테이징 복원 테스트 | 복원 시간, 누락 기능, 개선점 |
WordPress 공식 사이트 유지관리 문서도 백업을 정기적인 운영 일정에 포함하도록 안내합니다.
최종 체크리스트
- 파일과 데이터베이스가 모두 포함되어 있는가?
- 운영 서버 밖에 최소 한 사본이 있는가?
- 백업 파일을 실제로 내려받고 열어 보았는가?
- 백업 주기가 허용 가능한 데이터 손실 범위와 맞는가?
- 복원 순서와 필요한 계정 정보를 안전하게 기록했는가?
- 스테이징에서 복원 테스트를 했는가?
- 복원 후 확인할 기능 목록이 있는가?
- 자동 백업 실패 알림을 실제로 확인하는가?
워드프레스 백업의 품질은 파일 개수가 아니라 복원 가능성으로 판단합니다. 자동화를 설정하고 끝내지 말고 외부 보관, 접근 권한, 복원 연습, 기능 검증까지 하나의 절차로 관리하세요.