워드프레스 백업 옵트아웃하려면 이렇게 판단하세요
자동 백업을 끄기 전에 먼저 볼 것
얼마 전 관리하던 쇼핑몰 하나에서 호스팅 자동 백업을 꺼 달라는 요청이 왔습니다. 이유는 단순했습니다. 저장 공간이 부족하고, 백업 파일 때문에 요금제가 올라갈 것 같다는 거였습니다. 그런데 확인해보니 상품 이미지가 18GB, 데이터베이스가 420MB였고, 주문은 하루 30건 정도 들어오는 사이트였습니다. 이런 사이트에서 백업 옵트아웃을 아무 생각 없이 누르면 비용 몇 천 원 아끼려다 복구 불가능한 상황을 만들 수 있습니다.
백업 옵트아웃은 말 그대로 자동 백업 대상에서 빠지는 설정입니다. 호스팅 회사, 보안 플러그인, 백업 플러그인, 클라우드 저장소 연동에서 각각 따로 존재할 수 있습니다. 문제는 화면에 보이는 문구가 늘 친절하지 않다는 점입니다. ‘백업 제외’, ‘자동 저장 안 함’, ‘예약 작업 비활성화’, ‘원격 저장소 연결 해제’처럼 표현이 다릅니다.
워드프레스 운영에서 백업은 보험에 가깝습니다. 평소에는 돈과 용량을 먹는 것처럼 보이지만, 플러그인 업데이트 한 번 잘못되거나 관리자 계정이 털렸을 때 사이트를 살리는 거의 유일한 방법이 됩니다. 그래서 옵트아웃은 “백업이 필요 없다”가 아니라 “다른 방식으로 이미 안전하게 백업하고 있다”일 때만 선택해야 합니다.
백업 옵트아웃을 해도 되는 경우
모든 자동 백업을 무조건 켜둘 필요는 없습니다. 같은 파일을 세 군데에서 동시에 백업하면 서버가 느려지고 저장 공간도 빨리 찹니다. 특히 저가형 공유호스팅에서는 새벽 백업 작업이 겹치면 방문자가 적은 시간에도 CPU 사용량 제한에 걸리는 일이 있습니다.
이미 외부 백업이 정상 작동하는 경우
예를 들어 백업 플러그인으로 매일 새벽 3시에 데이터베이스를 저장하고, 매주 일요일 새벽 4시에 전체 파일을 외부 저장소로 보내고 있다면 호스팅의 중복 백업은 줄일 수 있습니다. 다만 최소 1회는 실제 복구 테스트를 해야 합니다. 백업 파일이 있다고 복구가 되는 것은 아닙니다. 압축 파일이 깨졌거나, 데이터베이스 문자셋이 맞지 않거나, 업로드 폴더만 빠진 경우를 꽤 봤습니다.
스테이징·개발용 사이트인 경우
테스트용 사이트, 임시 랜딩 페이지, 버려도 되는 개발 복제본은 백업 우선순위가 낮습니다. 이런 곳은 백업 옵트아웃을 해도 됩니다. 단, 운영 사이트와 같은 서버에 있으면 테스트 사이트의 백업 작업이 운영 사이트 속도까지 잡아먹을 수 있습니다. 이럴 때는 개발용 사이트의 자동 백업을 끄는 편이 낫습니다.
백업 주기가 과하게 촘촘한 경우
블로그 글을 일주일에 한두 개 쓰는 사이트가 1시간마다 전체 백업을 돌릴 필요는 없습니다. 데이터 변경이 적은 사이트는 데이터베이스는 하루 1회, 전체 파일은 주 1회 정도면 충분한 경우가 많습니다. 반대로 주문, 예약, 회원가입이 있는 사이트는 데이터베이스 백업 주기를 짧게 가져가야 합니다.
절대 끄면 안 되는 경우
운영 사이트에서 백업 옵트아웃을 누르기 전에 딱 세 가지를 확인해야 합니다. 최근 백업 날짜, 백업 저장 위치, 복구 가능 여부입니다. 이 세 가지 중 하나라도 모르면 끄지 않는 게 맞습니다.
- 최근 24시간 안에 데이터베이스 백업이 없다면 끄면 안 됩니다.
- 백업 파일이 같은 서버 안에만 있으면 안전한 백업으로 보기 어렵습니다.
- 복구 테스트를 한 번도 안 했다면 백업 성공 여부를 믿으면 안 됩니다.
- 쇼핑몰, 예약 사이트, 유료 회원 사이트는 데이터 손실 비용이 큽니다.
- 관리자가 여러 명이면 실수로 삭제되는 일이 생각보다 자주 생깁니다.
특히 같은 서버 안에 백업을 쌓아두는 방식은 조심해야 합니다. 서버 디스크가 고장 나거나 계정이 악성코드에 감염되면 원본과 백업이 같이 날아갑니다. 백업 플러그인이 만든 압축 파일이 웹에서 접근 가능한 폴더에 남아 있는 것도 위험합니다. 공격자가 그 파일을 내려받으면 사이트 소스와 데이터베이스 일부가 그대로 노출될 수 있습니다.
업데이트를 자주 미루는 사이트도 백업을 끄면 안 됩니다. 워드프레스 코어, 테마, 플러그인이 오래된 상태에서는 충돌과 보안 문제가 동시에 생깁니다. 이런 사이트는 어느 날 관리자 화면이 하얗게 뜨거나, 로그인 페이지가 이상한 주소로 바뀌는 식으로 터집니다. 그때 백업이 없으면 복구보다 재제작에 가까운 작업이 됩니다.
실무에서 쓰는 백업 설정 기준
제가 보통 권하는 기준은 단순합니다. 데이터베이스는 자주, 파일은 덜 자주, 저장 위치는 서버 밖입니다. 워드프레스에서 글, 주문, 댓글, 설정값은 대부분 데이터베이스에 들어갑니다. 이미지와 테마 파일은 파일 영역입니다. 그래서 둘을 같은 주기로 백업할 필요가 없습니다.
- 개인 블로그: 데이터베이스 매일 1회, 전체 파일 주 1회
- 회사 소개 사이트: 데이터베이스 매일 1회, 전체 파일 주 1회 또는 격주 1회
- 쇼핑몰: 데이터베이스 최소 하루 2회 이상, 전체 파일 주 1회
- 예약·회원 사이트: 데이터베이스 변경량에 따라 1~6시간 간격
- 업데이트 전: 수동 백업 1회 추가
보관 기간도 중요합니다. 백업을 3개만 남기면 감염 사실을 늦게 알았을 때 정상 파일이 이미 밀려났을 수 있습니다. 저는 최소 7일치 데이터베이스 백업, 4주치 전체 백업을 기준으로 잡습니다. 트래픽이 크거나 매출이 있는 사이트는 월 단위 보관본도 하나씩 남깁니다.
무료 플러그인으로도 기본 백업은 충분히 만들 수 있습니다. 다만 무료 버전에서 원격 저장소 자동 전송이 제한되거나, 복구 기능이 불편한 경우가 있습니다. 그럴 때 유료를 바로 쓰기보다 먼저 호스팅 백업과 조합해보는 게 낫습니다. 호스팅에서 하루 1회 서버 백업을 제공하고, 플러그인으로 업데이트 전 수동 백업만 챙겨도 작은 사이트는 꽤 안정적으로 운영됩니다.
백업 옵트아웃 체크 순서
옵트아웃 버튼을 누르기 전에는 순서대로 확인하면 됩니다. 어려운 작업은 아닙니다. 다만 건너뛰면 나중에 비용이 커집니다.
- 현재 백업이 어디에서 생성되는지 확인합니다. 호스팅, 플러그인, 보안 서비스가 각각 따로 돌 수 있습니다.
- 백업 파일 위치를 확인합니다. 같은 서버인지, 외부 저장소인지 구분해야 합니다.
- 데이터베이스와 업로드 파일이 모두 포함되는지 봅니다.
- 가장 최근 백업 파일을 내려받아 압축이 열리는지 확인합니다.
- 가능하면 스테이징 사이트에서 복구 테스트를 한 번 실행합니다.
- 중복되는 백업만 끄고, 최소 한 가지 자동 백업은 유지합니다.
여기서 많이 하는 실수가 있습니다. 백업 플러그인을 비활성화하면서 기존 백업 파일까지 삭제하는 겁니다. 플러그인 삭제 화면에서 ‘데이터 삭제’ 옵션이 나오면 문구를 꼭 읽어야 합니다. 일부 플러그인은 설정값만 지우지만, 일부는 백업 기록과 저장 파일까지 같이 지웁니다. 운영 사이트에서 이걸 실수하면 되돌리기 어렵습니다.
또 하나는 캐시 플러그인과 백업 플러그인의 작업 시간이 겹치는 경우입니다. 새벽 3시에 캐시 프리로드, 이미지 최적화, 전체 백업이 한 번에 돌면 서버가 버티기 힘듭니다. 이때 백업 옵트아웃이 답이 아니라 작업 시간을 나누는 게 먼저입니다. 예를 들어 데이터베이스 백업은 2시, 전체 백업은 4시, 캐시 프리로드는 5시처럼 분리하면 됩니다.
제가 권하는 운영 방식
백업 옵트아웃은 비용 절감 버튼이 아닙니다. 중복 작업을 줄이는 운영 설정에 가깝습니다. 그래서 끄는 것보다 남길 것을 먼저 정해야 합니다. 최소 하나의 자동 백업, 서버 밖 저장, 업데이트 전 수동 백업. 이 세 가지가 있으면 작은 블로그부터 회사 사이트까지 대부분의 사고를 버틸 수 있습니다.
워드프레스는 플러그인을 많이 깐다고 안전해지지 않습니다. 백업 플러그인도 마찬가지입니다. 두세 개를 동시에 돌리는 것보다 하나를 제대로 설정하고, 가끔 복구 테스트를 하는 쪽이 훨씬 낫습니다. 백업 옵트아웃을 해야 한다면 중복된 것부터 끄고, 운영 사이트를 살릴 마지막 백업선은 남겨두는 게 제일 현실적인 선택입니다.
