다락방 씨앗은 싹이 텄는데 네 백업은 열리긴 하냐, 복사부터 불변 저장소까지 보는 백업 짧은 역사

언제부터 있었는지도 모르는 씨앗 자루를 다락에서 꺼내 거름 더미에 던졌더니 싹이 텄단다. 네 백업 폴더는 마지막으로 열어본 게 언제냐.

• 보관해 둔 것과 되살릴 수 있는 것은 별개고, 그 간극을 다루는 기술이 백업이다.
• 백업은 파일 복사에서 테이프, 증분, 스냅샷, 오프사이트와 불변 저장소 순으로 갔다. 앞 방식이 사고를 낼 때마다 다음 방식이 나왔다.
• 지금 기준은 3-2-1이다. 거기에 복원 테스트가 빠지면 다락방 자루와 다를 게 없다.

복사본이 없으면 그냥 한 번 사는 거였다

기사 속 이탈리아 농부는 밀 얘기를 한다. 20세기에 수확량 높은 개량종이 전국으로 퍼지면서, 키가 크고 이삭이 일곱 개씩 달리는 옛 밀 같은 건 밭에서 밀려났다. 한 품종에 몰아넣으면 수확은 늘지만, 병 하나가 돌면 같이 쓰러진다.

데이터도 똑같았다. 초창기에는 파일이 디스크 한 장에 한 벌만 있었다. 지우면 끝이고, 디스크가 죽으면 끝이고, 프로그램이 버그로 덮어써도 끝이었다.

그래서 사람들은 뭘 했냐. 중요한 건 종이로 뽑아 두거나, 플로피에 손으로 옮겨 담거나, 대형 컴퓨터라면 밤마다 자기 테이프에 통째로 쏟아부었다. 방식은 단순했다. 복사본을 하나 더 만든다. 그게 전부였다.

“그럼 그냥 복사하면 되는 거 아니냐”고 물을 수 있다. 맞다. 초기 백업이 정확히 그거였다. 그게 왜 부족한지는 직접 만들어 보면 바로 보인다.

그때 방식 그대로 짜 보면

파이썬 3 표준 라이브러리만 쓴 “매일 한 번 통째로 압축해서 옆 폴더에 두는” 스크립트다. 옛날 크론탭에 걸려 있던 쉘 스크립트의 파이썬 버전쯤으로 보면 된다.

# Python 3.x, 표준 라이브러리만 사용
import shutil
import datetime
import pathlib

SRC = pathlib.Path("~/project").expanduser()
DST = pathlib.Path("/mnt/data/backup")  # 원본과 같은 디스크


def backup():
    DST.mkdir(parents=True, exist_ok=True)
    stamp = datetime.date.today().isoformat()
    base = DST / f"backup-{stamp}"
    shutil.make_archive(str(base), "gztar", root_dir=SRC)
    print("done:", base)


if __name__ == "__main__":
    backup()

돌아가긴 한다. 그리고 이 스크립트가 “done”을 찍는 순간 대부분의 사람은 안심하고 잊는다. 그 안심이 문제다.

여기서 아픈 지점:

• “done”은 파일을 썼다는 뜻이지, 그 파일이 열린다는 뜻이 아니다. 압축이 중간에 깨졌어도 이 코드는 모른다.
• 원본과 같은 디스크라서, 디스크가 죽으면 원본과 백업이 같이 죽는다. 같은 날 두 번 돌리면 먼저 만든 것도 덮어쓴다.
• 매번 전체를 복사한다. 하루 1GB씩이면 한 달에 30GB가 쌓이고, 바뀐 건 10MB뿐이어도 비용은 같다.

그래서 어떻게 진화했나

흐름을 먼저 한 장으로 보자. 화살표는 “앞 방식의 불편이 다음 방식을 만들었다”는 뜻이다.

flowchart LR
    A["수동 복사"] --> B["테이프 순환"]
    B --> C["증분과 hardlink 스냅샷"]
    C --> D["RAID를 백업으로 착각"]
    D --> E["파일시스템 스냅샷과 중복 제거"]
    E --> F["오프사이트와 불변 저장소"]

읽는 법: 왼쪽에서 오른쪽으로 시대순이다. 중간의 RAID는 해법이 아니라 “다들 한 번씩 빠지는 함정”이라 따로 넣었다.

첫 단계는 테이프다. 불편은 사람이 복사하는 걸 까먹는다는 것이었다. 해법은 밤마다 자동으로 전체를 테이프에 덤프하고, 테이프를 요일별로 돌려 쓰면서 한 벌은 건물 밖으로 내보내는 것이었다. 새로 생긴 문제는 느리다는 것, 그리고 테이프가 읽히는지 확인할 방법이 사실상 복원뿐이라는 것이었다.

두 번째는 증분이다. 불편은 전체 복사가 시간과 공간을 잡아먹는다는 것이었다. 해법은 바뀐 파일만 옮기는 것이었고, 90년대에 나온 rsync가 이걸 대중화했다. 명령 한 줄로 “안 바뀐 파일은 이전 백업과 같은 파일을 가리키게” 만들 수도 있다.

# 어제 백업과 같은 내용은 하드링크로 공유하고, 바뀐 것만 새로 복사
rsync -a --link-dest=/backup/2026-11-01 /data/ /backup/2026-11-02/

