워드프레스 백업하는 방법, 복구까지 생각해서 이렇게 잡으세요
얼마 전 운영 중인 쇼핑몰 하나가 플러그인 업데이트 뒤에 흰 화면으로 멈춘 적이 있습니다. 다행히 백업이 6시간 전 기준으로 남아 있어서 20분 만에 되돌렸습니다. 그런데 같은 상황에서 백업 파일은 있는데 복구를 못 해서 하루를 날리는 사이트도 꽤 봤습니다. 워드프레스 백업은 파일을 저장하는 일이 아니라, 사이트를 다시 살릴 수 있는 상태를 만들어 두는 일입니다.
초보자일수록 백업을 플러그인 하나 깔고 끝낸다고 생각합니다. 실제 운영에서는 조금 다릅니다. 어떤 파일을 저장할지, 데이터베이스는 언제 뽑을지, 백업 파일을 어디에 둘지, 복구 테스트를 했는지가 더 중요합니다. 특히 블로그라도 글이 100개를 넘고 검색 유입이 들어오기 시작하면 백업 정책은 선택이 아니라 기본 운영입니다.
워드프레스 백업에서 꼭 챙길 것
워드프레스 사이트는 크게 두 덩어리로 나뉩니다. 하나는 파일이고, 다른 하나는 데이터베이스입니다. 파일에는 테마, 플러그인, 업로드 이미지가 들어갑니다. 데이터베이스에는 글, 페이지, 댓글, 설정값, 사용자 정보가 들어갑니다.
둘 중 하나만 있으면 제대로 복구가 안 됩니다. 파일만 백업하면 글 내용이 빠지고, 데이터베이스만 백업하면 이미지와 테마 구성이 깨질 수 있습니다. 그래서 백업 설정을 볼 때는 반드시 파일 백업과 데이터베이스 백업이 같이 잡혀 있는지 확인해야 합니다.
- 파일: wp-content 폴더, 테마, 플러그인, 업로드 이미지
- 데이터베이스: 글, 페이지, 메뉴, 위젯, 플러그인 설정
- 설정 파일: wp-config 파일, 서버 설정 일부
여기서 가장 중요한 폴더는 wp-content입니다. 워드프레스 코어 파일은 다시 받을 수 있지만, 업로드한 이미지와 테마 수정본은 사라지면 복구가 어렵습니다. 특히 자식 테마를 쓰지 않고 테마 파일을 직접 수정한 사이트는 백업 없이는 거의 답이 없습니다.
백업 주기는 사이트 성격에 맞춰야 합니다
모든 사이트가 매시간 백업할 필요는 없습니다. 반대로 하루에 주문이 여러 건 들어오는 쇼핑몰을 일주일에 한 번만 백업하는 건 위험합니다. 백업 주기는 사이트가 얼마나 자주 바뀌는지 기준으로 잡는 게 맞습니다.
- 개인 블로그: 주 1회 파일 백업, 일 1회 데이터베이스 백업
- 콘텐츠를 자주 올리는 블로그: 일 1회 전체 백업
- 회원제 사이트: 최소 일 1회, 가능하면 6~12시간 단위
- 쇼핑몰: 주문 데이터 때문에 실시간 또는 짧은 주기 백업 권장
운영 경험상 일반 블로그는 하루 1회 자동 백업이면 충분한 경우가 많습니다. 다만 테마 변경, 플러그인 대규모 업데이트, PHP 버전 변경 전에는 수동 백업을 따로 떠야 합니다. 이 작업 전 백업은 보험이 아니라 안전장치입니다.
백업 보관 기간도 정해야 합니다. 저는 보통 최소 14일, 여유가 있으면 30일을 권합니다. 어제 생긴 문제라고 생각했는데 실제 원인은 10일 전 플러그인 업데이트였던 경우가 있습니다. 백업이 3개만 남아 있으면 이런 문제를 되돌리기 어렵습니다.
플러그인으로 백업할 때 설정값
처음에는 백업 플러그인을 쓰는 게 현실적입니다. 서버 명령어로 직접 백업하는 방식도 좋지만, 초보 운영자가 매번 확인하기 어렵습니다. 무료 플러그인으로도 기본 백업은 충분히 가능합니다.
많이 쓰는 선택지는 UpdraftPlus, BackWPup, Duplicator입니다. UpdraftPlus는 자동 백업과 외부 저장소 연결이 편합니다. BackWPup은 파일과 데이터베이스를 나눠 세밀하게 잡기 좋습니다. Duplicator는 이전이나 복제 작업에 강하지만, 자동 백업 중심으로 쓰려면 설정을 잘 봐야 합니다.
권장 설정 예시
- 파일 백업: 주 1회 또는 일 1회
- 데이터베이스 백업: 일 1회
- 보관 개수: 최소 14개 이상
- 저장 위치: 웹서버 밖의 외부 저장소
- 백업 알림: 실패 시 이메일 알림 켜기
중요한 건 백업 파일을 같은 서버 안에만 두지 않는 겁니다. 서버 장애, 계정 정지, 악성코드 감염이 생기면 같은 서버에 있는 백업도 같이 못 쓰게 됩니다. 클라우드 저장소나 별도 서버에 한 번 더 보내는 구성이 안전합니다.
무료로 충분히 운영하려면 자동 백업 플러그인 하나와 클라우드 저장소 조합이면 됩니다. 굳이 처음부터 유료 백업 서비스를 쓸 필요는 없습니다. 다만 매출이 나는 사이트라면 복구 지원이 포함된 유료 서비스도 계산해볼 만합니다. 비용보다 다운타임 손실이 큰 경우가 있기 때문입니다.
복구 테스트를 안 하면 백업이 아닙니다
백업 파일이 있다고 안심하면 안 됩니다. 실제로 압축 파일이 깨져 있거나 데이터베이스 백업이 누락된 사례를 여러 번 봤습니다. 백업 플러그인 화면에는 성공이라고 뜨는데 복구할 때 이미지가 빠지는 경우도 있습니다.
최소 한 번은 테스트 환경에서 복구를 해봐야 합니다. 운영 사이트에 바로 복구를 누르는 건 위험합니다. 가능하면 스테이징 사이트나 임시 설치본을 만들어 백업 파일을 올리고, 글 목록과 이미지, 로그인, 주요 페이지를 확인합니다.
- 관리자 로그인이 되는지 확인
- 최근 글과 페이지가 보이는지 확인
- 이미지가 깨지지 않는지 확인
- 메뉴와 위젯이 유지되는지 확인
- 문의 폼, 결제, 회원 기능이 정상인지 확인
복구 테스트는 매주 할 필요까지는 없습니다. 하지만 처음 백업 설정을 잡은 직후, 백업 플러그인을 바꾼 직후, 호스팅을 이전한 직후에는 꼭 한 번 확인하는 게 좋습니다. 이 과정을 한 번 해두면 실제 사고가 났을 때 당황하는 시간이 줄어듭니다.
업데이트 전에는 수동 백업부터
워드프레스 사고는 대개 큰 작업이 아니라 평범한 업데이트에서 납니다. 플러그인 하나 업데이트했는데 PHP 버전과 안 맞거나, 테마가 오래돼서 최신 워드프레스와 충돌하는 식입니다. 그래서 업데이트 버튼을 누르기 전에 수동 백업을 하나 만들어 두는 습관이 필요합니다.
특히 페이지 빌더, 보안 플러그인, 캐시 플러그인, 쇼핑몰 플러그인은 영향 범위가 큽니다. 이런 플러그인은 한꺼번에 여러 개 업데이트하지 말고 하나씩 적용한 뒤 화면을 확인하는 편이 안전합니다. 문제가 생기면 방금 바꾼 대상이 뭔지 바로 알 수 있습니다.
캐시 플러그인을 쓰는 사이트는 복구 후 캐시를 비워야 합니다. 백업은 제대로 돌아왔는데 오래된 캐시 때문에 화면이 계속 깨져 보이는 경우가 있습니다. 서버 캐시, 플러그인 캐시, CDN 캐시를 쓰고 있다면 순서대로 비워야 합니다.
제가 운영 사이트에 기본으로 잡는 방식은 단순합니다. 자동 백업은 매일 돌리고, 백업 파일은 외부에 저장하고, 큰 변경 전에는 수동 백업을 하나 더 만듭니다. 그리고 복구 테스트를 한 번 해둡니다. 이 정도만 해도 웬만한 사고는 하루짜리 문제가 아니라 30분짜리 작업으로 줄어듭니다. 워드프레스 백업은 복잡하게 꾸미는 것보다, 실제로 돌아오는 구성을 꾸준히 유지하는 게 훨씬 중요합니다.
