워드프레스 블로그 백업하는 법: 무엇을 어디에 얼마나 자주 백업할까

백업은 블로그가 망가질 확률을 낮추는 일이 아니라, 망가진 뒤 복구에 걸리는 시간을 미리 사두는 일입니다. 그래서 질문을 “백업을 해야 하나”가 아니라 “며칠 치를 잃어도 괜찮은가”로 바꿔야 판단이 섭니다. 결론부터 말하면, 호스팅이 제공하는 자동 백업 하나만 믿는 구성은 가장 흔하고 가장 위험한 선택입니다. 글과 미디어를 서로 다른 장소에 두 벌 두는 것이 개인 블로그가 지켜야 할 최소선이고, 여기까지는 돈을 거의 들이지 않고도 만들 수 있습니다.

백업이 필요한 순간은 해킹이 아니라 대부분 ‘내 손’이다

백업을 설명하는 글은 보통 해킹과 서버 장애를 앞세우지만, 개인 블로그에서 실제로 복구가 필요해지는 상황은 훨씬 평범합니다. 플러그인을 업데이트했더니 사이트가 백지가 되는 경우, 테마 파일을 직접 손보다 치명적인 오류를 내는 경우, 호스팅을 옮기는 중에 데이터베이스 일부가 깨지는 경우, 설정을 바꾸다 퍼머링크 구조를 건드려 전체 URL이 바뀌어버리는 경우가 그것입니다. 공통점은 외부 공격이 아니라 운영자 본인의 조작이 방아쇠였다는 점입니다.

이 구분은 중요합니다. 외부 공격 대비라면 “서버가 통째로 날아가도 살아남는 백업”이 필요하지만, 내 조작 실수 대비라면 “직전 상태로 10분 안에 되돌릴 수 있는 백업”이 더 급합니다. 두 요구가 다르기 때문에 뒤에서 보듯 방식도 하나로 끝나지 않습니다. 특히 플러그인을 꼭 필요한 것만 남기는 작업을 할 때나 퍼머링크 구조를 손대야 할 때는, 작업 전에 수동으로 한 벌 더 떠두는 습관이 자동 백업 설정보다 실질적인 안전장치가 됩니다.

애드센스 수익형 블로그에서는 손해 계산이 한 겹 더 붙습니다. 글이 사라진 것 자체보다, 사이트가 며칠 내려가 있는 동안 색인이 흔들리고 광고 노출이 끊긴 쪽이 더 비싸게 작용합니다. 복구 시간을 줄이는 것이 곧 수익 방어입니다.

백업해야 하는 네 가지와, 굳이 안 해도 되는 것

워드프레스 전체를 통째로 압축하는 방식은 직관적이지만 용량을 빠르게 잡아먹고, 그 때문에 보관 개수를 줄이게 되어 오히려 복구 지점이 얇아집니다. 대상을 성격별로 나누면 용량을 줄이면서 보관 기간을 늘릴 수 있습니다. 반드시 백업해야 하는 것은 네 가지입니다. 첫째 데이터베이스 — 글, 댓글, 카테고리와 태그, 모든 설정값이 여기에만 있습니다. 둘째 wp-content/uploads — 업로드한 이미지 원본으로, 한 번 잃으면 다시 만들 수 없습니다. 셋째 직접 수정한 테마·플러그인 파일과 자식 테마. 넷째 wp-config.php와 .htaccess — 용량은 수 킬로바이트지만 없으면 복구가 몇 배로 번거로워집니다.

반대로 워드프레스 코어 파일, 공식 저장소에서 받은 플러그인·테마의 본체, 캐시 폴더는 백업 대상에서 빼도 됩니다. 전부 다시 내려받을 수 있는 것들이고, 오히려 백업 용량의 대부분을 차지합니다. 이 구분만 적용해도 백업 한 벌의 크기가 몇 분의 일로 줄어드는 경우가 많습니다.

대상	변경 빈도	잃었을 때	우선순위
데이터베이스	글 쓸 때마다	글·설정 전부 소실, 복구 불가	최상
uploads (미디어)	발행할 때	이미지 원본 소실, 재제작 필요	최상
wp-config.php, .htaccess	거의 없음	재설정 가능하지만 시간 소모	높음
직접 수정한 테마·자식 테마	거의 없음	커스터마이징 다시 작업	높음
워드프레스 코어	자동 업데이트	재설치로 복구	불필요
저장소 플러그인 본체	자동 업데이트	재설치로 복구	불필요
캐시·임시 폴더	수시	영향 없음	제외 권장

주기는 ‘글 쓰는 빈도’가 아니라 ‘잃어도 되는 분량’으로 정한다

백업 주기를 정할 때 흔한 실수는 “매일 하면 안전하다”는 식으로 빈도만 올리는 것입니다. 기준은 빈도가 아니라 마지막 백업 이후 쌓인 작업량을 잃어도 감당할 수 있는지입니다. 주 2회 발행하는 블로그라면 하루 치 손실은 사실상 0일 수도 있지만, 매일 발행하면서 주 1회만 백업한다면 최악의 경우 글 여섯 편이 날아갑니다.