날짜 폴더마다 전체가 있는 것처럼 보이는데 실제 디스크는 바뀐 만큼만 쓴다. 새로 생긴 문제는 증분 체인이다. 방식에 따라 중간 하나가 깨지면 뒤에 쌓인 것이 줄줄이 못 쓰게 될 수 있다.

세 번째는 RAID를 백업으로 착각하는 단계다. 디스크 두 장에 똑같이 쓰면 한 장이 죽어도 산다. 그래서 “이미 이중화돼 있는데 무슨 백업이냐”는 말이 나온다.

그게 왜 위험하냐. RAID는 지운 것도 두 장에 똑같이, 즉시 지운다. 실수로 rm -rf를 쳐도, 버그가 데이터를 망가뜨려도, 랜섬웨어가 암호화해도 두 장 모두 같은 상태가 된다. RAID는 장비 고장 대비고 백업은 “과거로 돌아가는 능력”이다. 둘은 풀려는 문제가 다르다.

네 번째는 스냅샷과 중복 제거다. 불편은 과거 시점으로 돌아가고 싶은데 전체 복사는 비싸다는 것이었다. 해법은 2000년대에 보편화된 파일시스템 스냅샷이다. 블록 단위로 “그 시점의 상태”를 거의 공짜로 찍어 둔다.

여기에 2010년대 들어 restic이나 borg 같은 도구가 데이터를 조각내서 같은 조각은 한 번만 저장하는 중복 제거를 일반 개발자 손에 쥐여 줬다. 새로 생긴 문제는, 같은 장비 안의 스냅샷은 그 장비와 함께 죽는다는 것이다. 불이 나면 스냅샷도 같이 탄다.

다섯 번째가 지금이다. 다른 장소, 다른 계정에 복사본을 두고, 거기엔 덮어쓰기와 삭제를 일정 기간 막는 설정을 건다. 클라우드 오브젝트 스토리지가 2000년대 중반부터 이걸 싸게 만들었다. 새로 생긴 문제는 비용, 접근 키 관리, 그리고 복원할 때 데이터를 끌어내리는 시간과 요금이다.

세대별로 한 번에 비교하면 이렇다.

시대	방식	장점	한계
초창기	수동 복사, 종이	이해하기 쉽다	까먹고, 같은 장소에 둔다
메인프레임 이후	테이프 순환	자동, 오프사이트 가능	느리고 복원 검증이 어렵다
90년대 이후	증분, hardlink	공간과 시간 절약	체인이 깨지면 연쇄 피해
2000년대	파일시스템 스냅샷	시점 복귀가 빠르다	같은 장비에 묶여 있다
2010년대 이후	중복 제거, 클라우드	싸고 멀리 둔다	키, 비용, 복원 시간

지금은 어떤가

기사로 돌아가 보자. 농부는 자루를 열고 “밑져야 본전”이라며 심어 봤다. 이게 사실 백업 업계가 제일 말 안 듣는 습관인 복원 테스트다. 심어 보기 전에는 그 씨앗이 살아 있는지 아무도 몰랐다.

그리고 싹이 텄다고 끝도 아니었다. 빵을 구웠더니 반죽이 잘 부풀지 않았다고 한다. 데이터로 번역하면, 복원은 됐는데 그걸 읽는 프로그램이 안 맞거나 버전이 달라서 못 쓰는 경우다. 백업은 “파일이 돌아왔다”가 아니라 “서비스가 다시 뜬다”까지 확인해야 완성이다.

한 가지 짚자. 댓글에는 이 밀이 새로 발견된 종이 아니라 이미 널리 알려진 계통의 재발견일 수 있고, 기사도 정확한 품종을 안 밝혔다는 지적이 있다. 그래서 “고대 밀의 기적”으로 읽을 필요는 없다. 다만 개량종 하나로 쏠렸을 때 다양성이 얼마나 쉽게 사라지는지, 그리고 누군가 한 벌 남겨 뒀기에 되살릴 수 있다는 점은 백업과 구조가 같다.

지금 업계의 기준은 3-2-1이다. 복사본 3개, 서로 다른 매체 2종류, 그중 1개는 다른 장소. 거기에 요즘은 지우지 못하게 잠근 복사본 하나를 더 두는 게 표준 대응이 됐다.

읽는 법: 왼쪽은 복사본이 하나뿐인 예전 방식, 오른쪽은 3-2-1을 단순화한 구조다. 개념도(실제 수치 아님)이고, 점선 상자가 장소와 계정을 분리한 복사본이다.

지금 고를 수 있는 선택지를 비교하면 이렇다. 개인이나 작은 팀이면 restic이나 borg로 중복 제거 백업을 만들어 클라우드 저장소에 두는 게 가성비가 좋다. 서버가 많고 DB가 크면 클라우드의 관리형 스냅샷과 백업 서비스가 편하지만, 같은 계정 안에만 두면 계정 사고에 같이 당한다.

테이프는 죽은 게 아니다. 대용량을 오래 보관하는 곳에서는 지금도 쓰고, 네트워크에서 물리적으로 떨어져 있다는 점이 랜섬웨어 앞에서 오히려 장점이다. 선택지가 늘었다고 문제가 풀린 건 아니고, 늘 같은 곳에서 터진다. 복사는 했는데 복원은 안 해 본 곳이다.

백업 점검은 파일 개수가 아니라 복원 시간으로 해라. 한 번도 안 심어 본 자루는 그냥 자루다.

---

원문: An Italian farmer found some unknown seeds in his attic and planted them (via hn)