워드프레스 백업재 설정하는 방법: 복구까지 되는 구성으로 잡기
얼마 전 운영 중인 쇼핑몰 하나가 플러그인 업데이트 뒤에 흰 화면으로 멈췄습니다. 관리자 화면도 안 열리고, FTP로 들어가 보니 캐시 플러그인과 보안 플러그인이 동시에 꼬여 있었습니다. 다행히 전날 새벽 백업이 있었고, 20분 안에 복구했습니다. 이런 일을 겪고 나면 백업재, 그러니까 백업을 다시 쓸 수 있는 상태로 갖춰 두는 일이 얼마나 중요한지 바로 느끼게 됩니다.
워드프레스 백업은 파일만 받아 두는 게 아닙니다. 데이터베이스, 업로드 이미지, 테마, 플러그인, 설정값까지 같이 살아 있어야 합니다. 더 중요한 건 복구 테스트입니다. 백업 파일이 있어도 복구가 안 되면 그냥 용량만 차지하는 압축파일입니다.
백업은 파일과 데이터베이스를 나눠서 봐야 합니다
워드프레스 사이트는 크게 두 덩어리입니다. 하나는 서버에 올라간 파일이고, 다른 하나는 데이터베이스입니다. 파일에는 테마, 플러그인, 이미지, 첨부파일이 들어갑니다. 데이터베이스에는 글, 페이지, 댓글, 상품, 주문, 회원 정보, 설정값이 들어갑니다.
초보자가 자주 하는 실수가 uploads 폴더만 내려받고 백업했다고 생각하는 겁니다. 이미지 파일은 남아도 글 내용과 설정이 들어 있는 데이터베이스가 없으면 사이트는 제대로 돌아오지 않습니다. 반대로 데이터베이스만 있어도 이미지와 플러그인 파일이 없으면 화면이 깨집니다.
- 파일 백업: wp-content 폴더, 테마, 플러그인, 업로드 이미지
- 데이터베이스 백업: 글, 설정, 회원, 주문, 댓글, 옵션값
- 환경 정보: PHP 버전, 워드프레스 버전, 주요 플러그인 버전
운영 사이트라면 최소한 이 세 가지를 같이 기록해야 합니다. 특히 쇼핑몰이나 예약 사이트는 주문과 예약 데이터가 계속 바뀌기 때문에 하루 1회 백업만으로 부족할 수 있습니다. 블로그는 하루 1회면 충분한 경우가 많지만, 매출이 걸린 사이트는 6시간 또는 12시간 간격도 검토해야 합니다.
플러그인으로 백업할 때 설정값은 이렇게 잡습니다
백업 플러그인은 편합니다. 다만 아무 플러그인이나 설치하면 백업 도중 서버 자원을 많이 쓰거나, 저장 공간을 순식간에 채웁니다. 저는 보통 무료 플러그인부터 봅니다. UpdraftPlus, BackWPup, Duplicator 같은 플러그인이 많이 쓰입니다. 서버 이전까지 자주 한다면 Duplicator가 편하고, 정기 백업 위주면 UpdraftPlus가 무난합니다.
설정은 복잡하게 잡을 필요 없습니다. 일반 블로그 기준으로 파일 백업은 주 1회, 데이터베이스 백업은 매일 1회면 충분한 편입니다. 글을 매일 여러 개 올리거나 댓글이 많은 사이트라면 데이터베이스 백업 주기를 더 짧게 잡습니다.
- 일반 블로그: 데이터베이스 매일 1회, 파일 주 1회
- 기업 소개 사이트: 데이터베이스 주 2~3회, 파일 주 1회
- 쇼핑몰: 데이터베이스 6~12시간 간격, 파일 매일 또는 격일
- 강의·회원제 사이트: 데이터베이스 최소 매일 1회, 회원 활동이 많으면 더 짧게
백업 보관 개수는 무작정 늘리지 않는 게 좋습니다. 30일 치를 모두 서버 안에 쌓아 두면 트래픽보다 디스크 용량이 먼저 터집니다. 보통 최근 7개에서 14개 정도면 운영상 충분한 경우가 많습니다. 대형 변경 전에는 별도 수동 백업을 하나 더 만들어 두면 됩니다.
중요한 설정이 하나 더 있습니다. 백업 저장 위치입니다. 같은 서버 안에만 저장하면 서버 장애 때 같이 날아갑니다. 클라우드 저장소나 외부 저장 공간을 하나 붙여 두는 게 낫습니다. 무료 용량으로도 작은 블로그는 충분히 운영할 수 있습니다. 유료 저장소는 사이트 용량이 크거나 보관 기간을 길게 가져가야 할 때 생각해도 늦지 않습니다.
호스팅 백업만 믿으면 위험한 이유
대부분의 호스팅사는 자동 백업을 제공합니다. 그런데 이걸 전부 믿고 있으면 곤란합니다. 보관 기간이 7일뿐인 곳도 있고, 복구 요청을 해야만 처리되는 곳도 있습니다. 어떤 곳은 파일만 복구되고 데이터베이스는 별도 요청이 필요합니다. 또 복구 작업이 유료인 경우도 있습니다.
호스팅 백업은 안전망으로 보는 게 맞습니다. 내가 직접 관리하는 백업이 1차, 호스팅 백업은 2차입니다. 둘 중 하나만 있으면 불안합니다. 특히 업데이트 사고는 며칠 뒤에 발견되는 경우가 있습니다. 방문자는 적어서 몰랐는데 문의 폼이 5일 전부터 안 되고 있었다든지, 결제 완료 페이지가 깨져 있었다든지 하는 식입니다. 보관 기간이 너무 짧으면 멀쩡했던 시점으로 돌아갈 수 없습니다.
운영하면서 제가 가장 많이 본 사고는 세 가지입니다. 플러그인 업데이트 후 오류, 보안 침해 후 악성 파일 삽입, 서버 이전 중 데이터 누락입니다. 이 셋은 백업이 있으면 대응 시간이 확 줄어듭니다. 반대로 백업이 없으면 원인 분석보다 사이트를 다시 맞추는 데 시간을 다 씁니다.
복구 테스트를 안 하면 백업재가 아닙니다
백업재라는 말을 굳이 쓰는 이유가 있습니다. 백업 파일이 존재하는 것과 실제로 다시 쓸 수 있는 백업은 다릅니다. 복구 테스트를 한 번도 안 했다면 아직 완성된 백업 체계가 아닙니다.
복구 테스트는 운영 사이트에서 바로 하면 안 됩니다. 임시 도메인이나 스테이징 공간을 만들고 거기에 복원해야 합니다. 호스팅에서 스테이징 기능을 제공하면 그걸 쓰면 되고, 없으면 하위 폴더나 별도 테스트 계정으로 진행합니다. 여기서 주의할 점은 운영 데이터베이스를 덮어쓰지 않는 겁니다. 데이터베이스 이름과 접두어를 정확히 확인해야 합니다.
- 백업 파일 다운로드가 정상인지 확인
- 압축 파일이 열리는지 확인
- 데이터베이스 복원이 가능한지 확인
- 관리자 로그인이 되는지 확인
- 글, 이미지, 문의 폼, 결제 흐름을 확인
복구 테스트는 분기 1회 정도면 충분합니다. 다만 테마를 바꾸거나 쇼핑몰 기능을 추가하거나 PHP 버전을 올리기 전에는 따로 한 번 해두는 게 좋습니다. 이때 테스트에 걸린 시간도 적어 둡니다. 실제 장애가 났을 때 15분 안에 되는지, 1시간이 걸리는지 알고 있는 것만으로도 대응이 달라집니다.
업데이트 전 백업 순서
워드프레스 사고는 업데이트를 안 해서도 나고, 업데이트를 막 눌러서도 납니다. 저는 운영 사이트에서 업데이트할 때 순서를 고정합니다. 먼저 전체 백업을 만들고, 캐시를 비우고, 플러그인을 하나씩 업데이트합니다. 그다음 테마, 워드프레스 코어 순서로 진행합니다. 모든 업데이트를 한 번에 누르는 건 편하지만 문제가 났을 때 원인을 찾기 어렵습니다.
특히 페이지 빌더, 보안 플러그인, 캐시 플러그인, 쇼핑몰 플러그인은 조심해야 합니다. 이 네 종류는 사이트 전체 동작에 깊게 들어갑니다. 업데이트 전에 변경 로그를 보고, 최근 버전에서 오류 제보가 많으면 며칠 기다리는 편이 낫습니다.
- 업데이트 전 전체 백업 1개 생성
- 백업 파일을 서버 밖으로 내려받기
- 캐시 플러그인 캐시 삭제
- 중요 플러그인부터 하나씩 업데이트
- 관리자 화면, 글 화면, 문의 폼, 결제 화면 확인
업데이트 뒤에는 메인 화면만 보면 안 됩니다. 실제 사용자가 지나가는 경로를 확인해야 합니다. 블로그라면 글 상세, 카테고리, 검색, 문의 폼 정도는 봐야 합니다. 쇼핑몰이면 장바구니, 결제, 주문 완료, 이메일 발송까지 확인해야 합니다.
유료 플러그인이 꼭 필요한 경우와 아닌 경우
작은 블로그나 회사 소개 사이트는 무료 백업 플러그인으로도 충분합니다. 외부 저장소 연동, 자동 일정, 수동 복원 정도만 되면 운영에 큰 문제 없습니다. 유료 플러그인이 필요한 경우는 조금 다릅니다. 사이트 용량이 크거나, 멀티사이트이거나, 복구를 버튼 몇 번으로 끝내야 하거나, 고객 사이트 여러 개를 한 계정에서 관리해야 할 때입니다.
제가 권하는 기준은 단순합니다. 복구 실패가 매출 손실로 바로 이어지면 유료 도구를 검토합니다. 그렇지 않다면 무료 플러그인과 호스팅 백업을 같이 쓰는 구성으로 시작해도 됩니다. 대신 복구 테스트는 꼭 해야 합니다. 돈을 썼는지보다 실제로 돌아오는지가 더 중요합니다.
백업은 평소에는 귀찮고 티도 안 납니다. 그런데 사이트가 멈춘 날에는 가장 먼저 찾게 됩니다. 플러그인 하나 더 깔아서 기능을 늘리는 것보다, 오늘 밤 백업이 제대로 만들어지고 내일 복구할 수 있는지 확인하는 게 운영에는 훨씬 값진 일입니다.
