복구와 재검증

복구 명령 성공과 업무 복구는 다릅니다

파일을 복사하는 명령이 종료 0이어도 앱이 예전 파일을 계속 읽거나 데이터가 잘못되면 사용자는 여전히 실패를 봅니다. 이번 레슨은 손상 사본을 보존한 채 백업을 새 위치에 복원하고, 복구 판정에 필요한 네 가지 경계를 정합니다. HTTP·데이터·권한·점검 알림의 확인 결과가 모두 참이어야 완료입니다. 어느 결과가 누락되면 성공으로 채우지 않고 RECOVERY_FAILED로 판단하여 후속 확인을 요구합니다.

설정 되돌림과 데이터 복원을 선택합니다

잘못된 data_file 설정만 바뀌었고 기존 데이터는 온전하면 m09의 설정 사본으로 되돌릴 수 있습니다. 원본 데이터 자체가 손상됐다면 설정을 돌려도 데이터는 돌아오지 않습니다. 이 경우 검증된 백업을 별도 위치에 복원하고 새 데이터를 읽는 앱을 확인합니다. 이번 local 과제는 두 번째 상황을 작은 JSON 파일로 연습합니다. 실제 데이터베이스 일관성과 변경 이후 새 데이터의 병합은 별도 복구 계획이 필요합니다.

기대 업무 값을 후보에서 만들지 않습니다

정상 계약은 count가 3인 JSON 객체입니다. broken.json은 count가 9이고 backup.json에는 정상 사본이 있습니다. 백업을 읽은 뒤 그 값이 무엇이든 정상으로 정하면 손상 백업도 성공할 수 있습니다. manifest.json의 해시와 승인한 업무 값 둘 다 확인합니다. 해시는 사본의 동일성이고 업무 기대 값은 의미 검증입니다. 해시가 맞는 count=9 백업도 DATA_INVALID로 거부하는 테스트가 이 차이를 드러냅니다.

쓰기 전에 백업의 동일성을 검사합니다

restore는 backup.json의 원본 바이트를 읽고 SHA-256을 manifest와 비교합니다. 다르면 BACKUP_MISMATCH로 중단하고 restored.json을 만들지 않습니다. manifest가 신뢰할 수 있는 출처에서 보관됐다는 전제가 있으며 해시 문자열만으로 출처 인증이 되는 것은 아닙니다. 백업 생성 시각과 일관성 검증 기록은 누적 m07 증거를 연결합니다. 이 과제의 고정 사본 성공을 모든 과거 백업의 복구 가능성으로 확대하지 않습니다.

새 목적지를 선택하여 원본을 지킵니다

restored.json은 새 이름이어야 하며 기존 파일이나 심볼릭 링크가 있으면 DESTINATION_CONFLICT로 중단합니다. broken.json과 backup.json은 그대로 보존합니다. 파일을 xb 모드로 생성하여 이미 존재하는 파일을 덮어쓰지 않습니다. 테스트는 작업자만 쓰는 임시 폴더에서 진행하고 공유 쓰기 경로의 경쟁 상황은 다루지 않습니다. 실제 복원 경로는 소유자와 상위 디렉터리 권한을 먼저 확인합니다.

바이트 복원과 권한 복원을 같이 확인합니다

복원 파일은 백업과 같은 바이트를 가지고 접근 모드는 0640이어야 합니다. JSON 객체를 다시 직렬화하면 공백과 줄바꿈이 달라져 해시가 바뀔 수 있으므로 원본 바이트를 씁니다. 새 파일의 초기 모드는 실행 환경의 umask에 영향을 받으므로 명세 모드를 명시적으로 적용합니다. starter는 이 chmod가 빠져 있습니다. 값이 맞는 것만 보고 통과 처리하면 다른 사용자의 접근 범위가 달라진 사실을 놓칩니다.

로컬 모드는 서비스 접근 증거와 다릅니다

stat로 확인한 0640은 파일 모드의 증거입니다. 파일 소유자·그룹과 부모 경로 접근, 실제 bcweb의 읽기가 맞아야 서비스 접근까지 확인할 수 있습니다. local 테스트는 현재 작업자가 만든 임시 파일을 읽으며 계정을 바꾸지 않습니다. VM 제출에서는 누적 계정 계약과 복원 경로의 실제 소유·모드·서비스 계정 읽기 결과를 새로 연결합니다. 오래된 권한표만 보고 현재 복원 데이터 접근을 성공으로 적지 않습니다.

HTTP는 응답 본문까지 검사합니다

