백업 이야기를 하면 대개 “전체 백업” 이라는 한 덩어리를 떠올립니다. 그런데 워드프레스 사이트를 이루는 것은 성질이 전혀 다른 세 가지이고, 바뀌는 속도도 되돌리는 경로도 서로 다릅니다. 셋을 한 덩어리로만 관리하면 실제로 사고가 났을 때 선택지가 둘밖에 남지 않습니다 — 전부 되돌리거나, 아무것도 되돌리지 않거나.
백업 설계의 첫 단계는 도구를 고르는 것이 아니라 대상을 나누어 보는 것입니다.
한 사이트를 이루는 세 덩어리
코드 — 사실은 백업 문제가 아닙니다
코드는 사람이 배포할 때만 바뀝니다. 그래서 버전 관리(Git 등)에 들어가 있다면 백업본은 이미 저장소에 있는 셈입니다. 어느 시점의 상태로든 되돌릴 수 있고, 누가 무엇을 바꿨는지도 남습니다.
그렇다면 코드에서 실제 백업 대상은 저장소에 들어가지 않는 것들입니다. wp-config.php(DB 접속 정보와 보안 키), nginx · PHP 설정 파일, SSL 인증서와 갱신 설정, cron 등록, 그리고 관리 화면에서 손으로 올려 둔 파일들이 여기 해당합니다. 이것들은 보통 용량이 아주 작은데, 없으면 복구가 그 자리에서 멈춥니다.
반대로 코드가 버전 관리에 없다면 그때는 코드도 데이터입니다 — 어느 파일이 언제 왜 바뀌었는지 아무도 모르므로 통째로 백업하는 수밖에 없습니다. 이 상태에서 벗어나는 것이 백업 설계를 쉽게 만드는 가장 큰 한 걸음입니다.
데이터베이스 — 가장 자주 바뀌고, 대개 가장 작습니다
글과 페이지, 사이트 설정, 사용자 계정, 주문과 문의 기록이 전부 데이터베이스에 있습니다. 방문자가 한 명이라도 있으면 바뀌고, 아무도 오지 않아도 예약 작업이 돌면서 바뀝니다.
크기는 셋 중 가장 작은 경우가 많습니다. 텍스트와 설정값이 대부분이기 때문입니다. 작고 자주 바뀐다는 두 성질이 겹치므로, 자주 떠도 부담이 적고 자주 떠야 할 이유는 큽니다. 복구 경로도 단순합니다 — 덤프 파일 하나를 임포트하면 끝입니다.
업로드 — 가장 크고, 대개 덧붙기만 합니다
wp-content/uploads/ 는 보통 백업 용량의 대부분을 차지합니다. 그런데 성질이 특이합니다. 기존 파일은 거의 바뀌지 않고 새 파일이 더해질 뿐입니다. 그래서 매번 전체를 복사하는 대신 바뀐 것만 더하는 동기화가 맞습니다. 전체 복사를 고집하면 용량 때문에 주기가 느려지고, 그 느린 주기에 데이터베이스까지 끌려갑니다.
덧붙여, 이 성질이 5회차에서 다룰 “데이터베이스만 되돌리기” 를 가능하게 합니다. 셋이 한 압축 파일 안에 섞여 있으면 그 선택 자체가 없습니다.
서버 설정과 인증서를 어디까지 백업 대상에 넣을지는 서버 · 인프라 아카이브에서 더 다루고, 지금 운영 중인 사이트의 백업 구성을 한 번 점검받고 싶다면 최적화 지원 사업의 진단에 포함돼 있습니다.
다음 회차
대상이 정해졌으면 얼마나 자주 뜰지가 남습니다. 다음 회차는 주기인데, 기준은 “하루에 한 번” 같은 관행이 아니라 잃어도 되는 시간입니다.