소규모 사업자 웹사이트 백업 방법 | 3-2-1 규칙과 주의사항

웹사이트를 안전하게 지키려면 백업을 자동화하고 주기적으로 검증해야 합니다. 이 가이드에서는 3-2-1 규칙을 적용하는 방법과 백업 주기, 암호화, 도구 활용을 단계별로 설명합니다. 마지막에는 호스팅 업체의 제약 사항과 복원 테스트 체크리스트를 함께 확인합니다.

웹사이트 백업의 중요성과 3-2-1 규칙

웹사이트는 디스크 고장, 해킹, 관리자 실수, 호스팅 서버 사고 등 다양한 원인으로 데이터를 잃을 수 있습니다. 백업이 없으면 복구 비용이나 시간이 크게 늘어납니다. 특히 소규모 사업자는 전담 IT 인력이 없어서 더 철저한 대비가 필요합니다.

웹사이트 백업은 3-2-1 규칙을 따라야 한다. 3-2-1 규칙은 백업 복사본을 최소 3개 유지하고, 서로 다른 2가지 저장 매체에 보관하며, 그중 1개는 오프사이트에 보관하는 전략입니다. 예를 들어 사무실의 외장 하드, 호스팅 서버 스냅샷, 클라우드 스토리지에 각각 백업을 두는 방식입니다. 이렇게 하면 한 매체가 손상되어도 다른 곳에서 복원할 수 있습니다.

복사본	저장 매체	보관 위치	비고
1	호스팅 서버 스냅샷	데이터센터	업체가 자동 생성
2	외장 SSD/하드	사무실	물리적 분리
3	클라우드 스토리지	오프사이트	업로드 시 암호화

백업 주기 설정: 매일 증분 백업, 매주 전체 백업

백업 주기를 정할 때는 사이트 변경 빈도와 데이터 중요도를 고려해야 합니다. 일반 웹사이트는 매일 증분 백업과 매주 전체 백업을 수행해야 한다. 증분 백업은 직전 백업 이후의 변경 사항만 저장하므로 시간과 용량 면에서 효율적입니다. 전체 백업은 모든 파일과 데이터베이스를 한 번에 복사하므로 복원 절차가 단순합니다.

예를 들어 쇼핑몰처럼 주문 정보가 자주 쌓이는 사이트라면 하루에도 여러 번 백업해야 할 수 있습니다. 반면 소규모 블로그는 매일 증분 백업과 매주 전체 백업으로 충분할 수 있습니다. 백업 보관 주기도 함께 정하세요. 예를 들어 전체 백업은 4주간, 증분 백업은 2주간 보관하는 식입니다. 이렇게 하면 랜섬웨어 감염 시점을 찾아 복원하기도 쉽습니다.

백업 주기 결정 기준

상황	증분 백업	전체 백업
게시물/상품 수정이 드물 때	주 2~3회	월 1회
일반적인 소규모 사이트	매일	매주
쇼핑몰, 예약 시스템	매일 2회 이상	매일 1회

백업 데이터 암호화 및 안전한 보관

백업 파일은 고객 개인정보, 주문 내역, 사이트 설정 정보를 포함하므로 외부 유출에 특히 주의해야 합니다. 백업 데이터는 암호화되어야 한다. 전송 중에는 SFTP, FTPS, HTTPS 등 암호화 프로토콜을 사용하고, 저장 중에는 파일 암호화 또는 암호화된 스토리지 서비스를 사용하는 것이 좋습니다.

예를 들어 UpdraftPlus 플러그인에서 클라우드 저장소로 백업을 업로드할 때 ‘암호화’ 옵션을 활성화하고, 복호화 키를 안전한 비밀번호 관리자에 보관할 수 있습니다. 암호화 키를 백업 파일과 같은 곳에 보관하면 암호화 의미가 없어지므로 주의하세요. 또한 백업 파일 접근 권한을 최소한으로 설정하는 것도 중요합니다.

호스팅 업체 제공 백업 기능 확인 (카페24 등)

국내 호스팅 업체인 카페24, 가비아, 닷홈 등은 서버 스냅샷이나 자동 백업 기능을 제공하는 경우가 많습니다. 하지만 백업 주기와 보관 기간, 복원 절차가 업체마다 다르므로 실제로 확인해야 합니다. 특히 다음 사항을 체크하세요.

자동 백업이 매일 실행되는가?
백업 보관 기간은 얼마나 되는가?
백업에서 제외되는 데이터가 있는가? (예: 캐시, 세션, 로그)
사용자가 직접 복원할 수 있는가, 아니면 고객센터에 요청해야 하는가?
복원 시 사이트가 중단되는가?

