다시 실행하기 전에 남은 결과부터 읽기
백업 파일이 존재하거나 프로세스가 종료됐다는 이유만으로 작업을 성공 처리하면 내용 누락과 중복 처리를 놓칠 수 있습니다. 먼저 마지막 정상 결과를 보관하고, 데이터 내용이 틀린 것인지 실행 자체가 실패한 것인지 나눕니다. 이 사이트의 SQLite 실험에서는 무결성 검사에 통과한 복사본에도 메모 16개 중 4개가 빠져 있었습니다.
| 증상 | 우선 대조할 것 | 곧바로 하면 안 되는 판단 |
|---|---|---|
| 백업에서 최신 기록이 없음 | 별도 복구본의 행 수·마지막 키·대표 값 | integrity_check=ok만으로 백업 완료 |
| database is locked | 쓰기 트랜잭션 유지 시간과 연결별 timeout | WAL이면 동시 쓰기도 제한 없음 |
| 터미널에서만 성공 | 작업 디렉터리·필수 환경변수·PATH | 스케줄 시간을 바꾸면 해결 |
| 실행이 겹침 | 잠금 획득·건너뛰기 기록 | 잠금 파일 존재=프로세스 실행 중 |
| 중지 뒤 재실행 | 서비스와 타이머 각각의 상태 | service stop으로 다음 예약도 제거 |
완료 기준을 작업마다 구체적으로 남기기
백업 작업은 별도 경로에 복구한 뒤 기대한 데이터를 조회하는 것까지, 수집 작업은 결과 파일의 구조와 마지막 성공 시각을 읽는 것까지 완료 조건으로 둡니다. SQLite의 짧은 timeout은 오류를 빨리 반환하고 긴 timeout은 잠금 해제를 기다릴 수 있지만, 기다리는 시간을 늘린다고 잠금을 오래 가진 원인이 없어지지는 않습니다. 아래 busy_timeout 실험은 이 차이를 관찰한 자료입니다.
예약 작업을 재현할 때는 실제 쓰기 작업을 곧바로 중복 실행하기보다 경로와 필수 설정의 유무부터 비교합니다. 환경변수 전체를 로그로 출력하면 자격 증명이 섞일 수 있으므로 필요한 키가 존재하는지와 실행 경로만 남깁니다. 서비스 상태가 정상이어도 작업에 필요한 파일이 없을 수 있어, 준비 상태 검사에서 의존성을 확인하는 방법도 함께 읽을 수 있습니다.