백업 파일이 있다고 복구된 것은 아니었다: 두 저장소에서 byte 일치와 격리 import까지 검증

📝 한줄 요약

Mac mini의 Hermes 전체 상태를 로컬과 외부 저장소에 각각 암호화해 보관하고, 두 곳에서 실제 복원까지 수행했습니다.

바쁘시면 이것만 읽어도 돼요:

• MacBook 로컬 저장소와 Backblaze B2 외부 저장소에 Hermes 백업을 따로 만들었습니다.

• 백업 파일의 존재가 아니라 snapshot 조회와 저장소 전체 무결성을 검사했습니다.

• 두 저장소에서 복원한 ZIP이 원본과 byte 단위로 같은지 확인했습니다.

• 로컬 복원본은 일회용 Hermes 환경에 import해 설정과 인증 내용까지 비교했습니다.

• import 뒤 설정 파일 권한이 644로 느슨해지는 문제를 발견해 600으로 교정했습니다.

• 자동 백업과 장기 실패 알림은 아직 검증하지 않은 다음 과제로 분리했습니다.

ALT

한국의 비즈니스 프로세스 다이어그램

Hermes archive를 두 곳에 저장한 뒤, 각각 격리 복원하고 무결성·권한·원본 불변까지 확인했습니다.

🎯 이런 분들께 도움돼요

• 개인 AI 에이전트의 설정과 인증 상태를 안전하게 백업하려는 분

• “백업 완료” 표시보다 실제 복원 가능성을 확인하고 싶은 분

• 로컬 장비 고장과 집 전체 장비 손실을 서로 다른 위험으로 대비하려는 분

• 복원 시험 중 평문 파일과 인증 정보가 남지 않게 관리하고 싶은 분

😫 문제 상황 (Before)

시작 당시 Mac mini에는 restic 프로그램만 설치돼 있었습니다. 실제 백업 저장소와 정기 작업은 없었고, Time Machine 대상·NAS·외부 백업도 준비되지 않은 상태였습니다. Hermes 설정을 잘못 바꾸거나 Mac mini가 고장 나면 복구할 근거가 없었습니다.

저장소에 ZIP 하나를 올리는 것만으로는 충분하지 않았습니다. 암호화된 snapshot이 실제로 열리는지, 복원한 파일이 원본과 같은지, Hermes가 그 파일을 받아들일 수 있는지, 복원 과정에서 원본 상태가 바뀌지 않는지까지 확인해야 했습니다. 이 글의 범위는 수동 전체 백업을 두 곳에 만들고 실제 복원으로 증명하는 단계까지입니다.

🛠️ 사용한 도구

repository는 백업이 쌓이는 저장소이고, snapshot은 특정 시점의 백업 묶음입니다. byte 비교는 두 파일의 내용을 가장 작은 데이터 단위까지 대조하는 검사입니다.

🔧 작업 과정

같은 집 안의 복사본과 외부 복사본의 역할을 나눴다

백업 원본은 Mac mini에서 만든 Hermes full ZIP으로 정했습니다. MacBook에는 restic 로컬 저장소를 만들어 Mac mini 단독 고장에 대비했습니다. private Backblaze B2 저장소는 두 Mac의 동시 손실이나 장소 전체의 사고에 대비했습니다.

NAS가 없는 현재 MacBook 저장소는 임시 로컬 계층입니다. 나중에 NAS가 생기면 로컬 계층만 바꾸고 외부 저장소는 유지할 수 있게 역할을 나눴습니다. 두 저장소는 같은 강력한 전용 recovery password로 열되, 그 원본은 password manager에만 보관했습니다.

실제 작업을 시작할 때 사용한 대표 프롬프트는 다음과 같았습니다.

[프로젝트명 및 내부 단계명 제거] Hermes Backup & Recovery Foundation을 시작한다.

운영 기준도 먼저 정했습니다. Hermes 전체 백업은 최소 주 1회와 주요 변경·업데이트 전에 실행하고, 로컬과 외부 저장소가 모두 성공해야 한 번의 성공으로 판단합니다. 마지막 성공이 7일을 넘거나 snapshot 조회·무결성 검사 중 하나라도 실패하면 오래되거나 실패한 백업으로 분류합니다.

자격 증명 문제를 복원 전에 바로잡았다

첫 저장소를 만드는 과정에서 recovery credential이 다른 용도와 재사용된 사실을 발견했습니다. 별도의 강력한 비밀번호로 교체했습니다. 외부 저장소에는 더 이상 사용하지 않는 약한 key와 상태를 확신할 수 없는 key도 남아 있었습니다.

Backblaze의 파일 버전 목록에는 실제 key 객체와 숨김 표시가 함께 보일 수 있었습니다. 이름만 보고 지우지 않고 현재의 강한 key로 snapshot을 열 수 있는지 먼저 확인했습니다. 그다음 사용자 승인 아래 현재 사용하지 않는 정확한 대상만 제거해 활성 key 하나를 남겼습니다.

첫 외부 복원은 잘못된 access-key 형식으로 중단됐습니다. 이때 오류를 무시하고 진행하지 않는 fail-closed, 즉 안전 조건이 맞지 않으면 멈추는 방식을 유지했습니다. 비밀값을 출력하지 않고 필드의 역할만 비교한 결과, 서비스의 key ID와 application key를 S3 호환 인증 항목의 올바른 위치에 연결해야 했습니다. 매핑을 바로잡은 뒤 같은 복원을 다시 수행했습니다.

실패 중 만들어진 일부 파일도 즉시 지우지 않았습니다. 소유자만 읽을 수 있는 600 권한으로 보존해 원인을 확인한 뒤, 마지막 정리 단계에서 정확한 대상으로 함께 제거했습니다.

