cron 잡 설정 실수, 이렇게 하면 백업 점검 시간을 아낀다

자동 백업을 등록했다고 해서 실제로 백업이 되고 있다고 볼 수는 없습니다. 병원 서버 운영에서 cron 잡 설정 실수는 조용히 누적되다가 복구가 필요한 순간에 드러납니다.

실제로 매일 새벽 2시에 MySQL 백업 스크립트가 돌도록 cron에 넣어뒀는데, 한 달간 실행되지 않은 상태를 발견한 적이 있습니다. /bin/bash 경로를 생략하고 상대 경로로 스크립트를 지정해 cron이 찾지 못했습니다. 이 경험 이후 cron 잡 설정 실수 점검을 백업 루틴에 넣었습니다.

cron이 실패하는 흔한 이유

터미널에서 되는 명령이 cron에서는 실패할 수 있습니다. cron은 로그인 쉘과 환경변수가 다르고, PATH도 좁게 잡히는 경우가 많기 때문입니다.

자주 보는 원인은 다음과 같습니다.

1. 스크립트를 상대 경로로 작성
2. 실행 권한 누락
3. PATH 환경변수 부족
4. 로그 리다이렉션 없음
5. 실패 메일을 아무도 확인하지 않음

cron 잡 설정 실수를 줄이려면 명령을 짧게 쓰는 것보다 명시적으로 쓰는 편이 좋습니다.

안전한 등록 예시

실제 서버 계정이나 내부 경로는 공개하지 않는 것이 좋습니다. 아래는 구조를 보여주는 예시입니다.

SHELL=/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

0 2 * * * /bin/bash /path/to/backup.sh >> /path/to/backup.log 2>&1

여기서 중요한 것은 절대 경로입니다. 스크립트 경로, 로그 파일 경로, 실행 프로그램 경로를 모두 분명히 적습니다.

등록 후에는 기다리지 말고 수동 실행으로 먼저 확인합니다.

/bin/bash /path/to/backup.sh
tail -n 50 /path/to/backup.log

실행 여부 확인

cron 잡 설정 실수는 등록 화면만 봐서는 알 수 없습니다. 실제 결과물이 생겼는지 확인해야 합니다.

백업 작업이라면 백업 파일 생성 시각, 파일 크기, 로그 마지막 줄을 봅니다. 성공 시 로그 파일 크기가 변하고, 실패 시 이메일이나 알림이 오도록 이중 확인 구조를 둡니다.

특히 백업처럼 매일 반복되는 작업은 “성공했을 때도 흔적이 남는지”가 중요합니다. 실패 로그만 남기면 아무 일도 없을 때 정상인지, 아예 실행되지 않았는지 구분하기 어렵습니다.

점검 항목은 단순합니다.

1. 오늘 날짜 백업 파일 존재
2. 파일 크기가 0이 아닌지 확인
3. 로그에 success 또는 완료 문구 기록
4. 실패 시 알림 발송 여부 확인
5. 월 1회 복구 테스트 일정 기록

운영 기준

자동화의 핵심은 등록이 아니라 검증입니다. cron 잡 설정 실수를 막으려면 절대 경로, 로그 기록, 결과 파일 확인을 한 세트로 둬야 합니다.

병원 서버의 백업, 로그 정리, 보안 점검 스크립트는 모두 같은 기준으로 관리할 수 있습니다. cron에 넣고 끝내지 말고, 다음 날 실제 결과가 남았는지 확인하는 습관이 운영 안정성을 만듭니다.