백업 범위와 주기

왜 백업 정책부터 작성하는가

복구 요청을 받은 담당자는 압축 파일 이름보다 어떤 시점의 무엇을 되살려야 하는지 먼저 결정해야 합니다. 작은 운영 실습실에서도 데이터만 돌아오고 설정이 없으면 서비스가 같은 경로를 읽지 못합니다. 반대로 홈 디렉터리 전체를 묶으면 서비스에 필요 없는 SSH 개인키와 비밀 환경 값까지 백업으로 퍼집니다. 이번 레슨은 복사 명령을 고르기 전에 복구 대상·제외 대상·시간 목표를 한 장으로 정하는 작업입니다.

실습 환경과 제출 형식

이 모듈은 앞서 준비한 Linux VM의 bcops 작업 계정, bcweb 서비스 계정, bcapp 그룹과 Python 웹 앱을 이어 사용합니다. 파일 검사 과제는 Python 3와 bash만으로 맥에서도 실행합니다. ZIP은 새 폴더에 풀고 그 안에서 안내 명령을 입력합니다. starter에는 의도적으로 틀린 동작이 있고 solution은 비교용 완성본입니다. external 실습은 systemd VM 관측이 남은 상태이며 맥에서 통과했다고 바꾸지 않습니다. 실행하지 않은 VM 단계의 output은 비워 두고 실제 시각·종료 코드·원문을 제출합니다.

복구 단위를 다섯 파일로 묶습니다

프로젝트의 복구 단위는 data/items.json, config/service.env, app.py, service.py, bootcamp-systems.service입니다. 데이터·설정·실행 코드·실행 계정 선언을 같은 시점에 묶습니다. 실제 VM에서 유닛은 /etc/systemd/system에 설치되어 있으므로 미션은 그 파일을 읽어 묶음 안의 상대 이름으로 저장합니다. 서비스 설정에는 DATA_FILE·RUN_SECONDS·BIND_ADDRESS 세 키만 허용하며 다른 키가 발견되면 검토 없이 계속 진행하지 않습니다.

포함 여부를 이름과 이유로 기록합니다

데이터는 count와 items를 가진 JSON이며 복구 후 전체 값이 같아야 합니다. 코드는 저장소에서 다시 받을 수도 있지만 이번 실습은 그 시점 코드까지 함께 보관해 실행 차이를 줄입니다. 유닛은 bcweb·bcapp·자연 종료 조건을 재현하기 위해 포함합니다. 파일별 모드와 소유자 이름, UID/GID를 목록에 남기고 복구 VM에 같은 계정이 있는지 확인합니다. 권한 목록은 데이터가 아니라 메타데이터의 복구 기준입니다.

제외 기준은 금지 목록보다 허용 목록으로 좁힙니다

이번 구현은 정해진 다섯 파일만 선택합니다. private.key, .ssh, secret.env, 로그와 캐시는 이 묶음의 대상이 아닙니다. 확장자에 key가 없다고 안전한 것은 아니므로 service.env 내용도 세 키 계약으로 검사합니다. 실습용 가짜 비밀 파일로 제외 검사를 하며 실제 비밀을 예제나 출력에 적지 않습니다. 서비스가 비밀을 필요로 한다면 승인된 별도 공급 경로·담당자·접근 절차를 정책에 적고 이 백업이 비밀까지 복구한다고 주장하지 않습니다.

허용 손실은 마지막 복구 가능한 시점으로 봅니다

RPO는 장애 뒤 어느 시점까지의 데이터를 복구해야 하는지 정하는 목표입니다. 실습에서 RPO를 60분으로 정했다면 장애 14시, 최신 유효 백업의 데이터 시점 13시 20분은 40분 간격입니다. 백업 파일 생성 시각만으로 데이터 시점을 확정하지 않습니다. 복사 시작 전에 쓰기를 멈췄다면 그 시점을 적고, 백업이 실패하면 이전 유효 백업까지 간격이 길어집니다. 매시간 예약했다는 사실만으로 RPO 달성을 선언하지 않습니다.

주기는 실패 여유까지 포함해 정합니다

RPO 60분인데 백업 간격을 정확히 60분으로 잡으면 지연과 한 번의 실패에도 목표를 넘기기 쉽습니다. 후보 주기를 20분으로 잡고 소요 시간·실패 알림·마지막 유효 백업의 나이를 같이 관측합니다. 데이터가 거의 바뀌지 않는다는 추측으로 목표를 늘리기보다 사용자의 허용 손실을 먼저 합의합니다. 따라하기의 시간 계산은 정책 예제이며 실제 운영 백업이 존재한다는 증거가 아닙니다.

