워드프레스 백업하는 방법과 복구 확인 순서
얼마 전 플러그인 업데이트 뒤 화면이 하얗게 변한 사이트를 복구했습니다. 백업 파일은 있었지만 데이터베이스가 빠져 있어 글과 설정을 되살리는 데 시간이 더 걸렸습니다. 워드프레스 백업은 파일을 만드는 작업에서 끝나지 않습니다. 필요한 데이터가 모두 들어 있고, 실제로 복구할 수 있어야 합니다.
백업할 것은 파일과 데이터베이스 두 가지다
워드프레스는 파일과 데이터베이스를 따로 사용합니다. 업로드한 이미지, 테마, 플러그인은 주로 파일에 있고 글, 댓글, 사용자와 사이트 설정은 데이터베이스에 있습니다. 워드프레스 공식 운영 문서도 두 가지를 함께 보관해야 전체 사이트를 복구할 수 있다고 안내합니다. 서버의 파일만 내려받거나 관리자 화면의 ‘도구 → 내보내기’에서 XML 파일만 받아서는 전체 백업이 되지 않습니다.
파일에서는 최소한 wp-content 폴더와 wp-config.php를 챙깁니다. 테마 파일을 직접 수정했거나 워드프레스 설치 폴더에 별도 파일을 둔 사이트라면 설치 폴더 전체를 받는 편이 안전합니다. 데이터베이스는 SQL 형식으로 내보내고, 같은 시점에 만든 파일 백업과 한 묶음으로 보관합니다. 날짜만 적지 말고 업데이트 전인지 후인지도 파일 이름이나 보관 폴더에 남겨두면 복구할 때 헷갈리지 않습니다.
플러그인으로 자동 백업을 설정하는 방법
관리자 화면에 접속할 수 있고 일반적인 블로그 규모라면 UpdraftPlus 무료판으로 시작해도 됩니다. ‘플러그인 → 새로 추가’에서 UpdraftPlus를 설치한 뒤 설정 화면의 ‘설정’ 탭을 엽니다. 파일 백업은 주 1회, 데이터베이스 백업은 매일로 지정하고 보관 개수는 각각 4개 이상으로 잡습니다. 글을 매일 올리지 않는 사이트라면 데이터베이스도 주 1회로 낮출 수 있습니다. 반대로 주문이나 회원 가입이 계속 들어오는 사이트는 하루 한 번으로 부족할 수 있으니 손실을 감당할 수 있는 시간을 기준으로 주기를 정해야 합니다.
저장 위치는 구글 드라이브 같은 외부 저장소를 선택하고 계정을 연결합니다. 설정을 저장한 다음 ‘백업/복원’ 탭에서 즉시 백업을 한 번 실행합니다. 이때 데이터베이스, 플러그인, 테마, 업로드 파일, 기타 파일 항목이 포함됐는지 확인합니다. 작업이 끝나면 외부 저장소에 파일이 실제로 생겼는지도 봐야 합니다. 관리자 화면에 ‘완료’가 표시돼도 외부 전송에 실패했다면 서버 장애 때 함께 잃을 수 있습니다.
이미 호스팅 업체가 자동 백업을 제공한다면 플러그인을 추가하기 전에 보관 기간, 복구 방식, 백업 파일을 직접 내려받을 수 있는지 확인하세요. 필요한 조건을 충족한다면 기존 기능을 쓰는 편이 간단합니다. 다만 같은 서버에만 보관되는 백업에 전부 맡기지는 않습니다. 복구에 쓸 사본 하나는 서버 밖에 두는 게 좋습니다.
플러그인 없이 직접 받는 방법
플러그인을 늘리고 싶지 않다면 호스팅 파일 관리자나 SFTP로 워드프레스 파일을 내려받고, 호스팅에서 제공하는 phpMyAdmin으로 데이터베이스를 내보내면 됩니다. 먼저 사이트에 연결된 데이터베이스 이름을 wp-config.php에서 확인합니다. phpMyAdmin에서 그 데이터베이스를 선택한 뒤 ‘내보내기 → 빠른 실행 → SQL’을 고릅니다. 내려받은 SQL 파일이 비어 있지 않은지 확인하고, 같은 날짜의 사이트 파일과 함께 보관합니다.
여기서 다른 사이트의 데이터베이스를 선택하지 않도록 주의해야 합니다. 한 호스팅 계정에서 여러 사이트를 운영하면 이름이 비슷할 수 있습니다. 데이터베이스 내보내기는 원본을 지우는 작업이 아니지만, 복구 과정의 가져오기는 기존 데이터를 덮어쓸 수 있습니다. 운영 사이트에 시험 삼아 가져오기를 실행하면 그 이후에 작성된 글이나 주문이 사라질 수 있습니다.
수동 백업은 비용이 들지 않는 대신 사람이 잊기 쉽습니다. 글을 자주 올리거나 여러 명이 관리하는 사이트라면 자동 백업을 기본으로 두고, 큰 변경 직전에 수동 백업을 한 번 더 받는 방식이 실용적입니다. 특히 워드프레스 본체, 테마, 주요 플러그인을 업데이트하기 전에는 최신 백업의 생성 시각부터 확인합니다.
백업 파일이 복구되는지 확인하는 순서
백업의 품질은 복구 시험에서 드러납니다. 가능하면 별도 테스트 사이트를 만들고 백업 파일로 복원합니다. 화면만 뜨는지 보는 것으로 끝내지 말고 최근 글 2~3개, 이미지, 관리자 로그인, 문의 양식까지 확인합니다. 쇼핑몰이라면 주문 내역과 상품 이미지도 봐야 합니다. 테스트 환경에서 메일이 발송되거나 결제가 진행되지 않도록 해당 기능은 미리 꺼둡니다.
실제 장애가 나면 우선 현재 상태도 별도로 보관하고, 정상 작동한 백업 시점을 고릅니다. 파일을 복원한 뒤 해당 시점의 데이터베이스를 복원하는 순서가 기본입니다. 데이터베이스 접속 정보가 달라졌다면 wp-config.php의 설정도 맞춰야 합니다. 복구 후에는 관리자 로그인과 주요 페이지를 확인하고, 오류를 일으킨 업데이트나 플러그인을 찾은 다음 다시 적용 여부를 결정합니다.
저는 백업 주기보다 ‘언제까지의 데이터를 잃어도 되는가’를 먼저 묻습니다. 일주일에 글 한 편 쓰는 블로그와 하루에 주문이 수십 건 들어오는 사이트는 같은 설정을 쓰면 안 됩니다. 자동 백업을 걸어두고 한 달에 한 번 외부 저장소와 복구 가능 여부를 확인하는 습관이 결국 사이트를 가장 오래 살립니다.
