홈페이지 데이터 백업, 사이트 잃지 않는 3-2-1 규칙

홈페이지 데이터 백업은 파일과 데이터베이스를 같은 시점으로 한 세트로 복사해 사고가 나도 사이트를 그대로 되살릴 수 있게 준비해 두는 일입니다. 2026년 기준으로 웹사이트는 코드·이미지 같은 파일과 글·회원·주문이 담긴 데이터베이스가 짝을 이뤄 돌아갑니다. 한쪽만 백업하면 복구가 되지 않습니다. 이 글은 개인 휴대폰 백업이 아니라 외주로 만든 홈페이지를 잃지 않는 방법을, 백업의 구성과 규칙, 그리고 계약에서 확인할 항목까지 발주자 관점에서 정리했습니다.

핵심 요약

• 웹사이트 백업은 파일과 데이터베이스를 같은 시점으로 한 세트로 받아야 복구됩니다. 한쪽만 있으면 사이트가 안 뜨거나 데이터가 깨집니다.
• 백업의 기본은 3-2-1 규칙입니다. 사본 3벌, 서로 다른 매체 2종, 그중 1벌은 물리적으로 떨어진 곳에 둡니다.
• 백업 방식은 전체·증분·차등으로 나뉘고 저장 공간과 복원 속도가 서로 반대로 움직입니다.
• 복구해 본 적 없는 백업은 백업이 아닙니다. 정기적인 복구 테스트가 있어야 실제로 되살릴 수 있습니다.
• 일정 규모부터는 백업·복구 계획 수립이 권장이 아니라 법적 의무입니다. 외주 계약서에 백업 주체·주기·소유권을 명시해 두세요.

홈페이지 백업은 개인 파일 백업과 다르다

휴대폰 사진을 클라우드에 올려 두는 것과 홈페이지 백업은 성격이 다릅니다. 웹사이트는 두 덩어리로 이뤄져 있습니다. 하나는 코드·이미지·업로드 파일 같은 파일 묶음이고 다른 하나는 게시글·회원·주문 기록이 들어가는 데이터베이스입니다. 이 둘은 같은 시점의 짝으로 맞아야 사이트가 정상으로 뜹니다. 데이터베이스만 받아 두면 화면이 깨지고 파일만 받아 두면 글과 회원 정보가 사라집니다.

그래서 워드프레스든 직접 만든 사이트든, 제대로 된 백업은 "파일 전체 + 데이터베이스 덤프"를 한 묶음으로 받는 것을 뜻합니다. 데이터베이스는 흔히 mysqldump 같은 명령으로 통째로 내보냅니다. 여기에 더해 도메인과 각종 계정의 소유권, 소스코드까지 발주자 명의로 확보돼 있어야 진짜 백업이라 할 수 있습니다. 웹사이트가 어떻게 구성되는지는 데이터베이스가 무엇인지 설명한 글과 함께 보면 이해가 빠릅니다.

백업의 기본 원칙 — 3-2-1 규칙

백업의 세계에서 가장 널리 통하는 원칙이 3-2-1 규칙입니다. 미국 정부의 침해사고대응팀(US-CERT)이 2012년 데이터 백업 안내 문서에서 정리한 뒤 업계 표준처럼 자리 잡았습니다. 내용은 단순합니다. 중요한 파일은 원본 1벌과 백업 2벌을 합쳐 3벌을 두고 서로 다른 2종의 매체에 나눠 저장하며 그중 1벌은 물리적으로 떨어진 곳(오프사이트)에 보관합니다.

세 가지를 다 지켜야 하는 이유는 각 항목이 서로 다른 사고를 막기 때문입니다. 사본을 여러 벌 두는 것은 파일 하나가 손상돼도 다른 사본으로 복구하려는 장치입니다. 매체를 나누는 것은 디스크 고장 같은 한 종류의 사고가 모든 사본을 한꺼번에 삼키지 못하게 합니다. 오프사이트 보관은 화재·침수·도난처럼 한 장소를 통째로 잃는 상황에 대비합니다. 최근에는 여기에 변경 불가능한 사본 1벌과 복구 테스트로 확인한 오류 0을 더한 3-2-1-1-0 방식도 쓰이는데, 이는 랜섬웨어 대응을 강화한 업계 확장판입니다.

