모든 사본이 한 방에 있다면 실제 기회는 몇 번일까?
두 번째 파일은 존재만으로 안심을 준다. 하지만 실패할 때 중요한 것은 사용할 수 있는 곳에 남아 있느냐다. 동기화 폴더, 옆의 드라이브, 다른 장소의 오프라인 사본은 기기 고장과 방의 손실, 실수로 삭제한 상황에 다르게 반응한다. 파일 수보다 공통 실패 조건을 살펴보자.
서로 따로 실패할 수 있을 때 사본은 더 유용하다.
세 사본의 의존성
가상 배치는 컴퓨터의 작업 사본, 다른 기기의 로컬 동기화 사본, 다른 장소의 분리된 사본으로 구성했다. 작업 사본은 컴퓨터 고장과 방 손실, 동기화 삭제에 영향을 받는다. 로컬 사본은 뒤의 두 조건을 공유한다. 다른 장소의 오프라인 사본은 이 세 조건을 공유하지 않는다고 정했다.
제품 조사가 아닌 단순한 시나리오다. 삭제 파일과 버전을 보관하는 동기화 서비스도 있고 계속 연결된 외장 드라이브도 있다. 원래 기기 없이는 접근할 수 없는 원격 사본도 있다. 가정을 밝혀 특정 배치를 모든 백업의 보편적 행동처럼 설명하지 않는다.
기기 실패와 공통 사건
영향받은 사본을 사건별로 제외했다. 작업 기기가 고장 나면 두 개, 방을 잃으면 다른 장소의 한 개, 두 동기화 위치에 삭제가 전파돼도 분리된 한 개가 남는다. 네 검사는 초기 수와 생존 사본을 확인한다. 사건 확률은 부여하지 않았다.
같은 방의 사본은 공통 사건에 노출되므로 독립 실패 확률을 곱하면 안 된다. 재해 빈도를 말하는 것이 아니라 하나의 사건이 별개처럼 보이는 여러 사본을 없앨 수 있음을 보여 준다. 독립성은 숫자 가정 이전에 설계 문제다.
동기화와 백업의 다른 역할
동기화는 변경을 여러 곳으로 전달해 편리하다. 유용한 수정뿐 아니라 실수도 전달될 수 있다. 버전을 보관하는 백업은 이전 상태로 돌아갈 기회를 준다. 무엇을 얼마나 오래 보관하고 원본을 손상시킨 사건이 버전도 삭제할 수 있는지가 중요하다.
삼이일 지침은 여러 사본, 서로 다른 저장 방식, 다른 장소의 사본을 권한다. 인증서가 아니라 출발점으로 보자. 다른 주소라도 접근할 수 있어야 하고 다른 매체도 복구 과정이 지원해야 한다. 구호 충족보다 실제 실패 관계가 중요하다.
남아 있어도 오래됐을 수 있다
오프라인 사본은 지난달 상태인데 잃은 기기에 최근 일주일의 작업이 있다면 오래된 사본은 가치가 있어도 전달되지 않은 작업을 복구하지 못한다. 최근 작업 중 얼마나 다시 만들 수 있는지 정하고 백업 주기와 완료 확인에 반영하자.
암호화 키, 계정 복구, 파일을 여는 소프트웨어도 고려해야 한다. 보존한 압축 파일도 복호화 키가 없으면 쓸 수 없을 수 있다. 필요한 접근 정보는 보호하면서 별도 경로로 사용할 수 있게 둔다. 설명을 단순하게 하려고 암호화를 약화시키지 말고 복구 조건을 계획에 넣자.
작은 복구를 연습하자
무해한 대표 파일 몇 개를 별도 위치로 복원한다. 이름과 내용, 기대한 버전인지 확인하면 원본을 덮어쓰지 않고 폴더 선택이나 보존 정책의 오해를 발견할 수 있다. 작은 연습이 모든 복구를 보장하지는 않아도 녹색 상태 표시보다 더 많은 것을 확인한다.
중요한 자료는 어떤 사본을 어디서 구하고 무엇으로 읽을지 적어 두자. 주 기기를 쓸 수 없을 때도 계획을 볼 수 있어야 한다. 서비스나 기기, 생활 환경을 바꾸면 다시 검토한다. 압박을 받는 상황에서도 사람이 따라갈 수 있어야 설계가 유용하다.