호스팅 업체의 백업은 완벽해 보여도, 같은 데이터센터에 위치하기 때문에 화재나 정전 같은 재해에는 취약할 수 있습니다. 따라서 3-2-1 규칙에서 강조하는 ‘오프사이트 백업’을 별도로 보관하는 것이 안전합니다. 업체 백업을 메인으로, 클라우드 백업을 보조로 사용하는 방식이 일반적입니다.

주의사항: 문의 데이터 미지원, 사용자 삭제 데이터 복구 불가

백업 기능이 모든 데이터를 보호해 주지는 않습니다. 예를 들어 문의 데이터는 백업과 복원 모두 지원되지 않습니다. 아임웹 FAQ에 따르면 문의는 백업 및 복원이 미지원입니다. 따라서 별도로 문의 내역을 주기적으로 내보내거나, 이메일로 전달되도록 설정해야 합니다.

또한 사용자가 실수로 삭제한 데이터는 복원이 불가능합니다. 아임웹은 자체 시스템으로 데이터를 보존하지만, 사용자가 직접 삭제한 데이터는 복원할 수 없습니다. 즉, 관리 화면에서 실수로 지운 게시물, 상품, 회원 정보는 호스팅 업체의 백업으로도 되살리기 어렵습니다. 이런 사고를 막으려면 중요한 데이터는 삭제 전에 파일로 내보내거나, 삭제 권한을 제한하는 방법을 고려하세요.

백업 복원 시 자주 겪는 문제

문제	확인 사항
복원 후 사이트가 열리지 않음	복원한 백업 시점과 현재 워드프레스 버전의 호환성
업로드한 이미지가 깨짐	미디어 파일 경로가 절대 경로인지, 상대 경로로 교체했는지
데이터베이스 오류	백업 파일이 완전히 업로드되었는지, 복원 도구의 로그 확인

복원이 불가능한 경우 대처 방법

백업 파일이 없을 때: 전문 업체에 데이터 복구를 문의할 수 있지만 성공을 보장할 수 없습니다.
일부 데이터만 손실: 사이트맵이나 검색엔진 캐시를 활용해 게시물의 텍스트를 부분 복원할 수 있습니다.
고객 데이터 손실: 관련 법령에 따라 신고 및 고지 절차가 필요할 수 있습니다.

이와 같은 문제를 피하려면 평소에 백업이 실제로 복원되는지 테스트해야 합니다.

복원 테스트 단계

백업이 제대로 되었는지 확인하는 가장 확실한 방법은 실제 복원 테스트입니다. 다음 단계로 진행하세요.

테스트용 하위 도메인(예: test.example.com) 또는 로컬 개발 환경을 준비합니다.
가장 최근 전체 백업 파일을 다운로드합니다.
백업 도구의 ‘복원’ 기능이나 호스팅 업체의 스냅샷 복원 메뉴를 사용합니다.
사이트가 정상적으로 로드되는지 확인합니다.
최근 게시물이나 주문 내역이 포함되어 있는지 확인합니다.
관리자 계정으로 로그인하여 글쓰기, 이미지 업로드 등이 작동하는지 확인합니다.
테스트가 끝나면 테스트 사이트를 삭제하거나 외부 접근을 차단합니다.

이 테스트를 분기마다 실시하면 백업 파일 손상이나 복원 절차 오류를 조기에 발견할 수 있습니다. 테스트 결과를 기록해 두면 사고 발생 시 참고할 수 있습니다.

백업 계획 점검하기

마지막으로 현재 백업 계획이 3-2-1 규칙과 일치하는지 점검해 보세요. 아래 항목을 하나씩 확인하면 누락된 부분을 찾을 수 있습니다.

백업 복사본이 3개 이상 있습니까?
복사본이 서로 다른 저장 매체에 보관됩니까?
최소 1개는 오프사이트에 있습니까?
백업 파일에 암호화가 적용되어 있습니까?
매일 증분 백업과 매주 전체 백업이 자동으로 실행됩니까?
호스팅 업체의 백업 제약(문의, 직접 삭제 등)을 알고 있습니까?
최근 3개월 이내에 복원 테스트를 완료했습니까?

웹 운영과 관련된 더 다양한 가이드는 웹살림에서 확인할 수 있습니다.

참고 자료

웹사이트를 안전하게 백업하세요 - Youstable — 확인일 2026-07-27
아임웹 FAQ - 백업 및 복원 — 확인일 2026-07-27

소규모 사업자 웹사이트 백업 방법: 3-2-1 규칙부터 도구 활용까지