이 손실을 시간으로 환산해 보면 결정이 쉬워집니다. 글 한 편에 실제로 드는 시간과 비용을 계산해 보면 보통 한 편에 두세 시간은 들어가는데, 글 여섯 편이면 거의 이틀 분량의 작업입니다. 백업 주기를 하루로 줄이는 데 드는 비용은 설정 10분과 저장 공간 몇 기가바이트뿐이니, 비교 자체가 성립하지 않습니다.

실무적으로는 데이터베이스와 미디어의 주기를 따로 두는 쪽이 효율적입니다. 데이터베이스는 작고 자주 바뀌니 매일, 미디어는 크고 드물게 바뀌니 주 1회면 충분합니다. 여기에 “플러그인 업데이트나 테마 수정 직전에는 반드시 수동 1회”라는 규칙을 얹으면 앞서 본 사고 유형 대부분이 덮입니다. 보관 개수는 일간 7개, 주간 4개가 현실적인 균형점인데, 조용히 망가진 상태로 며칠 백업이 돌았을 경우에 대비해 최소 한 달 전 지점까지는 되돌아갈 수 있어야 하기 때문입니다.

어디에 두느냐가 방식보다 중요하다

백업에서 가장 자주 틀리는 지점은 방식이 아니라 저장 위치입니다. 같은 서버 안에 둔 백업은 백업이 아닙니다. 서버 디스크가 고장 나거나 호스팅 계정에 문제가 생기면 원본과 백업이 함께 사라지기 때문입니다. 실제로 “백업은 매일 돌고 있었는데 정작 복구할 수 없었다”는 사례는 대부분 백업 파일이 원본과 같은 운명을 공유하는 곳에 있었던 경우입니다.

기업에서 쓰는 3-2-1 원칙(사본 3개, 매체 2종, 외부 1곳)을 개인 블로그 규모로 줄이면 원본 + 호스팅 자동 백업 + 외부 클라우드 1곳이 됩니다. 외부 클라우드는 구글 드라이브나 드롭박스처럼 이미 쓰고 있는 계정으로 충분하고, 데이터베이스만 따로 보낸다면 무료 용량 안에서도 몇 달치가 들어갑니다.

그래서 호스팅별 조건을 비교할 때는 자동 백업 보관 일수, 복구가 셀프인지 요청 방식인지, 복구에 추가 비용이 붙는지를 함께 봐야 합니다. 보관 일수가 3일이고 복구가 유료 요청 방식인 호스팅이라면, 외부 백업의 비중을 그만큼 더 키워야 합니다.

방식 비교: 호스팅 자동 백업 / 플러그인 / 수동 내보내기

세 가지 방식은 대체재가 아니라 서로 다른 사고를 막습니다. 호스팅 자동 백업은 서버 장애에 강하지만 복구 단위가 사이트 전체라 “어제 글 하나만 되돌리기”가 안 됩니다. 플러그인 백업은 복구가 빠르고 외부 클라우드로 보낼 수 있어 조작 실수에 가장 잘 맞지만, 스케줄이 멈춰도 알림이 없으면 몇 주를 모르고 지나칩니다. 수동 내보내기는 번거롭지만 중요한 작업 직전에 쓰는 한 벌로서 대체가 없습니다.

구분	호스팅 자동 백업	백업 플러그인	수동 내보내기
막아주는 사고	서버·디스크 장애	업데이트 충돌, 조작 실수	계획된 작업 직전 사고
복구 단위	사이트 전체	전체 또는 DB만 선택	내보낸 범위만
외부 저장	대개 같은 인프라	클라우드 연동 가능	로컬 PC
복구 속도	요청 방식이면 수 시간	10~30분	즉시(범위 한정)
비용	요금제 포함 또는 유료	무료 플랜으로 시작 가능	0원
주요 실패 지점	보관 일수 짧음, 셀프 복구 불가	스케줄 중단·토큰 만료를 모름	사람이 잊음

서버에 명령줄로 접근할 수 있다면 데이터베이스 백업은 한 줄로 끝납니다. wp db export backup-$(date +%F).sql로 내보낸 뒤 압축해 클라우드로 올리는 스크립트를 하루 한 번 돌리면, 플러그인 없이도 가장 중요한 대상이 덮입니다. 다만 사이트 속도 관점에서 백업 작업은 CPU와 디스크를 함께 쓰므로, 방문자가 가장 적은 시간대로 예약하는 편이 좋습니다.

복구 연습을 한 번도 안 한 백업은 백업이 아니다

백업 설정에서 가장 많이 빠지는 단계가 복구 테스트입니다. 백업 파일이 매일 생기고 있다는 사실과, 그 파일로 사이트를 되살릴 수 있다는 사실은 전혀 다른 문제입니다. 복구가 실패하는 원인은 몇 가지로 정해져 있습니다. 용량 제한이나 타임아웃으로 백업이 중간에 잘려 있었던 경우, 클라우드 연동 토큰이 만료돼 몇 주 전부터 업로드가 안 되고 있던 경우, 데이터베이스는 있는데 미디어 폴더가 빠져 글마다 이미지가 깨지는 경우입니다.