실제 HTTP 검사에서는 /health의 상태와 정상 본문, /items의 상태와 전체 JSON을 확인합니다. /health가 200이어도 count가 9이면 업무 복구가 아닙니다. 미션의 외부 테스트는 앞 앱과 httpcheck를 사용하여 복원 데이터로 루프백 서버를 열고 요청합니다. 프록시를 거치지 않고 요청에 상한을 두며 서버는 컨텍스트 종료 때 닫습니다. 샌드박스에서는 소켓 제한 때문에 이 검사 결과를 실행한 것처럼 채우지 않습니다.

알림 정상은 조용함만으로 판단하지 않습니다

복구 후 알림이 없으면 서비스가 정상일 수도 있지만 timer가 꺼졌거나 전달 경로가 막혔을 수도 있습니다. 현재 점검의 정상 결과와 실행 시각을 확인하고 허가된 실패 대역 입력으로 실패 코드와 알림 전달도 재확인합니다. 누적 m08의 절차를 사용하며 기존 서비스에 실제 장애를 만들 필요는 없습니다. 새 결과 파일과 담당 역할에 전달된 증거가 있어야 알림 경로를 확인했다고 쓸 수 있습니다.

종합 판정 함수의 계약

assess는 http·data·permission·alert 네 키가 모두 Python의 True인지 검사합니다. 누락 키, None, 정수 1은 검증 완료를 뜻하지 않으므로 실패로 처리합니다. 이 함수는 검사 자체를 수행하지 않으며 전달된 결과를 결합합니다. 네 개의 True를 직접 만든 demo는 판정 정책 예제입니다. 실제 측정이 필요한 제출물에서는 각 참 값을 어떤 명령·대상·시각으로 얻었는지 증거를 붙입니다.

복구 실패 후에는 추가 변경을 멈춥니다

파일 동일성이 맞지만 HTTP가 실패했다면 캐시·잘못된 데이터 경로·실행 계정 등을 조사할 수 있습니다. 확인되지 않은 상태에서 다른 백업을 연속 적용하면 현재 상태와 시점을 더 구분하기 어려워집니다. 복구 사본과 현재 설정, 실패한 경계, 마지막 정상 관측을 보존하고 담당 역할에 전달합니다. RECOVERY_FAILED는 원인을 특정했다는 뜻이 아니라 완료 조건을 아직 만족하지 못했다는 뜻입니다.

테스트에서 실제 부작용을 확인합니다

test_copy_bytes_mode_preserve_broken은 복원 바이트와 모드뿐 아니라 손상 파일이 그대로인지 확인합니다. corrupt_backup_no_write는 해시 실패 시 목적지 파일이 없음을 검사합니다. conflict와 symlink는 기존 증거 덮어쓰기를 막습니다. all_checks_required는 각 키의 False·None·1 및 전체 누락을 검사합니다. 반환 문자열만 고쳐 RECOVERED를 늘리는 구현은 이 경계 사례에서 깨집니다.

오류를 읽고 수정 범위를 좁힙니다

모드 기대 값 416은 0640을 십진수로 표현한 값입니다. 기대 416과 실제 다른 숫자가 나오면 stat.S_IMODE와 chmod의 8진 표기를 확인합니다. BACKUP_MISMATCH가 나오면 원본 사본과 manifest의 출처를 재확인하고 기대 해시를 즉시 덮어쓰지 않습니다. DESTINATION_CONFLICT이면 기존 결과를 보존하고 새 실습 폴더를 사용합니다. 실제 HTTP의 Operation not permitted는 실행 환경 제한으로 남기고 데이터 복구 성공으로 바꾸지 않습니다.

복구 기록을 새 관측으로 닫습니다

기록에는 사건 식별자, 백업 시각·경로, 복원 목적지, 해시·모드, HTTP 본문, 서비스 계정 읽기, 자동 점검과 알림 결과, 실행 계정과 시각을 적습니다. 아직 실행하지 않은 항목은 PENDING으로 남깁니다. 파일 대역·판정 정책·실측을 분리하면 인수자가 무엇을 다시 확인해야 하는지 알 수 있습니다. rsync의 전송 옵션은 더 읽기에서 살펴보고 이번 실습에서는 별도 위치 복원과 완료 조건의 결합에 집중합니다.

python3 -B demo.py

BYTES_MATCH True
MODE 0640
DATA 3
CHECK_POLICY RECOVERED
HTTP_MEASURED False

checks={"http":True,"data":True,"permission":True}
print("RECOVERED" if all(checks.get(k) is True for k in ("http","data","permission","alert")) else "RECOVERY_FAILED")

RECOVERY_FAILED

bash check.sh

bash check.sh

bash check.sh