사본을 실제로 어디에 두느냐도 이 규칙과 이어집니다. 흔히 쓰는 곳은 세 갈래입니다. 클라우드 스토리지는 오프사이트 조건을 자연스럽게 채우고 접근이 편하지만 용량에 따라 비용이 붙습니다. 외장 하드나 NAS 같은 장치는 손안에 두고 관리하기 좋은 대신 그 장치 자체가 고장 나거나 도난당할 위험이 있습니다. 다른 지역의 서버에 보관하는 방법도 있습니다. 어느 하나만 쓰기보다 매체를 나눠 두라는 것이 3-2-1의 핵심입니다. 그리고 백업은 사람이 매번 손으로 챙기면 언젠가 빠뜨리게 되니, 자동으로 돌아가고 실패하면 알려 주는 구조로 만들어 두는 편이 안전합니다.

전체·증분·차등, 백업 종류 고르기

같은 3벌을 두더라도 매번 무엇을 복사하느냐에 따라 방식이 갈립니다. 전체·증분·차등 세 가지가 있고 저장 공간과 복원 속도가 서로 맞바꿈 관계입니다.

방식	매번 복사하는 것	저장 공간	복원 속도
전체 백업	데이터 전부	가장 큼	가장 빠름(사본 1개만 필요)
증분 백업	직전 백업 이후 바뀐 것	가장 작음	느림(전체+모든 증분을 순서대로)
차등 백업	마지막 전체 이후 바뀐 것 전부	중간	빠름(전체+최신 차등 1개)

실무에서는 셋을 섞어 씁니다. 주기적으로 전체 백업을 한 번 뜨고 그 사이는 증분이나 차등으로 채우는 식입니다. 증분은 백업이 가장 빠르고 공간을 아끼지만 복원할 때 전체와 모든 증분을 차례로 붙여야 해서 사슬 하나만 손상돼도 위험합니다. 차등은 회차가 갈수록 사본이 커지는 대신, 복원은 전체와 최신 차등 하나만 있으면 되니 더 단순합니다. "복원을 얼마나 빨리, 얼마나 확실하게 하고 싶은가"가 선택의 기준입니다.

얼마나 자주, 얼마나 빨리 — 백업 주기와 RPO·RTO

백업 주기는 감이 아니라 두 개의 목표치로 정합니다. 하나는 RPO(복구 목표 시점)로, 데이터를 최대 얼마까지 잃어도 되는지를 시간으로 나타냅니다. RPO가 한 시간이면 최악의 경우 한 시간치 데이터 손실을 감수한다는 뜻입니다. 그러면 최소 한 시간에 한 번은 백업해야 합니다. 다른 하나는 RTO(복구 목표 시간)로, 사고 뒤 다시 정상으로 돌아오기까지 허용하는 시간입니다. RTO가 짧아야 한다면 복구를 빨리 끝낼 방식과 인프라를 미리 갖춰 둬야 합니다.

쇼핑몰처럼 주문이 실시간으로 쌓이는 사이트는 RPO를 짧게 잡아 백업을 자주 떠야 하고 몇 주에 한 번 소식만 올리는 소개형 사이트라면 하루 한 번으로도 충분한 경우가 많습니다. 정답이 하나로 정해져 있지 않으니, 내 사이트에서 하루치 데이터가 날아가면 얼마나 아픈지를 먼저 따져 주기를 정하는 편이 좋습니다.

백업만 있으면 안전하다는 착각 — 복구 테스트