복구 시간에는 확인 작업도 포함합니다

RTO는 복구 완료까지 허용하는 시간 목표입니다. 압축 해제만 끝났다고 시계를 멈추면 계정 권한 조정과 서비스 기동·데이터 조회가 빠집니다. 실습 정책은 시작 기준을 복구 요청 접수, 끝 기준을 복원 경로의 /items 조회와 내용 확인 완료로 적습니다. 현장에서는 장애 감지부터인지 선언부터인지 합의가 다를 수 있으므로 기준 시점을 기록합니다. 작은 파일의 해제 속도를 서비스 전체 복구 시간으로 제시하지 않습니다.

보관 개수와 복구 시점 수를 나눕니다

최근 세 개 보관은 이번 교육용 규칙입니다. 백업을 20분 간격으로 만들면 세 개가 제공하는 시점 범위는 일주일 보관과 다릅니다. 잘못된 데이터가 사흘 뒤 발견되는 업무라면 세 개로 충분한지 다시 논의해야 합니다. 자동 삭제는 새 백업 검증 뒤에 실행하고 임시 .part는 유효 백업으로 세지 않습니다. 다른 이름의 문서나 손상된 기존 묶음을 자동으로 지우지 않는 것도 보관 정책의 일부입니다.

별도 경로와 별도 장애 영역을 구분합니다

원본 옆 backup 디렉터리는 덮어쓰기 사고와 복원 연습을 분리하지만 같은 디스크 고장에는 함께 잃을 수 있습니다. 실습에서는 원본·백업·복원을 서로 다른 경로에 두고, 정책에는 별도 저장 장치 또는 별도 장소의 사본과 접근 담당자를 추가합니다. 이 모듈의 코드가 원격 전송·암호화 저장·불변 보관을 구현한 것은 아닙니다. 필요한 보호 수단과 아직 구현되지 않은 범위를 문서에 나란히 표시합니다.

읽기 권한도 정책의 일부입니다

백업에는 코드뿐 아니라 실제 데이터가 있으므로 조회할 수 있는 담당자를 제한합니다. 제공 구현은 새 백업 폴더를 700, 묶음과 체크섬 파일을 600으로 만들고 상위 경로의 접근도 점검합니다. 기존 폴더 권한이 넓으면 생성 옵션만으로 좁아지지 않을 수 있으므로 정책 검토에서 따로 확인합니다. 체크섬은 전송이나 저장 손상을 찾는 기준이며 같은 사람이 묶음과 체크섬을 함께 바꿀 수 있는 상황의 진위를 보장하지 않습니다.

쓰기를 멈추는 방식도 미리 정합니다

이 실습 앱은 RUN_SECONDS=20과 Restart=no로 자연 종료합니다. 종료한 뒤 다른 작성자가 없음을 확인하고 파일을 읽습니다. 운영의 장기 실행 앱에 이 절차를 그대로 적용할 때는 쓰기 차단과 업무 영향에 대한 별도 변경 계획이 필요합니다. DB 파일은 실행 중인 파일을 그냥 복사하는 대신 해당 DB의 일관성 백업 수단을 사용해야 합니다. 여기서는 닫힌 작은 JSON의 복구 단위를 연습합니다.

정책을 검토할 때 찾는 빈칸

데이터 경로만 있고 유닛 설치 위치가 없으면 어디서 원본을 수집하는지 모호합니다. RTO 숫자만 있고 시작·종료 기준이 없으면 측정마다 값이 달라집니다. 제외 대상만 있고 비밀 재공급 방법이 없으면 기동 시 필요한 값이 빠집니다. 백업 생성 성공만 있고 마지막 유효 백업 확인이 없으면 실패한 날의 손실 범위를 알 수 없습니다. 담당자는 이 네 빈칸을 찾아 정책을 실제 절차로 바꿉니다.

정책 과제의 완료 기준

제출물은 대상 다섯 파일의 경로·이유·소유자·모드, 제외 목록, RPO와 RTO 및 기준 시각, 백업 주기·보관 개수·실패 알림 담당자, 별도 장애 영역 보관 계획을 담습니다. 다음 레슨에서는 이 정책의 허용 목록과 쓰기 종료 조건을 코드와 테스트에 옮깁니다. 동기화 도구의 옵션과 경로 끝 슬래시 규칙은 더 읽기의 rsync 원고에서 확인하고 여기서는 복구 가능한 시점을 유지하는 정책을 완성합니다.