크레 백업 제대로 설정하는 방법: 워드프레스 운영자가 먼저 봐야 할 기준
얼마 전 오래된 쇼핑몰 하나를 복구해 달라는 연락을 받았는데, 백업 파일은 있다고 했지만 막상 열어보니 업로드 폴더만 있고 데이터베이스가 빠져 있었습니다. 워드프레스는 파일만 복사한다고 살아나는 구조가 아닙니다. 글, 상품, 주문, 회원, 설정값 대부분은 데이터베이스에 들어 있고, 이미지와 테마 파일은 서버 파일에 따로 있습니다. 그래서 크레 백업을 준비할 때도 “백업 버튼을 눌렀다”보다 “무엇을, 어디에, 얼마나 자주, 어떻게 복구할 수 있는가”를 먼저 봐야 합니다.
크레 백업 전에 구조부터 잡아야 합니다
워드프레스 백업은 크게 두 덩어리입니다. 하나는 데이터베이스, 다른 하나는 파일입니다. 데이터베이스에는 글, 페이지, 댓글, 사용자, 우커머스 주문, 플러그인 설정이 들어갑니다. 파일에는 테마, 플러그인, 업로드 이미지, 첨부파일이 들어갑니다. 둘 중 하나라도 빠지면 복구 후 사이트가 어딘가 비어 보이거나 관리자 화면에서 오류가 납니다.
특히 우커머스 사이트는 더 조심해야 합니다. 일반 블로그는 하루 한 번 백업으로도 버틸 수 있지만, 주문이 들어오는 사이트는 몇 시간 차이로 매출 데이터가 사라질 수 있습니다. 하루 20건 이상 주문이 들어오는 사이트라면 최소 6시간 단위 데이터베이스 백업을 권합니다. 파일은 매번 바뀌지 않으니 하루 한 번 또는 변경 작업 전 백업이면 충분한 경우가 많습니다.
- 블로그: 데이터베이스 1일 1회, 파일 1주 1회
- 기업 사이트: 데이터베이스 1일 1회, 파일 변경 전 수동 백업
- 쇼핑몰: 데이터베이스 1~6시간 단위, 파일 1일 1회
- 강의·회원제 사이트: 회원 가입과 결제 빈도에 맞춰 데이터베이스 백업 주기 조정
백업 위치는 서버 밖으로 빼야 합니다
초보 운영자들이 가장 많이 하는 실수가 백업 파일을 같은 호스팅 계정 안에만 두는 겁니다. 서버 디스크가 깨지거나 계정이 정지되거나 악성코드가 퍼지면 원본과 백업이 같이 죽습니다. 크레 백업을 쓰든 다른 백업 플러그인을 쓰든, 저장 위치는 서버 밖이어야 합니다.
실무에서는 보통 3개 기준으로 봅니다. 첫째, 서버 안에 임시 백업 1개. 둘째, 외부 저장소에 자동 백업. 셋째, 중요한 변경 전에는 내 컴퓨터나 별도 보관 공간에 수동 다운로드. 이 정도면 대부분의 사고에서 버틸 수 있습니다. 다만 백업 파일을 계속 쌓아두면 용량이 금방 찹니다. 이미지가 많은 사이트는 한 번 백업에 2GB가 넘는 일도 흔합니다.
보관 개수는 사이트 성격에 맞춰 잡는 게 좋습니다. 작은 블로그는 최근 7일치면 충분한 경우가 많고, 쇼핑몰은 최근 14일치와 월별 보관분 2~3개를 따로 두는 편이 낫습니다. 오래된 백업을 무작정 보관하면 비용만 늘고, 개인정보가 들어간 파일을 오래 들고 있는 부담도 생깁니다.
플러그인 선택은 기능보다 복구 성공률입니다
백업 플러그인은 많습니다. 그런데 운영 경험상 중요한 건 버튼이 예쁘냐가 아니라 복구가 단순하냐입니다. 무료 플러그인도 충분히 쓸 수 있습니다. 다만 대용량 사이트, 멀티사이트, 우커머스 실시간 백업, 외부 저장소 자동 연동 같은 조건이 붙으면 유료 기능이 필요한 경우가 있습니다. 무료로 되는 일에 유료를 먼저 권할 필요는 없지만, 주문 데이터가 걸린 사이트에서 백업 비용을 아끼는 건 방향이 틀립니다.
크레 백업을 포함해 어떤 도구를 쓰더라도 아래 항목은 먼저 확인해야 합니다. 이걸 확인하지 않고 설치하면 백업은 된 것처럼 보이는데 복구 단계에서 막힙니다.
- 데이터베이스와 파일을 따로 백업할 수 있는지
- 외부 저장소 자동 업로드를 지원하는지
- 백업 파일을 분할 저장할 수 있는지
- 복구 과정에서 기존 파일을 덮어쓰기 전에 경고가 나오는지
- 서버 용량 부족 시 백업을 중단하고 알려주는지
- 백업 로그를 관리자 화면에서 확인할 수 있는지
저사양 호스팅에서는 백업 플러그인이 서버 자원을 꽤 씁니다. 방문자가 많은 낮 시간에 전체 백업을 돌리면 사이트가 느려지거나 500 오류가 날 수 있습니다. 예약 시간은 새벽 3시에서 5시 사이가 무난합니다. 해외 방문자가 많은 사이트라면 실제 접속 통계를 보고 가장 조용한 시간을 골라야 합니다.
업데이트 전에는 자동 백업만 믿지 마세요
워드프레스 사고는 대부분 업데이트를 미뤄서 생기지만, 업데이트 직후에도 사고는 납니다. 테마와 플러그인 충돌, PHP 버전 문제, 캐시 플러그인 설정 꼬임이 대표적입니다. 그래서 코어, 테마, 플러그인을 업데이트하기 전에는 자동 백업과 별개로 수동 백업을 하나 더 만들어야 합니다.
업데이트 순서도 중요합니다. 먼저 백업을 만들고, 캐시를 비운 뒤, 플러그인을 하나씩 업데이트합니다. 그다음 테마, 워드프레스 코어를 처리하는 방식이 안정적입니다. 한꺼번에 전체 업데이트를 누르면 문제가 났을 때 어떤 항목이 원인인지 찾기 어렵습니다. 플러그인이 20개 넘는 사이트라면 더더욱 나눠서 해야 합니다.
업데이트 전 체크할 것
- 최근 백업 시간이 오늘인지 확인
- 백업 파일 크기가 0KB가 아닌지 확인
- 관리자 계정으로 로그인이 되는지 확인
- 호스팅 PHP 버전과 플러그인 요구 조건 확인
- 캐시 플러그인과 보안 플러그인 설정 위치 확인
잘못 건드리면 사이트가 바로 죽는 부분도 있습니다. 데이터베이스 최적화, 보안 플러그인의 로그인 주소 변경, 캐시 플러그인의 파일 병합, 테마 함수 파일 수정은 백업 없이 만지면 안 됩니다. 특히 함수 파일은 세미콜론 하나 빠져도 관리자 화면까지 하얗게 뜰 수 있습니다.
복구 테스트를 한 번은 해야 합니다
백업은 복구가 확인돼야 백업입니다. 이 말을 진짜 많이 합니다. 파일이 있어도 압축이 깨졌거나 데이터베이스 문자셋이 맞지 않거나 업로드 경로가 꼬이면 복구가 실패합니다. 운영 중인 사이트에 바로 복구 테스트를 하면 위험하니, 테스트용 하위 환경이나 임시 서버에서 확인하는 방식이 좋습니다.
복구 테스트에서는 첫 화면만 보면 안 됩니다. 관리자 로그인, 글 목록, 이미지 표시, 문의 폼, 결제 화면, 회원 로그인까지 봐야 합니다. 쇼핑몰이라면 테스트 상품을 장바구니에 담고 결제 직전 단계까지 가보는 게 맞습니다. 이 과정에서 이미지가 깨지면 파일 백업 문제이고, 글은 보이는데 설정이 날아갔다면 데이터베이스 복원 쪽을 봐야 합니다.
저는 새 사이트를 만들면 운영 시작 전에 백업과 복구를 먼저 맞춥니다. 디자인보다 먼저입니다. 예쁘게 만든 사이트도 한 번 터지면 복구 못 하는 순간부터 운영 자산이 아니라 불안 요소가 됩니다. 크레 백업을 쓰는 목적도 결국 같습니다. 문제가 생겼을 때 당황하지 않고 어제 상태, 또는 한 시간 전 상태로 돌아갈 수 있어야 합니다.
워드프레스는 오래 굴릴수록 화려한 기능보다 기본기가 돈을 아껴줍니다. 백업 주기, 저장 위치, 복구 테스트만 제대로 잡아도 큰 사고의 절반은 피합니다. 플러그인을 하나 더 설치하기 전에 지금 백업 파일이 실제로 복구 가능한지부터 확인하는 쪽이 운영자에게 훨씬 현실적인 선택입니다.
