crontab -e로 생성한 루트 크론탭이 ZimaOS 재부팅 후 사라진다면, 이는 ZimaOS의 어플라이언스 스타일이자 대부분 읽기 전용인 시스템 구조와 일치하는 동작입니다. 2025년 11월 스레드는 이 증상을 정확히 확인했지만, 일반적인 컨테이너 우회 방법만 제시했습니다.
이제 ZimaOS에 더 적합한 방법이 있습니다. 커뮤니티에서 유지 관리하는 Zima Cron 패키지를 zpkg로 설치하면 ZimaOS에 맞게 설계된 방식으로 예약 작업 구성을 저장할 수 있습니다.
기존 루트 크론탭이 사라진 이유
사용자는 루트 크론 항목을 생성하고 crontab -l로 확인했지만, 재부팅 후 해당 항목이 사라졌습니다. 커뮤니티 답변에서는 장기간 유지되어야 하는 구성은 일반적인 변경 가능한 Linux 시스템 경로가 아니라 ZimaOS의 영구 스토리지에 저장해야 한다고 설명했습니다.
이는 대부분의 시스템 폴더가 읽기 전용이며 사용자 및 앱 데이터는 /DATA 아래에 저장해야 한다는 현재 ZimaOS 지침과도 일치합니다.
/var 스풀 상태를 다시 구성하는 대신 Zima Cron 사용
현재 Zima Cron 튜토리얼에는 zpkg install zima_cron 명령이 안내되어 있으며, 설치 후 Zima Cron이 앱 목록에 표시됩니다. 간격 기반 일정과 일반적인 크론 표현식을 지원합니다.
작업 자체가 일시적인 시스템 경로에 의존하지 않도록 스크립트와 출력 파일은 /DATA 아래에 보관하세요.
실제 백업 작업을 신뢰하기 전에 지속성 테스트
먼저 안전한 작업을 생성하세요. 예를 들어 현재 시간을 /DATA 아래의 로그에 추가하도록 설정할 수 있습니다. 작업이 실행되는지 확인한 뒤 ZimaOS를 재부팅하고, 작업이 여전히 존재하며 새 타임스탬프를 계속 기록하는지 확인하세요.
그 후에야 백업, 정리 또는 동기화 명령을 스케줄러에 추가해야 합니다. 예약 작업 문제 해결 가이드에서는 스케줄러는 유지되지만 명령 자체가 실행되지 않을 때 확인해야 할 다음 단계를 설명합니다.
스케줄러 컨테이너가 여전히 유용한 경우
작업이 하나의 애플리케이션 스택에 속하고 Compose 구성과 함께 버전 관리되어야 한다면 전용 스케줄러 컨테이너를 사용하는 것도 여전히 합리적입니다. 이 경우 해당 컨테이너의 구성을 영구 저장하고, 스케줄링을 담당하는 구성 요소를 명확히 하나로 지정하세요.
Docker 영구 저장 가이드를 참고하면 삭제될 수 있는 컨테이너 계층 내부에 스크립트를 저장하는 일을 피할 수 있습니다.
요약
ZimaOS에서 수동으로 편집한 시스템 크론탭을 영구적인 스케줄링 계층으로 사용하지 마세요. 스크립트와 로그는 /DATA 아래에 저장하고, Zima Cron 또는 의도적으로 영구 저장을 지원하는 다른 스케줄러를 사용하세요. 또한 ZimaOS 재부팅과 앱 또는 컨테이너 재생성 후에도 일정이 유지되는지 반드시 확인하세요.
