워드프레스 백업 방법: 파일과 데이터베이스를 함께 보관하세요

· WordPress.org 공식 문서 검토 ·

글을 모두 내보냈는데도 테마·플러그인·업로드 이미지가 돌아오지 않거나, 호스팅 백업은 있는데 어느 날짜로 복원해야 할지 모르면 실제 사고 때 멈추게 됩니다. 백업은 파일 하나를 만드는 일이 아니라, 같은 시점의 파일과 데이터베이스를 찾아 복구에 쓸 수 있게 보관하는 일입니다.

일반적인 워드프레스 사이트를 온전히 되돌리려면 파일과 데이터베이스가 모두 필요합니다.
파일에는 테마·플러그인·업로드 이미지와 설정 파일이 있고, 데이터베이스에는 글·페이지·댓글·사용자와 사이트 설정이 들어 있습니다.

먼저 호스팅이 자동 백업하는 범위와 보관 기간을 확인하세요.
그다음 같은 시점의 파일 사본과 데이터베이스 내보내기를 한 묶음으로 만들고, 운영 서버와 다른 장소에도 보관합니다.

복원은 운영 사이트에서 바로 시험하지 마세요.
별도 복제본이나 호스팅의 안전한 복원 환경에서 주소·글·이미지·로그인·핵심 기능이 돌아오는지 확인해야 백업의 쓸모를 알 수 있습니다.

이 글의 범위: 일반적인 단일 워드프레스 사이트에서 백업 범위와 주기를 정하고, 파일과 데이터베이스를 한 세트로 보관한 뒤 복구 가능성을 점검하는 데까지만 다룹니다. 특정 백업 플러그인 추천·비교, 호스팅별 버튼 위치, 운영 사이트의 실제 복원 실습은 별도 과업입니다.

바로 가기: 무엇을 백업할지 · 백업 주기 정하기 · 한 세트로 보관하기 · 정상 백업 확인 · 문제가 생겼을 때

이 글에서 바로 찾기

파일과 데이터베이스가 모두 있어야 합니다

WordPress 공식 백업 문서는 일반적인 사이트 백업을 파일과 데이터베이스 두 부분으로 나눕니다.
서버의 워드프레스 폴더를 내려받는 것만으로는 보통 데이터베이스가 포함되지 않습니다.

구분 주로 들어 있는 것 빠졌을 때 생기는 문제
워드프레스 파일 테마, 플러그인, 업로드 이미지, wp-content, wp-config.php, 서버 설정 파일 디자인·기능·이미지·연결 설정을 원래 상태로 되돌리기 어려움
데이터베이스 글, 페이지, 댓글, 사용자, 카테고리, 메뉴와 여러 사이트·플러그인 설정 콘텐츠와 설정을 원래 시점으로 되돌리기 어려움

데이터베이스를 내보내면 .sql, .gz, .bz2 같은 파일이 생길 수 있습니다.
그 파일을 워드프레스 파일 사본과 같은 폴더에 넣어 보관할 수는 있지만, 복원할 때는 데이터베이스 시스템으로 다시 가져와야 합니다.

도구 → 내보내기 파일만으로는 전체 사이트를 복구할 수 없습니다

WordPress의 내보내기 기능은 글·페이지·댓글·분류와 사용자 같은 콘텐츠 데이터를 WXR 형식의 XML 파일로 만듭니다.
다른 워드프레스에 콘텐츠를 옮길 때 유용하지만 테마·플러그인·wp-config.php와 서버의 실제 업로드 파일까지 한꺼번에 담는 전체 사이트 백업은 아닙니다.

콘텐츠 내보내기 파일을 추가 사본으로 보관하는 것은 괜찮습니다.
다만 파일 백업과 데이터베이스 백업을 대신했다고 표시하지 마세요.

백업 완료의 최소 기준 같은 시점의 워드프레스 파일과 데이터베이스 내보내기가 있고, 어느 사이트·언제·어떤 방법으로 만든 것인지 이름이나 기록으로 구분할 수 있어야 합니다.

호스팅 자동 백업부터 확인하세요

직접 백업 도구를 고르기 전에 현재 호스팅이 제공하는 백업을 확인하면 중복 비용과 빠진 범위를 줄일 수 있습니다.
확인할 항목은 버튼 이름이 아니라 아래 조건입니다.

  1. 파일과 데이터베이스가 모두 포함되는가?
  2. 자동 백업은 얼마나 자주 만들어지는가?
  3. 각 백업은 며칠 또는 몇 개까지 남는가?
  4. 내가 별도 위치로 내려받을 수 있는가?
  5. 전체 복원과 파일·데이터베이스 개별 복원이 가능한가?
  6. 복원 중 사이트가 중단되는가?
  7. 복원에 별도 비용이나 지원 요청이 필요한가?

