3-2-1 백업 규칙, 사본이 셋이면 충분할까?

운영 데이터베이스가 있고, 데이터베이스 서비스가 매일 자동 백업을 해 주고, 같은 계정의 파일 저장소에 덤프를 하나 더 올려 둡니다. 사본은 셋입니다. 저장 방식도 데이터베이스와 파일 저장소로 둘입니다. 3-2-1 규칙의 숫자는 모두 맞습니다.

그런데 그 계정의 관리자 비밀번호가 새거나, 결제가 밀려 계정이 정지되면 셋은 한꺼번에 사라집니다. 숫자는 맞았는데 규칙이 막으려던 일은 막지 못한 구성입니다. 저는 3-2-1을 「사본 개수 규칙」으로 읽는 데서 이 차이가 생긴다고 봅니다.

처음 정의가 실제로 요구한 것

3-2-1이 널리 인용되는 형태는 미국 US-CERT(지금의 CISA)가 2012년에 낸 「Data Backup Options」에 있습니다. 문서는 출처로 사진가 Peter Krogh의 『The DAM Book』 2판(2009)을 각주에 답니다. 원문은 이렇습니다.

3 – Keep 3 copies of any important file: 1 primary and 2 backups.
2 – Keep the files on 2 different media types to protect against different types of hazards.
1 – Store 1 copy offsite (e.g., outside your home or business facility).

두 번째 줄의 끝이 핵심입니다. 매체를 둘로 나누는 까닭이 「서로 다른 종류의 위험」을 막기 위해서라고 적혀 있습니다. 세 번째 줄의 바깥도 건물 밖, 곧 화재나 도난처럼 건물 하나를 통째로 덮치는 위험을 피하라는 뜻입니다. 규칙의 숫자는 개수를 말하지만, 그 숫자가 지키려는 것은 사본들이 같은 사고로 함께 사라지지 않는 것입니다.

2012년의 위험은 디스크 고장, 화재, 도난이었습니다. 데이터가 클라우드 계정 안에 사는 지금은 위험의 목록이 바뀌었고, 숫자만 그대로 옮기면 빈틈이 생깁니다.

사본마다 「무엇이 터지면 같이 사라지나」

사본이 같은 사고에 함께 무너지는 범위를 장애 도메인(failure domain)이라고 부릅니다. 3-2-1을 지금 환경에 맞게 읽는 방법은 사본마다 이 범위를 적어 보는 것입니다.

사고	같은 서버의 사본	같은 업체·같은 계정의 다른 서비스	다른 업체의 다른 계정
디스크·서버 고장	사라짐	남음	남음
리전(데이터센터) 장애	사라짐	같은 리전이면 사라짐	남음
계정 탈취·정지·결제 중단	사라짐	사라짐	남음
업체의 큰 사고·서비스 종료	사라짐	사라짐	남음
사람의 실수가 복제됨	사라짐	복제 방식에 따라 사라짐	열쇠를 나눴다면 남음

가운데 칸이 이 글의 요점입니다. 데이터베이스와 파일 저장소는 「서로 다른 매체」처럼 보이지만, 같은 계정 안에 있으면 계정 단위 사고에서는 한 사본과 같습니다. 오늘날 3-2-1의 「1」은 건물 밖보다 계정 밖, 업체 밖으로 읽어야 맞다고 저는 봅니다.

동기화와 복제를 백업으로 셈하지 않는 기준

같은 문서가 짚는 함정이 하나 더 있습니다. 주기적으로 최신 상태로 덮어쓰는 롤링 백업을 두고 이렇게 적었습니다.

Rolling backups can silently propagate any corruption or malware in the primary files to the backup files.

데이터베이스의 읽기 복제본, 클라우드 드라이브 동기화, 미러링 디스크가 모두 여기에 해당합니다. 원본에서 표를 잘못 지우면 복제본에서도 곧바로 지워집니다. 이것들은 고장에는 강하지만 실수와 악성 코드에는 사본이 아닙니다. 그래서 사본을 셀 때 「원본의 변경이 저절로 따라오는가」를 먼저 묻습니다. 따라온다면 고가용성 장치이지 백업이 아닙니다.

뒤에 붙은 1과 0

랜섬웨어가 흔해지면서 백업 업체들은 숫자를 덧붙였습니다. Veeam이 퍼뜨린 3-2-1-1-0이 대표적입니다.

뒤의 1은 지울 수 없는 사본 하나입니다. 공격자는 원본을 잠그기 전에 백업부터 지웁니다. 백업 작업이 쓰는 열쇠로 지난 백업까지 지울 수 있다면, 그 열쇠 하나가 새는 순간 모든 사본이 같은 장애 도메인에 들어갑니다. 객체 저장소의 보존 잠금이 이 칸을 채우는 흔한 방법입니다. AWS S3의 Object Lock은 compliance 모드에서 보존 기간이 끝날 때까지 루트 사용자도 그 객체를 지우거나 덮어쓰지 못하게 합니다. 테이프를 빼서 금고에 두는 오프라인 보관도 같은 칸입니다.

