cron으로 돌리던 백업 스크립트가 어느 날부터 안 돈다는데, 로그가 없어 원인을 못 찾습니다. cron은 단순하지만 실행 이력·실패 추적·의존성 관리가 약합니다. systemd timer는 같은 예약 작업을 journalctl로 추적 가능하게 만듭니다.
증상 — cron의 한계
cron 작업은 실패해도 조용하고, 출력은 메일로 흩어지며, 부팅 중 놓친 작업을 따라잡지 못합니다. systemd timer는 실행을 일반 서비스처럼 다뤄 상태·로그·재시도를 모두 관리합니다.
진단 — 지금 도는 타이머 보기
서버 터미널
systemctl list-timers --all
NEXT(다음 실행), LAST(마지막 실행), ACTIVATES(연결된 서비스)가 한눈에 보입니다. cron의 crontab -l과 달리 다음 실행 시각까지 계산해 줍니다.
단계 — timer 만들기
타이머는 .service(무엇을 실행할지)와 .timer(언제 실행할지) 두 파일로 구성됩니다.
- 서비스 유닛
/etc/systemd/system/backup.service
INI
[Unit]
Description=Nightly backup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
- 타이머 유닛
/etc/systemd/system/backup.timer
INI
[Unit]
Description=Run backup nightly
[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true
[Install]
WantedBy=timers.target
Persistent=true는 서버가 꺼져 있어 놓친 작업을 부팅 후 따라잡게 해 줍니다. cron에는 없는 기능입니다.
- 활성화
서버 터미널
systemctl daemon-reload
systemctl enable --now backup.timer
OnCalendar 표현이 의도대로인지 검증하려면 다음을 씁니다.
로컬 터미널
systemd-analyze calendar "*-*-* 03:00:00" # 다음 실행 시각 미리보기
운영 체크리스트
서버 터미널
systemctl list-timers backup.timer # 다음/마지막 실행 확인
systemctl status backup.service # 마지막 실행 결과
journalctl -u backup.service # 실행 로그(여기 다 남는다)
systemctl start backup.service # 수동 즉시 실행 테스트
cron과 달리 실패 시 status가 빨갛게 뜨고, journalctl -u에 stdout/stderr가 그대로 쌓입니다. "왜 안 돌았는지"를 더는 추측하지 않아도 됩니다.
systemd 유닛과 timer를 직접 만들고 journalctl로 추적하는 실습은 리눅스 트랙에서 회원가입 없이 무료로 해볼 수 있습니다.