호스팅 백업이 있다는 말만으로는 충분하지 않습니다.
백업이 같은 서버나 같은 계정 안에만 있고 계정 접근을 잃으면, 필요할 때 꺼내지 못할 수 있습니다.

WordPress 공식 문서는 호스팅 백업과 별개로 자신의 파일 사본을 보관하는 방법을 설명합니다.
최소한 최근 백업 하나는 운영 서버와 다른 위치에서 내가 찾을 수 있게 두세요.

백업 주기는 잃어도 되는 변경량으로 정하세요

모든 사이트에 같은 백업 주기가 맞는 것은 아닙니다.
지난 백업 이후 바뀐 글·주문·회원·댓글·설정 가운데 얼마나 잃어도 되는지가 기준입니다.

사이트 변화 시작할 백업 기준 다시 정해야 할 때
글과 설정이 거의 바뀌지 않음 정기 백업과 중요한 변경 직전 백업 발행 빈도나 담당자가 늘어남
주 1~2회 글 발행 적어도 새 글을 잃지 않을 간격 댓글·회원·폼 제출이 늘어남
매일 글·댓글·회원 정보 변경 매일 또는 더 짧은 자동 백업 검토 손실 가능한 시간이 더 짧아짐
테마·플러그인·코어 업데이트 업데이트 직전 별도 백업 업데이트와 배포 횟수가 늘어남
코드·서버 설정 변경 변경 직전 백업과 원래 설정 기록 여러 사람이 서버를 만짐

WordPress 공식 문서는 데이터베이스를 정기적으로, 특히 업그레이드 전에 백업하라고 안내합니다.
주간·일간 같은 예시는 시작점일 뿐, 내 사이트의 변경 속도와 허용 가능한 손실량에 맞춰야 합니다.

백업 시점도 기록하세요

문제가 발견된 날짜와 실제로 문제가 시작된 날짜는 다를 수 있습니다.
최근 백업 하나만 남기면 이미 문제가 포함된 백업일 수 있습니다.

공식 보안 문서는 서로 다른 시점의 전체 설치 스냅샷을 보관하는 전략을 예로 듭니다.
최근 사본 여러 개를 남기되, 개인정보가 들어 있다면 접근 권한과 보관 기간도 함께 정하세요.

파일과 데이터베이스를 한 세트로 묶으세요

백업 파일이 많아질수록 최신이라는 이름만으로는 짝을 찾기 어렵습니다.
사이트·생성 시각·범위·방법이 드러나는 이름을 사용하세요.

사이트: example.com
생성 시각: 2026-08-02 14:00 KST
파일: example-com_20260802-1400_files.zip
데이터베이스: example-com_20260802-1400_database.sql.gz
생성 방법: 호스팅 전체 백업 + 데이터베이스 내보내기
보관 위치: 호스팅 / 별도 저장소
복구 확인일:

WordPress 공식 문서는 일관성을 위해 파일과 데이터베이스를 비슷한 시점에 만든 한 세트로 다루는 방식을 설명합니다.
일반적인 백업 순서는 데이터베이스를 먼저 내보내고 파일을 복사하는 것이며, 일반적인 복원 순서는 파일을 먼저 되돌린 뒤 데이터베이스를 가져오는 것입니다.

이 순서가 모든 호스팅과 도구의 필수 규칙이라는 뜻은 아닙니다.
관리형 호스팅이나 백업 도구가 정한 복원 절차가 있다면 그 공식 절차를 먼저 따르세요.

서로 다른 위치에 보관하세요

한 서버 안에 백업 폴더를 만드는 것만으로는 서버 장애·계정 잠금·잘못된 삭제에 함께 영향을 받을 수 있습니다.
운영 서버 사본과 별개로 내려받은 사본 또는 접근 경로가 다른 저장소를 둡니다.

백업에는 사용자 이메일, 주문, 문의, 비공개 글, 데이터베이스 연결 정보가 포함될 수 있습니다.
공개 공유 링크에 올리지 말고, 필요한 사람만 접근하도록 보관하세요.

운영 사이트에서 복원 버튼을 시험 삼아 누르지 마세요. 복원은 현재 파일과 데이터베이스를 덮어쓸 수 있습니다. 별도 복제본, 스테이징, 또는 호스팅이 보장한 안전한 복원 환경이 없다면 복원 직전에서 멈추고 지원 문서를 확인하세요.

