저장소 경계를 선택하세요
프로덕션 서버와 다른 대상과 자격 증명을 사용하세요. 클라이언트 측 암호화는 저장된 사본을 보호할 수 있지만, 저장소 비밀번호나 키는 비공개로 백업해야 합니다. 이를 잃으면 모든 암호화된 스냅샷을 사용할 수 없게 될 수 있습니다.
일관된 데이터를 수집하세요
데이터베이스 네이티브 덤프 또는 애플리케이션이 지원하는 스냅샷 절차를 사용하세요. 구성, 배포 지침 및 복구에 필요한 보호된 비밀을 백업하세요. 재구축할 수 있다고 확신할 때만 일시적 캐시를 제외하세요.
삭제를 더 어렵게 만드세요
소스 머신이 모든 이전 복사본을 지울 수 없는 추가 전용 또는 불변 대상을 고려하세요. 가능하면 보존 및 정리 자격 증명을 분리하세요. 암호화만으로는 침해된 서버가 쓰기 가능한 저장소를 삭제하는 것을 막을 수 없습니다.
점검 및 복원 훈련 일정 수립
작업 종료 상태와 마지막 정상 백업의 경과 시간을 모니터링하세요. 도구에서 지원하는 저장소 무결성 검사를 실행하세요. 정기적으로 샘플을 복원하고 주요 애플리케이션 변경 후 전체 복구 리허설을 수행하세요.
복사본 추가와 기록 삭제 분리
추가 전용 대상은 프로덕션 서버가 스냅샷을 추가하도록 허용하면서 삭제 권한은 별도의 신뢰할 수 있는 기기에 유지할 수 있습니다. 보존 정책은 여전히 신중히 검토해야 합니다. 위조된 최신 스냅샷은 일부 달력 기반 선택 정책을 약화시킬 수 있습니다. 도구의 지침을 확인하고 보존 드라이 런을 실행하며 용량을 모니터링하세요. Restic의 forget 작업은 스냅샷을 선택하고, pruning은 참조되지 않은 저장 데이터를 제거합니다.
- 저장소 유지 관리 자격 증명을 운영 머신에서 분리하세요
- 삭제를 허용하기 전에 보존 모의 실행을 수행하세요
- 각 복구 훈련에는 새 빈 대상을 사용하세요
restic check
restic snapshots
restic restore latest --target /srv/restore-drill공식 문서: Restic 보존 및 정리
합격 조건이 있는 복원 훈련
현실적인 실패 하나를 선택하세요: 삭제된 파일, 손실된 데이터베이스 또는 완전한 기기 재구축. 별도 디렉터리나 격리된 호스트로 복원하세요. 파일 내용, 권한 및 애플리케이션이 이를 사용할 수 있는지 확인하세요. 소요 시간과 런북에서 누락된 수동 단계를 기록하세요. 저장소 검사는 실제 애플리케이션 복원과는 다른 속성을 확인합니다.
- 첫 테스트로 운영 중인 애플리케이션 위에 복원하지 마세요
- 암호화 자격 증명을 독립적으로 복구할 수 있는지 확인하세요
- 최신 성공 백업이 복구 목표를 초과하면 알림
제외 항목을 선택하기 전에 복구 매니페스트를 작성하세요
패키지를 다시 설치하는 것만으로는 재현할 수 없는 항목을 나열하세요: 데이터베이스 콘텐츠, 업로드, 애플리케이션 구성, 서명 또는 암호화 키, 배포 버전 등입니다. 각 항목 옆에 일관성 방법을 기록하세요. 데이터베이스 덤프는 정의된 시점에 속합니다. 사용 중인 데이터베이스 디렉터리를 복사하면 다른 결과가 나올 수 있습니다. 저장소 접근 권한, 암호 문구 및 모든 Borg 키 내보내기를 별도의 비공개 복구 위치에 보관하세요. 복구 사본을 유일한 사본으로 만들기 전에 교체 장비에서 저장소를 열 수 있는지 테스트하세요.
- 복구 시점 목표를 명시하세요: 최근 작업이 얼마나 손실될 수 있는지입니다. 해당 요구 사항에 맞춰 일정을 설정하세요.
- 복구 시간 목표를 명시하세요: 재구축에 걸릴 수 있는 시간. 리허설에 데이터베이스 가져오기 및 DNS 변경을 포함하세요.
- 캐시를 위한 제외가 업로드, 컨테이너 볼륨 또는 보호된 구성까지 제거하지 않는지 확인하세요.
- 설치된 Borg 주 버전의 문서를 사용하세요. 저장소 형식과 명령은 모든 버전에서 호환되지 않습니다.
공식 문서: Borg: 암호화, 일관성 및 복원
저장된 데이터와 저장소 메타데이터를 함께 확인하세요
Restic의 기본 저장소 검사와 읽기 기반 검증은 서로 다른 작업을 수행합니다. 대역폭과 실행 시간 비용을 고려하여 데이터 검증을 예약하세요. 예시는 팩 파일의 정의된 5분의 1을 검사하며, 이후 예약된 검사는 저장소를 모두 포함하도록 나머지 분수를 사용해야 합니다. 무작위로 선택된 하위 집합은 동일한 범위 보장을 제공하지 않습니다. 두 작업 모두 복원된 데이터로 애플리케이션이 시작될 수 있음을 증명하지는 않습니다.
restic check --read-data-subset=1/5
restic snapshots --host example-host
restic restore latest --host example-host --target /srv/restore-drill공식 문서: restic: 저장소 검사 및 데이터 검증
유지 관리를 침해된 클라이언트의 손이 닿지 않는 곳에 두세요
Borg append-only 스토리지는 커밋된 세그먼트 데이터를 보존하지만, 클라이언트는 여전히 표시되는 아카이브 목록을 변경할 수 있습니다. 복구와 컴팩션에는 문서화된 관리 절차가 필요합니다. 원격 백업 자격 증명은 해당 보호 조치를 우회할 수 있는 무제한 셸이나 파일 시스템 로그인이 아닌 Borg의 서버 명령으로 제한하세요. restic의 경우 append-only 보존을 위한 keep-within 지침을 검토하세요. 이력을 제거할 수 있는 유지보수 전에는 신뢰할 수 있는 머신에서 저장소 상태를 점검하고 선택 항목을 미리 확인하세요.
- 마지막 성공 복사본의 경과 시간, 저장소 증가, 캐시 공간 및 양쪽 끝의 여유 용량을 모니터링하세요.
- 복원이 실패하면 복구나 정리를 시도하기 전에 원본 저장소와 로그를 보존하십시오.
- 작업은 성공했지만 예상 파일이 없다면 보존 기간을 변경하기 전에 아카이브 내용과 제외 패턴을 확인하세요.
- 격리 환경에서 파일을 열고 애플리케이션 점검을 실행하여 훈련을 마무리하세요. 복원 명령에 프로덕션 대상을 포함하지 마세요.
공식 문서: Borg: 추가 전용 운영 및 유지 관리 · restic: 보존 및 추가 전용(append-only) 고려 사항