마지막 0은 복원 시험에서 오류 0입니다. 백업 파일이 있다는 사실과 그 파일로 시스템이 다시 선다는 사실은 다릅니다. 덤프가 중간에 끊겼거나, 복원할 판의 데이터베이스가 파일 형식을 읽지 못하거나, 암호화 열쇠를 잃었다면 파일은 있어도 백업은 없습니다. 저는 되살려 보지 않은 백업은 셈에 넣지 않습니다.

4-3-2 같은 변형들

숫자를 더 늘린 형태도 있습니다. Backblaze가 정리한 글에 소개된 4-3-2는 사본 넷을 세 곳에 두고 그중 둘을 바깥에 둡니다. 재해 복구를 맡기는 관리 업체들이 쓰는 형태입니다. 바깥 사본을 서로 다른 업체 둘에 나누는 3-2-2 같은 이름도 쓰입니다.

이 변형들은 표준이라기보다 같은 생각을 더 촘촘히 적용한 권장안입니다. 숫자가 늘어날수록 비용과 관리할 열쇠도 늘어납니다. 어디까지 갈지는 아래 두 질문의 답이 정합니다.

개수 규칙이 답하지 않는 두 질문

첫째는 얼마까지 잃어도 되고, 얼마 안에 되살려야 하나입니다. 복구 목표 시점(RPO)과 복구 목표 시간(RTO)입니다. 매일 한 번 뜨는 백업은 최악의 경우 하루치 입력을 잃습니다. 하루 몇 건이 들어오는 시스템과 하루 수백 건이 들어오는 시스템에서 그 하루의 무게는 다릅니다. 3-2-1은 사본을 어디에 둘지만 말하고, 얼마나 자주 뜰지는 말하지 않습니다.

둘째는 얼마나 오래 남기나입니다. 사본을 셋 두어도 모두 7일치만 남긴다면, 열흘 전에 생긴 잘못을 발견한 날에는 이미 잘못된 상태의 사본만 남아 있습니다. 그래서 보관을 층으로 나눕니다. 매일 것은 몇 주, 매주 것은 몇 달, 매달 것은 1년처럼 두는 방식을 GFS(Grandfather-Father-Son)라고 부릅니다. 개수와 보관 기간은 서로 다른 축이고, 둘 다 정해야 계획이 됩니다.

관리형 데이터베이스의 자동 백업을 셈하는 법

관리형 데이터베이스 서비스는 대부분 일일 백업이나 특정 시점 복구를 제공합니다. 이것은 좋은 사본입니다. 서버 고장과 최근 며칠의 실수에는 가장 빨리 돌아오는 길입니다.

다만 표의 가운데 칸에 들어갑니다. 서비스 업체의 계정 안에 있고, 보관 기간은 요금제가 정하고, 계정이 사라지면 함께 사라집니다. 그래서 저는 업체 백업을 「첫 번째 방어선」으로 세고, 업체와 계정 밖의 사본을 따로 하나 둡니다. 둘은 서로를 대신하지 않습니다. 업체 백업은 빠르고, 바깥 사본은 끝까지 남습니다.

바깥 사본은 업체를 나간 순간부터 그 저장소를 여는 열쇠가 곧 데이터를 여는 열쇠가 됩니다. 그래서 올리기 전에 암호화하고, 잠그는 열쇠와 여는 열쇠를 나누는 편을 권합니다. 매일 백업을 뜨는 작업은 공개키로 잠그기만 하고, 여는 비밀키는 복구할 때 사람만 꺼내 씁니다. 이때 비밀키를 잃으면 바깥 사본 전부를 잃으므로, 비밀키 보관이 이 방식의 실제 비용입니다.

제가 사본을 세는 방식

사본마다 한 줄씩 적습니다. 「이 사본은 무엇이 터지면 같이 사라지는가」. 두 사본의 줄이 같다면 그 둘은 한 사본입니다. 그렇게 세고도 셋이 남고, 그중 하나가 계정과 업체 밖에 있고, 하나는 지울 수 없고, 최근에 실제로 되살려 본 적이 있다면 3-2-1-1-0을 채운 것입니다.

이 셈법이 모든 경우에 맞는다고 확신하지는 않습니다. 같은 업체 안에서도 리전과 계정을 완전히 나눠 두는 대기업 구성은 표의 칸 경계가 다르게 그어집니다. 다만 사본 개수부터 세는 습관보다는, 같이 사라지는 범위부터 묻는 습관이 빈틈을 먼저 보여 준다고 봅니다.