versioning은 backup이 아니야

둘은 다른 질문에 답해

versioning은 누가 무엇을 언제 바꿨고 이전 내용이 무엇이었는지 묻는 장치야. backup은 원본 장치와 장소가 사라져도 데이터를 되찾을 수 있는지 묻는 장치고. 둘 다 과거를 다루지만 실패 가설이 다르다.

같은 컴퓨터에 live vault, mirror, bare repo 세 개가 있어도 disk failure 하나면 전부 같이 사라져. commit 수가 만 개여도 독립 사본은 0개야. 반대로 version history 없는 offsite copy는 재난 복구에는 쓸모 있지만 어제의 잘못된 한 줄을 찾기 어렵지.

durability는 기존 chain의 책임이야

bounded product는 이미 있는 durability chain을 읽고 자기 역할을 추가하지 않아. 다른 장치, NAS, 암호화된 offsite처럼 독립 failure domain이 원본과 ledger를 보호한다면 Vestige는 그 위에 version trail을 얹으면 돼.

자기 Git remote를 하나 더 만든다고 안전해지는 것도 아니야. soul memory는 민감한 plaintext라 새 provider와 credential과 노출 표면이 생겨. backup 필요가 있다고 해서 제품이 마음대로 trust boundary를 넓힐 권리는 없어.

UI 단어도 invariant야

사용자가 Versioned를 Backed Up으로 읽을 수 있으면 상태표시는 거짓말이야. last commit time과 last durable backup time을 다른 필드로 보여주거나, durability를 이 제품이 관측하지 않는다면 아예 backup badge를 만들지 않아야 해.

이 구별은 장애 때 행동을 바꿔. history corruption이면 live에서 mirror를 rebuild하고, device loss면 backup owner가 restore하며, accidental edit이면 ledger에서 과거 blob을 골라 forward-write해. 한 단어로 뭉치면 세 runbook이 충돌해.

failure table을 써

파일 실수, history 손상, 디스크 고장, 건물 상실, credential 탈취를 행으로 놓고 어떤 사본이 살아남는지 표시해봐. versioning과 backup을 혼동한 설계는 대개 첫 두 행만 통과하고 나머지는 전부 같은 failure domain에 묶여 있어. 암호화와 restore rehearsal까지 있어야 durability 주장이 완성돼.

commit은 복구 지점일 수 있지만 독립 사본이라는 뜻은 아니야. version history와 durability는 owner도 증거도 다른 계약으로 표시해야 해.

Code

failure domain별 생존 사본 세기·python

copies = {
    "live": {"device": "laptop", "site": "home"},
    "mirror": {"device": "laptop", "site": "home"},
    "offsite": {"device": "server", "site": "remote"},
}

def survives_device_loss(item):
    return item["device"] != "laptop"

assert sum(survives_device_loss(v) for v in copies.values()) == 1

Exercise

보유한 version history와 backup을 각각 나열하고 disk loss, 계정 탈취, accidental edit 세 사건에서 살아남는지 표시해. 같은 칸에 전부 실패하면 사본 수가 아니라 failure domain을 늘려.

Hint

경로가 세 개여도 같은 장치와 credential 아래면 한 사본처럼 죽을 수 있어.

둘은 다른 질문에 답해

durability는 기존 chain의 책임이야

UI 단어도 invariant야

failure table을 써

Code

External links

Exercise

Progress

댓글 0