발주자가 가장 자주 하는 오해가 "백업 파일이 있으니 안전하다"는 생각입니다. 복원해 본 적 없는 백업은 백업이라 부르기 어렵습니다. 데이터베이스 덤프가 중간에 손상돼 있거나, 파일 일부가 빠졌거나, 버전이 맞지 않는 문제는 실제로 복구를 시도하는 순간에야 드러납니다. 그래서 정기적으로 백업을 실제 환경에 되살려 보는 복구 테스트가 있어야 "백업 보유"가 "복구 가능"으로 이어집니다. 웹사이트를 인수인계하다 보면 소스코드는 받았는데 데이터베이스 백업이 빠져 있어 사이트가 아예 안 뜨는 경우를 만나는데, 이런 문제도 한 번이라도 복원을 해봤다면 미리 잡혔을 것입니다. 복구 테스트는 거창할 필요 없이, 백업 파일을 임시 공간에 실제로 되살려 화면과 데이터가 정상인지 눈으로 확인하는 정도면 충분합니다.

또 하나 짚어 둘 오해는 호스팅사 백업입니다. 카페24나 가비아 같은 호스팅사도 백업을 하지만 그것은 대체로 자기 인프라 장애를 복구하려는 목적이지 고객 데이터를 보장하는 서비스가 아닙니다. 보관 주기가 며칠로 짧거나 유료 옵션인 경우가 많고 계정 정지·해킹·설정 실수로 인한 손실은 막지 못하기도 합니다. 무엇보다 그 백업이 원본과 같은 계정·서버 안에 있으면, 그 서버가 통째로 문제가 날 때 백업도 같이 사라집니다. 3-2-1 규칙의 오프사이트 원칙이 깨지는 셈입니다.

구분	호스팅사 기본 백업	독립(오프사이트) 백업
주목적	호스팅사 인프라 복구	내 데이터 보존
보관 위치	대개 같은 계정·서버	물리적으로 분리된 곳
계정 정지·해킹 시	함께 잃을 수 있음	영향 받지 않음
복구 테스트	내가 확인 불가한 경우 많음	내가 직접 주기적으로 확인

그래서 호스팅사 백업만 믿지 말고 원본과 분리된 독립 사본을 따로 확보해 두는 것이 안전합니다.

외주·유지보수 계약에서 확인할 백업 조항

외주로 만든 사이트라면 백업은 결국 계약의 문제로 이어집니다. 업체가 사라져도 내 사이트를 잃지 않으려면, 아래 항목을 계약과 검수 단계에서 확인하세요.

1. 백업 주체·주기·보관 위치를 계약서에 명시합니다. "백업하고 있습니다"라는 말이 아니라 누가, 며칠 간격으로, 어디에 두는지를 적습니다.
2. 복구 테스트를 누가 언제 하는지 책임을 정합니다. 최소한 인수 시점에 실제 복원이 되는지 함께 확인합니다.
3. 소스코드와 데이터베이스를 발주자가 받을 수 있게 합니다. 필요할 때 전체 파일과 덤프를 인계받는 조건을 넣습니다.
4. 도메인·호스팅·각종 계정의 소유권을 발주자 명의로 확보합니다. 계정이 업체 명의면 백업이 있어도 접근하지 못합니다.
5. 계약이 끝날 때 데이터를 온전히 돌려받는 절차를 정합니다. 종료 후 데이터 반환과 파기 조건을 함께 적습니다.

이 항목들은 유지보수 계약과 맞물립니다. 백업과 복구를 월 유지보수 범위에 넣을지, 별도로 둘지에 따라 비용과 책임이 달라지므로 유지보수 계약을 어떻게 정하는지와 함께 검토하는 편이 좋습니다. 제작 단계부터 백업·소유권을 계약에 담고 싶다면 노바랩의 홈페이지 제작 서비스가 어떤 인수인계 항목을 다루는지 확인해 보세요.

