도마뱀 백업으로 워드프레스 사이트 살리는 방법

얼마 전 오래된 쇼핑몰 하나를 복구했는데, 관리자 화면도 안 열리고 흰 화면만 떴습니다. 원인은 플러그인 자동 업데이트 충돌이었고, 다행히 전날 백업이 남아 있어 20분 만에 되돌렸습니다. 이런 일을 10년 넘게 겪다 보니 백업은 보험이 아니라 운영 기본값에 가깝습니다.
검색어로 도마뱀 백업을 찾는 분들이 있는데, 실제로 중요한 건 이름보다 방식입니다. 워드프레스 백업은 파일과 데이터베이스를 같이 잡아야 합니다. 테마 파일만 저장해 놓고 안심하면 글, 주문, 회원 정보가 빠집니다. 반대로 데이터베이스만 있으면 이미지와 업로드 파일이 비어 보입니다.
도마뱀 백업 전에 알아야 할 범위
워드프레스 사이트는 크게 두 덩어리입니다. 하나는 서버에 있는 파일이고, 다른 하나는 데이터베이스입니다. 파일에는 테마, 플러그인, 업로드 이미지, 캐시 일부가 들어갑니다. 데이터베이스에는 글, 페이지, 댓글, 상품, 주문, 설정값이 들어갑니다.
그래서 백업 플러그인을 고를 때는 “전체 백업”이라는 말만 보면 안 됩니다. 실제로 파일과 DB를 모두 포함하는지 봐야 합니다. 특히 우커머스 사이트라면 주문 데이터가 DB에 있으니 백업 주기가 짧아야 합니다. 하루에 주문이 30건 들어오는 사이트에서 주 1회 백업은 복구해도 손실이 큽니다.
- 일반 블로그: 파일 주 1회, DB 매일 1회
- 회사 소개 사이트: 변경 전 수동 백업, 월 1회 자동 백업
- 쇼핑몰: DB 최소 하루 2회, 주문 많은 곳은 더 짧게
- 개발 작업 전: 테마·플러그인 업데이트 직전 수동 백업
사실 백업 주기는 서버 용량보다 사이트 성격으로 정해야 합니다. 글이 자주 올라오지 않는 블로그와 주문이 계속 쌓이는 쇼핑몰은 같은 기준을 쓰면 안 됩니다.
무료 플러그인으로 설정하는 방법
처음에는 무료 플러그인으로 충분합니다. UpdraftPlus, BackWPup, Duplicator 같은 선택지가 있고, 각각 성격이 조금 다릅니다. UpdraftPlus는 자동 백업과 복원이 편합니다. BackWPup은 압축 파일을 만들어 외부 저장소로 보내는 구성이 좋습니다. Duplicator는 사이트 이전이나 복제에 강합니다.
도마뱀 백업이라는 키워드로 들어온 분이라도 결국 목표는 같습니다. 버튼 몇 번으로 복구 가능한 상태를 만드는 겁니다. 저는 초보 운영자에게는 UpdraftPlus를 먼저 권하는 편입니다. 복원 화면이 비교적 단순하고, 파일과 DB를 나눠서 관리하기 쉽습니다.
권장 설정값
- 파일 백업 주기: 주 1회
- 데이터베이스 백업 주기: 매일 1회
- 보관 개수: 4개 이상
- 저장 위치: 서버 내부가 아닌 외부 저장소
- 업데이트 전 수동 백업: 반드시 실행
여기서 가장 많이 하는 실수가 백업 파일을 같은 서버 안에만 두는 겁니다. 서버 디스크가 깨지거나 호스팅 계정이 정지되면 백업도 같이 날아갑니다. 무료 저장소를 써도 되니 외부로 빼는 게 맞습니다. 구글 드라이브, 드롭박스, 원드라이브 같은 서비스 이름만 기억해도 충분합니다.
근데 외부 저장소 연결할 때 권한 요청 화면이 뜨면 대충 넘기지 마세요. 백업 플러그인이 접근하는 폴더가 어디인지 확인해야 합니다. 사이트 여러 개를 관리한다면 사이트명과 날짜가 보이는 폴더 구조를 만들어 두는 게 나중에 덜 헷갈립니다.
복구 테스트를 안 하면 백업이 아닙니다
백업 파일이 있다고 복구가 되는 건 아닙니다. 압축 파일이 깨졌을 수도 있고, 용량 제한 때문에 업로드가 중간에 멈출 수도 있습니다. PHP 메모리 제한, 업로드 제한, 실행 시간 제한 때문에 복원이 실패하는 경우도 흔합니다.
운영 사이트에서 바로 복구 테스트를 하면 위험합니다. 가능하면 스테이징 사이트나 별도 테스트 계정에서 확인하는 게 좋습니다. 최소한 3개월에 한 번은 백업 파일을 내려받아 압축이 풀리는지, DB 파일이 포함되어 있는지 봐야 합니다.
복구 전에 확인할 것
- 워드프레스 버전
- PHP 버전
- 테마와 주요 플러그인 버전
- DB 접두어와 문자셋
- 업로드 폴더 용량
특히 PHP 버전 차이 때문에 복구 후 플러그인이 바로 죽는 경우가 있습니다. 예전 사이트를 새 서버로 옮길 때 PHP 7.4에서 잘 돌던 플러그인이 PHP 8.x에서 오류를 내는 식입니다. 백업은 저장보다 복구 환경까지 같이 보는 작업입니다.
업데이트 전 백업 순서
워드프레스 사고의 상당수는 업데이트를 미루다가 한 번에 몰아서 눌렀을 때 납니다. 코어, 테마, 플러그인을 동시에 업데이트하면 뭐가 문제였는지 찾기 어렵습니다. 저는 보통 백업을 먼저 만들고, 플러그인 하나씩 업데이트한 뒤 화면을 확인합니다.
- 1단계: 전체 백업 생성
- 2단계: 캐시 플러그인 일시 비활성 또는 캐시 삭제
- 3단계: 플러그인 1개 업데이트
- 4단계: 관리자 화면과 주요 페이지 확인
- 5단계: 이상 없으면 다음 플러그인 진행
대형 업데이트는 방문자가 적은 시간에 하는 게 좋습니다. 쇼핑몰이면 새벽 시간대가 낫고, 기업 사이트라면 업무 시작 전이 낫습니다. 솔직히 5분 아끼려고 한 번에 누르는 것보다, 15분 더 쓰고 원인을 좁힐 수 있는 쪽이 훨씬 싸게 먹힙니다.
자동 업데이트도 무조건 나쁜 건 아닙니다. 보안 패치는 빨리 적용되는 게 맞습니다. 다만 결제, 예약, 회원 기능처럼 매출과 직접 연결된 플러그인은 자동 업데이트보다 수동 확인이 안전합니다. 자동화는 편하지만 책임까지 자동으로 가져가 주지는 않습니다.
유료 백업이 필요한 경우
무료로 되는 일에 유료를 먼저 권할 이유는 없습니다. 개인 블로그, 작은 회사 사이트, 방문자 적은 포트폴리오라면 무료 플러그인과 외부 저장소 조합으로 충분합니다. 다만 복구 시간이 돈으로 바로 연결되는 사이트는 이야기가 달라집니다.
우커머스 주문이 많거나, 회원제 강의 사이트처럼 데이터가 계속 바뀌는 곳은 실시간 또는 짧은 간격 백업이 필요합니다. 이때는 호스팅 백업, 플러그인 유료 기능, 별도 관리 서비스까지 비교해야 합니다. 기준은 기능 이름이 아니라 “몇 분 전 상태까지 되돌릴 수 있나”입니다.
- 무료 권장: 일반 블로그, 회사 소개, 소규모 랜딩 페이지
- 유료 검토: 쇼핑몰, 예약 사이트, 유료 회원 사이트
- 별도 관리 필요: 매출 손실이 시간 단위로 커지는 사이트
그리고 호스팅 업체가 백업을 제공한다고 해서 내 백업이 필요 없는 건 아닙니다. 업체 백업은 복구 요청 시간이 걸리고, 원하는 시점으로 안 돌아갈 수도 있습니다. 직접 가진 백업과 업체 백업이 같이 있어야 선택지가 생깁니다.
도마뱀 백업이든 어떤 이름의 백업이든, 운영자가 확인해야 할 건 단순합니다. 파일과 DB가 모두 있는지, 외부에 저장되는지, 복구 테스트를 해봤는지입니다. 워드프레스는 잘 굴러갈 때 손대기 싫은 마음이 드는데, 백업은 조용할 때 만들어 둬야 진짜 값어치를 합니다.