분기에 한 번 다음 네 가지만 확인하면 충분합니다. ① 최신 백업 파일의 용량이 이전과 비슷한지(갑자기 작아졌다면 잘린 것입니다) ② 압축 파일을 열어 데이터베이스 파일과 uploads 폴더가 모두 들어 있는지 ③ 외부 저장소에 올라간 날짜가 최근인지 ④ 데이터베이스를 로컬이나 스테이징에 한 번 복원해 글 목록이 보이는지. 전체 복구까지 해볼 필요는 없고, ④만 한 번 성공해 두면 나머지는 대체로 따라옵니다.

복구를 마친 뒤에도 할 일이 남습니다. URL이나 퍼머링크가 바뀌지 않았는지, 이미지 경로가 살아 있는지 확인한 다음 서치콘솔에서 색인 상태를 점검해야 합니다. 사이트가 며칠 내려가 있었다면 크롤링 오류가 쌓여 있을 수 있고, 그대로 두면 복구는 끝났는데 검색 노출만 돌아오지 않는 상태가 길어집니다. 애드센스를 운영 중이라면 광고 코드와 ads.txt가 함께 복원됐는지도 같이 봐야 합니다. 블로그 운영 전반의 순서는 워드프레스 애드센스 수익형 블로그 완전 가이드에 정리해 두었습니다.

이럴 땐 이걸 고르세요

이제 막 블로그를 열었고 글이 10편 미만이라면 — 호스팅 자동 백업을 켜둔 상태에서, 데이터베이스만 월 1회 수동으로 내려받아 두면 충분합니다. 지금 단계에서 백업 구성에 쓸 시간은 글 한 편을 더 쓰는 데 쓰는 편이 낫습니다. 다만 “호스팅 백업이 켜져 있는지”는 지금 확인해 두세요.

주 2~3회 발행하고 글이 30편을 넘겼다면 — 백업 플러그인을 붙여 데이터베이스는 주 2회, 미디어는 주 1회 외부 클라우드로 보내도록 설정할 시점입니다. 이 구간부터는 잃을 분량이 다시 만들기 부담스러운 규모가 됩니다.

매일 발행하거나 애드센스 수익이 발생하고 있다면 — 데이터베이스 일 1회, 미디어 주 1회, 외부 저장소 2곳(클라우드 + 월 1회 로컬)까지 올리는 것이 맞습니다. 수익이 나는 사이트는 다운타임 자체가 비용이므로, 복구 속도가 빠른 플러그인 백업을 주력으로 두고 호스팅 백업을 보조로 쓰는 구성이 유리합니다.

테마를 직접 수정하거나 코드를 손대는 편이라면 — 주기와 무관하게 “작업 직전 수동 백업”을 규칙으로 고정하세요. 이 유형에서 사고가 가장 자주 나고, 동시에 가장 쉽게 막을 수 있습니다.

호스팅을 옮기려는 중이라면 — 이전 전에 전체 백업을 외부에 받아두고, 이전이 끝난 뒤에도 기존 계정을 최소 2주 유지하세요. 이전 직후에 발견되는 문제가 적지 않습니다.

자주 묻는 질문

Q. 호스팅에서 자동 백업을 해준다는데 따로 또 해야 하나요?
성격이 다르기 때문에 필요합니다. 호스팅 백업은 보관 일수가 짧은 경우가 많고(3~7일), 복구 단위가 사이트 전체이며, 셀프 복구가 안 되면 요청과 대기에 시간이 걸립니다. 어제 글 하나만 되돌리거나 플러그인 업데이트 직전 상태로 돌아가는 일에는 맞지 않습니다. 호스팅 백업은 서버 장애 대비, 별도 백업은 운영자 실수 대비로 생각하면 둘을 함께 두는 이유가 분명해집니다.

Q. 무료 백업 플러그인만으로 충분한가요?
개인 블로그 규모에서는 대체로 충분합니다. 무료 플랜에서 보통 제한되는 것은 외부 클라우드 연동 종류, 증분 백업, 자동 복구 같은 편의 기능이고, 가장 중요한 “데이터베이스와 미디어를 정기적으로 외부에 보내기”는 무료 범위에서도 됩니다. 다만 무료 플랜은 스케줄이 멈춰도 알림이 없는 경우가 있으니, 분기 점검을 사람이 챙긴다는 전제가 붙습니다.

Q. 백업을 복원했는데 이미지만 안 보입니다.
데이터베이스는 복원됐지만 uploads 폴더가 백업에 빠져 있었거나, 사이트 주소가 바뀌어 이미지 경로가 어긋난 경우입니다. 먼저 uploads 폴더에 파일이 실제로 있는지 확인하고, 파일이 있는데도 깨진다면 데이터베이스에 저장된 기존 주소를 현재 주소로 일괄 치환해야 합니다. 백업 대상에서 미디어를 빼면 안 되는 이유이고, 복구 테스트를 해봐야 미리 알 수 있는 문제입니다.