워드프레스 백업제 제대로 고르는 방법: 복구까지 되는 구성으로 잡기
백업은 저장보다 복구가 먼저입니다
얼마 전 오래된 쇼핑몰 하나를 점검했는데, 백업 플러그인은 깔려 있었지만 복구 테스트를 한 번도 안 해본 상태였습니다. 관리자 화면에는 “백업 완료”라고 떠 있었고 파일도 쌓여 있었습니다. 그런데 막상 테스트 서버에 복원하려고 하니 데이터베이스 파일이 빠져 있었습니다. 이런 경우가 제일 위험합니다. 백업을 했다고 생각했는데, 사고가 난 뒤에야 못 쓰는 백업이었다는 걸 알게 됩니다.
워드프레스에서 백업제, 그러니까 백업 플러그인이나 백업 서비스를 고를 때는 기능 목록보다 먼저 봐야 할 게 있습니다. 파일과 데이터베이스를 따로 백업하는지, 외부 저장소로 보내는지, 자동 실행이 되는지, 그리고 복구 과정이 현실적으로 쉬운지입니다. 사이트가 죽은 상태에서는 관리자 화면에 접속하지 못할 수도 있습니다. 그때 플러그인 안에서만 복구되는 구조라면 생각보다 곤란해집니다.
저는 운영 사이트 기준으로 최소 3가지를 봅니다. 첫째, 데이터베이스 백업이 빠지지 않아야 합니다. 둘째, 백업 파일이 같은 서버 안에만 있으면 안 됩니다. 셋째, 한 달에 한 번이라도 복구 테스트가 가능해야 합니다. 이 3개가 안 되면 이름이 유명한 백업제라도 운영용으로는 불안합니다.
백업 범위를 먼저 나누세요
워드프레스 백업은 크게 파일 백업과 데이터베이스 백업으로 나뉩니다. 파일에는 테마, 플러그인, 업로드 이미지, 커스텀 코드가 들어갑니다. 데이터베이스에는 글, 페이지, 댓글, 상품, 주문, 회원 정보, 설정값이 들어갑니다. 블로그라면 데이터베이스가 더 중요하고, 쇼핑몰이라면 둘 다 절대 빠지면 안 됩니다.
초보자가 자주 하는 실수는 업로드 폴더만 복사해두고 백업이 끝났다고 생각하는 겁니다. 이미지는 살아 있어도 글과 설정이 날아가면 사이트는 정상 복구가 안 됩니다. 반대로 데이터베이스만 백업해두고 업로드 파일이 없으면 글은 보이지만 이미지가 깨집니다. 그래서 백업제 설정 화면에서 “파일”, “데이터베이스”, “업로드”, “테마”, “플러그인” 항목이 각각 어떻게 체크되어 있는지 직접 확인해야 합니다.
- 개인 블로그: 데이터베이스 매일 1회, 파일 주 1회 정도면 대체로 충분합니다.
- 기업 소개 사이트: 데이터베이스 주 2~3회, 파일 주 1회 구성이 무난합니다.
- 쇼핑몰·예약 사이트: 데이터베이스 최소 매일 1회, 주문이 많으면 더 짧게 잡아야 합니다.
- 개발 작업 중인 사이트: 큰 수정 전 수동 백업을 따로 만들어야 합니다.
백업 주기는 방문자 수보다 변경 빈도에 맞추는 게 맞습니다. 하루 방문자가 많아도 글을 거의 안 쓰는 사이트와, 방문자는 적어도 주문이나 문의가 계속 들어오는 사이트는 위험도가 다릅니다. 특히 우커머스 주문 데이터는 몇 시간만 날아가도 실제 돈 문제가 됩니다.
무료 백업제로 충분한 경우와 부족한 경우
무료 백업제로도 운영 가능한 사이트는 많습니다. 예를 들어 작은 블로그, 회사 소개 사이트, 포트폴리오 사이트는 UpdraftPlus 무료 버전이나 호스팅사 자동 백업만으로도 꽤 버틸 수 있습니다. 다만 조건이 있습니다. 백업 파일을 외부 저장소로 보내야 하고, 복구 절차를 한 번은 직접 확인해야 합니다.
무료 플러그인을 쓸 때는 자동 백업 시간도 신경 써야 합니다. 방문자가 많은 낮 시간에 전체 백업을 돌리면 서버 자원을 많이 먹습니다. 저가형 공유 호스팅에서는 백업 도중 사이트가 느려지거나 500 오류가 날 수 있습니다. 보통 새벽 3시에서 5시 사이처럼 접속이 적은 시간에 맞추는 편이 낫습니다.
유료 백업제가 필요한 경우도 분명히 있습니다. 사이트 매출이 직접 발생하거나, 회원 정보가 많거나, 담당자가 직접 복구하기 어려운 경우입니다. 이때는 백업 기능보다 복구 지원, 증분 백업, 실시간 백업, 마이그레이션 기능을 봐야 합니다. 증분 백업은 매번 전체 파일을 새로 저장하지 않고 바뀐 부분만 저장하는 방식이라 서버 부담이 줄어듭니다. 쇼핑몰처럼 이미지와 주문 데이터가 계속 쌓이는 사이트에서는 차이가 큽니다.
제가 자주 쓰는 선택 기준
- 예산이 거의 없는 블로그: 무료 백업 플러그인과 외부 저장소 조합
- 작은 회사 사이트: 호스팅 자동 백업과 플러그인 백업을 함께 사용
- 쇼핑몰: 실시간 또는 짧은 주기의 데이터베이스 백업 지원 서비스
- 개발자가 없는 사이트: 복구 버튼이 단순하고 문서가 많은 백업제
솔직히 무료로 되는 일에 처음부터 유료를 권할 필요는 없습니다. 다만 무료 구성이면 운영자가 직접 확인해야 할 일이 늘어납니다. 유료는 기능값이라기보다 사고 났을 때 시간을 사는 비용에 가깝습니다.
같은 서버에만 저장하면 백업이 아닙니다
백업 파일을 워드프레스 안에만 저장하는 설정은 편하지만 위험합니다. 서버 디스크가 망가지거나 계정이 정지되거나 악성코드가 전체 폴더를 건드리면 백업 파일까지 같이 죽습니다. 실제로 해킹된 사이트를 열어보면 백업 압축 파일까지 감염되거나 삭제된 경우가 꽤 있습니다.
기본 원칙은 간단합니다. 운영 서버와 다른 곳에 하나 더 보관해야 합니다. 클라우드 저장소, 호스팅사 백업, 로컬 다운로드 중 최소 하나는 있어야 합니다. 가능하면 2곳이 좋습니다. 백업 파일은 오래 쌓아두기보다 최근 7일, 최근 4주, 최근 3개월처럼 단계적으로 보관하는 방식이 관리하기 쉽습니다.
- 최근 7일: 매일 백업 보관
- 최근 4주: 주간 백업 보관
- 최근 3개월: 월간 백업 보관
이렇게 해두면 어제 실수로 삭제한 글도 살릴 수 있고, 2주 전에 들어온 악성코드도 피해서 복원할 가능성이 생깁니다. 백업이 너무 최근 것만 있으면 감염된 상태 그대로 저장되어 있을 수 있습니다. 반대로 너무 오래된 것만 있으면 복구 후 다시 입력해야 할 데이터가 많아집니다.
복구 테스트는 꼭 한 번 해야 합니다
백업제가 잘 돌아가는지 확인하는 가장 확실한 방법은 복구 테스트입니다. 운영 사이트에 바로 복원하지 말고 테스트용 하위 설치나 임시 서버에서 해보는 게 안전합니다. 이 과정에서 압축 파일이 정상인지, 데이터베이스가 깨지지 않았는지, 이미지 경로가 살아 있는지 확인할 수 있습니다.
복구 테스트를 할 때는 첫 화면만 보고 끝내면 안 됩니다. 관리자 로그인, 글 목록, 미디어 라이브러리, 문의 폼, 결제 페이지까지 봐야 합니다. 쇼핑몰이라면 테스트 주문까지 넣어보는 게 좋습니다. 백업 파일은 정상인데 특정 플러그인 설정이 빠져서 폼이 안 가는 경우도 있습니다.
특히 캐시 플러그인, 보안 플러그인, 멤버십 플러그인은 복구 뒤에 설정 충돌을 만들 수 있습니다. 복원 후 흰 화면이 뜨면 플러그인 폴더 이름을 바꿔서 전체 비활성화한 뒤 하나씩 켜는 방식으로 원인을 찾습니다. 이 작업을 운영 서버에서 처음 겪으면 손이 떨립니다. 미리 테스트해두면 사고가 났을 때 판단이 훨씬 빨라집니다.
업데이트 전 백업 규칙을 고정하세요
워드프레스 사고는 대부분 업데이트를 너무 오래 미뤘거나, 반대로 백업 없이 바로 눌렀을 때 생깁니다. 코어, 테마, 플러그인 업데이트 전에는 수동 백업을 하나 만들어두는 습관이 필요합니다. 자동 백업이 있어도 큰 업데이트 전에는 별도 백업을 남기는 편이 안전합니다.
제가 운영 사이트에 잡는 기본 순서는 이렇습니다. 먼저 전체 백업을 만들고, 백업 파일이 외부 저장소에 올라갔는지 확인합니다. 그다음 플러그인을 하나씩 업데이트합니다. 여러 개를 한 번에 누르면 문제가 생겼을 때 원인을 찾기 어렵습니다. 캐시를 비우고 주요 페이지를 확인합니다.
- 업데이트 전: 파일과 데이터베이스 전체 백업
- 업데이트 중: 플러그인 여러 개를 한 번에 처리하지 않기
- 업데이트 후: 메인, 글 상세, 문의, 로그인, 결제 화면 확인
- 문제 발생 시: 바로 복원하기보다 에러 로그와 충돌 플러그인 먼저 확인
백업제는 사이트를 빠르게 만드는 도구가 아닙니다. 사고가 났을 때 원래 상태로 돌아갈 시간을 줄이는 장치입니다. 그래서 멋진 기능보다 복구 가능성이 더 중요합니다. 작은 사이트라면 무료 백업 플러그인으로도 충분히 시작할 수 있습니다. 다만 백업 파일을 서버 밖에 두고, 복구 테스트를 한 번 해본 구성이어야 합니다. 그 정도만 지켜도 워드프레스 운영에서 겪는 큰 사고의 절반은 꽤 조용히 지나갑니다.