두 저장소를 각각 복원해 원본과 비교했다

Mac mini에서 만든 Hermes full ZIP은 크기가 0이 아니었고 ZIP 무결성 검사와 소유자 전용 600 권한을 통과했습니다. 외부 저장소에 snapshot을 만든 뒤 restic 저장소 전체 검사를 실행했습니다.

MacBook 로컬 저장소에는 SSH stream으로 같은 archive를 보냈습니다. MacBook 파일 시스템에 별도 평문 ZIP을 먼저 만들지 않았고, 로컬 저장소도 snapshot 조회와 전체 검사를 통과했습니다.

그다음 두 저장소를 독립적으로 시험했습니다.

1. 로컬 snapshot을 Mac mini의 새 격리 폴더에 복원

2. 원본과 byte 단위 일치, ZIP 무결성, 600 권한 확인

3. 복원 ZIP을 일회용 Hermes 환경에 import

4. import된 설정·인증 내용과 운영 Hermes 상태 비교

5. 외부 snapshot도 다른 격리 파일로 복원해 같은 byte·ZIP 검사 반복

일회용 환경에 import하기 전과 후의 운영 설정·인증 지문은 같았습니다. 복원 시험이 실제 Hermes의 현재 상태를 바꾸지 않았다는 뜻입니다.

내용 일치 뒤에 파일 권한까지 확인했다

격리 import에서 예상하지 못한 문제가 나왔습니다. 인증 파일은 600이었지만 설정 파일은 644로 생성됐습니다. 600은 소유자만 읽고 쓸 수 있지만, 644는 다른 사용자도 읽을 수 있는 권한입니다.

내용이 정확하다는 이유로 복구를 끝내지 않고 두 파일을 모두 600으로 교정했습니다. import 뒤 설정과 인증 파일의 권한을 확인하는 단계를 recovery runbook, 즉 반복 가능한 복구 절차의 필수 항목으로 추가했습니다.

마지막에는 실패 중 생긴 일부 파일, 원본 staging archive, 두 복원본, 일회용 import 폴더의 정확한 위치를 다시 확인했습니다. 사용자 승인 후 해당 평문 대상만 제거하고 남은 시험용 평문 파일 수가 0인지 확인했습니다.

✅ 결과 (After)

Before vs After

결과물

• MacBook 로컬과 Backblaze B2의 독립된 암호화 snapshot

• 두 저장소의 snapshot 조회와 restic 전체 검사 결과

• 원본과 byte 단위로 일치한 두 개의 격리 복원 결과

• 일회용 Hermes import와 운영 설정·인증 불변 확인

• import 뒤 권한을 600으로 교정하는 recovery runbook 항목

• 평문 staging·restore 파일의 정확한 정리 기록

이번 결과는 해당 시점의 수동 백업과 복원 성공입니다. 자동 실행, 7일 이상 오래된 백업 알림, 새 장비 전체 복구, 장기간의 신뢰성까지 확인한 것은 아닙니다.

💬 이 과정에서 배운 AI 활용 팁

효과적이었던 것

• AI에게 백업 명령보다 손실 시나리오와 복원 완료 기준을 먼저 정리하게 했습니다.

• “snapshot이 보이는가”와 “실제로 복원 가능한가”를 별도 시험으로 나눈 것이 효과적이었습니다.

• 비밀값을 출력하지 않고 인증 필드의 역할만 비교해 잘못된 매핑을 찾았습니다.

• 실패 파일도 바로 지우지 않고 권한을 제한해 보존하니 원인 확인과 안전한 정리를 함께 할 수 있었습니다.

이렇게 하면 안 돼요

• 저장소에 파일이 있다는 이유만으로 복구 가능하다고 판단하면 안 됩니다.

• 로컬과 외부 백업을 같은 장소와 같은 손실 시나리오로 운영하면 이중화 효과가 줄어듭니다.

• 복원 내용만 확인하고 파일 권한을 보지 않으면 인증 정보가 더 넓게 읽힐 수 있습니다.

• 실패 중 생긴 평문 파일을 경로 확인 없이 한꺼번에 삭제하면 필요한 증거나 다른 파일을 잃을 수 있습니다.

🌍 다른 업무에 적용한다면?

개인 문서, 비밀번호 관리 도구의 내보내기 파일, 홈 서버 설정, 작은 업무 시스템도 같은 방식으로 검증할 수 있습니다. 서로 다른 손실을 담당하는 두 저장소를 만들고, 실제 복원·원본 비교·권한 확인·시험 파일 정리를 하나의 완료 기준으로 묶는 것입니다.

🚀 앞으로의 계획

• 수동 절차를 반복 가능한 주간 runbook으로 유지

• 자동화를 시작하기 전에 실패 알림과 7일 stale 판정이 실제로 전달되는지 시험

• 새 장비에서 Hermes 전체 상태를 복구하는 별도 재난 복구 훈련 진행

📋 재사용 가능한 프롬프트

프롬프트 1: 백업 존재가 아닌 복원 가능성 검증

[대상 시스템]의 백업을 서로 다른 손실 시나리오를 담당하는 로컬과 외부 저장소에 암호화해 보관해줘.
파일 존재만 확인하지 말고 snapshot 조회, 저장소 무결성, 두 저장소의 독립 복원, 원본과 byte 비교를 수행해줘.
복원본은 일회용 환경에서 실제 import하고 운영 상태 불변과 파일 권한을 확인해줘.
인증값은 출력하지 말고, 실패 중 생긴 평문 파일은 정확한 대상을 확인한 뒤 사용자 승인으로 정리해줘.