백업 비용이 얼마냐는 질문도 자주 나오는데, 정해진 금액표가 있는 게 아니라 저장 용량, 백업 주기, 자동화와 복구 테스트를 어디까지 하느냐로 갈립니다. 소개형 사이트를 하루 한 번 클라우드에 백업하는 정도는 부담이 크지 않지만 주문이 많은 쇼핑몰을 짧은 주기로 백업하고 정기 복원까지 확인하려면 손이 더 들어갑니다. 그래서 견적을 볼 때는 "백업 포함"이라는 한 줄만 보지 말고 그 안에 주기와 보관 위치, 복구 테스트가 들어 있는지를 나눠 물어야 실제 비용을 비교할 수 있습니다.

백업은 법적 의무이기도 하다 — 개인정보와 규제

회원 정보나 주문 내역처럼 개인정보를 다루는 사이트라면, 백업은 단순한 권장 사항을 넘어섭니다. 한국의 개인정보보호위원회 고시인 개인정보의 안전성 확보조치 기준 제11조는 재해·재난에 대비해 개인정보처리시스템의 백업 및 복구 계획을 마련하도록 정하고 있습니다. 이 조항은 10만 명 이상의 개인정보를 처리하는 대기업·중견기업·공공기관, 또는 100만 명 이상을 처리하는 중소기업·단체에 적용됩니다. 규모가 작은 소상공인 사이트에 제11조가 곧바로 강제되지는 않지만 접근 통제나 접속 기록 같은 다른 안전조치는 폭넓게 적용됩니다.

흥미로운 점은 이 규제 안내서가 백업·복구 계획의 예시로 복구 목표 시점과 복구 목표 시간, 즉 앞서 설명한 RPO와 RTO를 들고 있다는 것입니다. 규제 기준조차 "백업만 있으면 된다"가 아니라 "얼마나 잃어도 되고 얼마 만에 되살릴 것인가"를 계획에 담으라고 요구하는 셈입니다. 개인정보를 다룬다면 개인정보보호법이 운영자에게 요구하는 의무와 함께 백업 계획을 짚어 두는 것이 안전합니다.

자주 하는 오해와 상황별 판단

지금까지 나온 오해를 정리하면 세 가지입니다. 첫째, 호스팅사가 알아서 다 해준다는 생각인데, 호스팅사 백업은 대개 자기 인프라용이라 독립 사본을 따로 둬야 합니다. 둘째, 백업 파일만 있으면 안전하다는 착각으로, 복구 테스트 없이는 복원 여부를 장담하지 못합니다. 셋째, 홈페이지 백업은 데이터베이스만 받으면 된다는 오해인데, 파일과 데이터베이스를 같은 시점의 한 세트로 받아야 합니다.

가상 예시로 감을 잡아 보겠습니다. 어떤 쇼핑몰이 서버 사고로 데이터가 날아가 급히 호스팅사에 복구를 요청했다고 해 보겠습니다. 알고 보니 호스팅사 백업은 사흘 주기였고 마지막 백업 이후 들어온 주문은 되살릴 방법이 없었습니다. 만약 이 쇼핑몰이 매일 독립 백업을 뜨고 한 달에 한 번 복원을 테스트했다면, 손실은 하루치 안쪽으로 줄었을 것입니다. 실제 피해 규모는 사이트마다 다르지만 백업 주기가 곧 최악의 손실 크기를 정한다는 원리는 같습니다.

백업이 왜 이렇게 중요한지는 사고 통계가 말해 줍니다. 버라이즌이 발간한 2024년 데이터 침해 조사 보고서에 따르면 전체 침해의 약 3분의 1이 랜섬웨어나 갈취와 얽혀 있었고 관련 사고의 피해 중앙값은 약 4만 6천 달러였습니다. 랜섬웨어는 데이터를 인질로 잡는 공격이라, 되살릴 수 있는 독립 백업이 있느냐가 대응의 갈림길이 됩니다. 상황별로 보면, 개인정보나 결제가 오가는 사이트는 짧은 주기의 독립 백업과 정기 복구 테스트를 갖추는 편이 맞고 변동이 드문 소개형 사이트라면 하루 한 번 독립 백업에 분기 복원 확인 정도로도 큰 위험을 덜 수 있습니다.