백업 파일이 열리는 것만으로는 충분하지 않습니다

압축 파일이 존재하거나 자동 백업 목록에 성공 표시가 있다는 것은 백업 생성 상태를 보여 줄 뿐입니다.
실제로 사이트를 되돌릴 수 있는지는 복원 뒤 확인해야 합니다.

운영 사이트와 분리된 환경에서 아래 항목을 확인하세요.

  • 사이트 주소가 예상한 주소로 열리는가?
  • 최근 글과 페이지가 예상한 시점까지 들어 있는가?
  • 대표 이미지와 본문 이미지가 보이는가?
  • 관리자 계정으로 로그인할 수 있는가?
  • 사용 중인 테마와 필수 플러그인이 활성화되는가?
  • 메뉴·카테고리·고유주소가 예상대로 작동하는가?
  • 문의 폼·검색·회원·결제처럼 사이트의 핵심 기능이 작동하는가?
  • 복원 과정에서 나온 오류와 걸린 시간을 기록했는가?

전자상거래·회원·예약 사이트는 백업 뒤에도 데이터가 계속 바뀝니다.
오래된 데이터베이스를 운영 서버에 되돌리면 백업 이후의 주문이나 회원 변경이 사라질 수 있으므로, 일반 정보 사이트와 같은 방식으로 즉시 복원하면 안 됩니다.

이 글은 실제 복원 실험 결과를 제공하지 않습니다.
사이트마다 호스팅·데이터 규모·플러그인·외부 저장 방식이 다르므로, 복원 절차는 사용 중인 호스팅과 도구의 공식 문서로 확정해야 합니다.

이 여섯 가지가 맞으면 백업 준비가 끝났습니다

  • 파일과 데이터베이스가 모두 백업 범위에 들어갑니다.
  • 같은 시점의 파일과 데이터베이스를 한 세트로 찾을 수 있습니다.
  • 사이트명·생성 시각·방법·보관 위치가 기록돼 있습니다.
  • 운영 서버와 다른 위치에도 최근 사본이 있습니다.
  • 업데이트나 서버 변경 직전에 별도 백업을 만듭니다.
  • 운영 사이트와 분리된 곳에서 복구 확인을 할 경로가 있습니다.

백업이 불완전하거나 복원이 실패했다면 덮어쓰기를 멈추세요

파일만 있고 데이터베이스가 없다면

테마·플러그인·업로드 이미지와 설정 파일은 남아 있을 수 있지만, 글·사용자·사이트 설정을 원래 시점으로 되돌릴 데이터가 부족합니다.
호스팅 백업 목록에서 같은 시점의 데이터베이스 사본이 있는지 먼저 확인하세요.

데이터베이스만 있고 파일이 없다면

글과 여러 설정은 남아 있을 수 있지만 업로드 이미지, 사용하던 테마·플러그인, wp-config.php 같은 파일이 없습니다.
기존 서버·별도 저장소·호스팅 전체 백업에서 같은 시점의 파일 사본을 찾으세요.

백업 날짜를 모르겠다면

가장 최근이라는 이유만으로 바로 복원하지 마세요.
문제가 포함된 시점일 수 있습니다.
백업 생성 시각과 마지막 정상 확인 시각, 문제를 처음 발견한 시각을 나란히 적고 후보를 좁힙니다.

복원 중 오류가 났다면

같은 복원을 반복하면 일부 데이터가 중복되거나 현재 상태가 더 바뀔 수 있습니다.
오류 메시지, 사용한 백업 세트, 시작 시각, 이미 되돌린 범위를 기록한 뒤 작업을 멈춥니다.

관리형 호스팅이라면 현재 상태를 추가로 덮어쓰기 전에 공식 지원에 이 기록을 전달하세요.
직접 서버를 운영한다면 원본 디스크와 데이터베이스의 현재 사본을 별도로 확보한 뒤, 복구 경험이 있는 담당자가 복제 환경에서 확인해야 합니다.

사용자를 나눠 운영한다면 워드프레스 사용자 역할과 권한 기준으로 백업과 복원 권한을 가진 사람을 먼저 정하세요.
사이트를 처음 만든 단계라면 설치 후 설정 7가지를 마친 뒤 첫 정상 상태의 백업을 남기면 됩니다.

확인한 공식 문서

공식 문서는 2026년 8월 2일 다시 확인했습니다.
호스팅마다 백업 범위·보관 기간·다운로드·복원 방식이 다르므로 실제 버튼과 복원 절차는 사용 중인 호스팅의 최신 공식 문서를 함께 확인해야 합니다.

워드프레스 전체 순서 보기