재실행 중 덮어쓴 배포 백업

배포 도구를 교체할 때 현재 파일을 백업하고, 준비한 새 파일을 설치하는 명령을 이어서 실행했습니다. 같은 명령을 다시 실행했더니 install에서 후보 파일을 찾지 못했습니다. 실패 메시지는 마지막 단계에서 나왔지만, 그 전에 실행된 복사가 기존 백업을 이미 바꾼 뒤였습니다.

첫 실행에서는 백업 파일에 이전 버전이 들어갔고 설치 경로에는 새 버전이 들어갔습니다. 두 번째 실행에서는 그 새 버전이 같은 이름의 백업 위에 복사됐습니다. 그 뒤에야 설치할 후보 파일이 없다는 오류가 났습니다. 이번에는 변경 전 도구가 저장소 이력에 있어 이전 내용을 찾을 수 있었습니다. 운영에서만 관리하는 파일이라면 동일한 복원 경로를 기대하기 어렵습니다. 실제로 도구를 이전 상태로 복구했거나, 수정한 절차로 설치를 다시 검증했다는 기록은 없습니다.

후보 확인부터 백업 보존까지

백업 && 설치는 백업이 실패하면 설치를 건너뜁니다. 설치가 실패했을 때 이미 끝난 백업을 되돌리는 기능은 없습니다. 후보 파일이 있는지 먼저 검사하고, 현재 파일이 어느 버전인지 확인한 다음 백업을 만드는 순서라면, 이번처럼 후보가 없는 상태에서 백업부터 바꾸는 일을 피할 수 있습니다. 백업은 실행마다 새 이름으로 만들거나, 첫 사본이 이미 있으면 덮어쓰지 않는 정책을 따로 정해야 합니다. 매번 새 이름을 붙이는 경우에도 어느 사본이 최초 설치 전 원본인지 식별할 수 있어야 합니다.

후보 누락, 재실행, 복원을 같은 임시 폴더에서 확인했습니다

문자 두 개로 구분되는 가상 버전을 만들었습니다. 후보 파일을 확인하고, 최초 사본이 없을 때만 백업한 뒤 파일을 교체하는 작은 모형을 같은 임시 폴더에서 실행했습니다.

후보 누락은 복사 전에 걸렀고, 다시 실행한 뒤에도 사본의 이전 버전이 남았습니다. 모형에서 파일 내용과 복원 결과를 확인했습니다. 운영의 교체 도구, 여러 프로세스가 동시에 실행되는 경우, 권한과 서비스 기동은 이 재현의 범위 밖입니다.

사본의 읽기 권한도 따로 정할 수 있습니다. 별도로 Compose 설정을 교체했을 때는 기존 파일을 백업하며 install -m 600으로 사본의 권한을 지정하고, 파일 이름에 백업 시각을 남겼습니다. 어떤 사본을 보존할지는 이름과 덮어쓰기 조건이 정하고, 누가 읽을 수 있는지는 권한이 정합니다. 이 별도 작업에서는 사본을 만들었고, 같은 시각으로 이름이 겹치거나 실제로 복원하는 경우는 확인하지 않았습니다.

별도의 Git 작업에서는 검사와 커밋 뒤에 세미콜론으로 병합을 이어 붙였습니다. 검사 실패로 커밋은 건너뛰었지만 병합은 실행됐고, Git이 미커밋 변경 때문에 병합을 거부했습니다. 이어서 실행하면 안 되는 단계는 &&로 연결하고, 실패 뒤에는 실제 파일이나 Git 상태부터 확인합니다. 배포에서 다시 실행해도 안전한지 판단할 때는 두 번째 실행의 각 단계가 첫 실행 뒤 남은 상태를 어떻게 읽고 바꾸는지 순서대로 적어 보는 것이 기준이 됐습니다.