기존 ZimaOS 1.5.3의 “항상” 일정은 LAN/클라우드 백업 소스를 매일 오전 1시에 확인한다고 실제로 안내했지만, 여러 사용자가 작업이 자동으로 시작되지 않았다고 보고했습니다. 수동 실행은 정상적으로 작동했으므로, 문제는 기본적인 소스 또는 대상 접근 권한이 아니라 일정 예약 및 서비스 동작에 있는 것으로 좁혀졌습니다.
icewhale-files-backup.service를 다시 시작하면 일부 사용자의 작업이 실행되었지만, 원 게시자는 이 방법을 신뢰할 수 없다고 명시했습니다. 따라서 이는 진단용 우회 방법으로만 유지하고, 일반적인 일정 예약 방법으로 권장해서는 안 됩니다.
1.5.3 UI에서 안내한 내용
Zima/USB 소스의 경우 “항상”은 파일 변경에 반응한다는 의미였습니다. 클라우드 또는 LAN 소스의 경우 툴팁에는 기기 시간 기준 매일 오전 1시에 한 번 확인한다고 설명되어 있었습니다.
수동 실행 성공이 일정 예약의 정상 작동을 의미하지는 않음
“지금 실행”이 성공한다면 소스 인증 정보, 경로 접근 및 대상 쓰기는 정상적으로 작동할 가능성이 높습니다. 다음으로 확인할 항목은 기기 시간대, 작업 일정 상태, 그리고 예상 실행 시간 전후의 백업 서비스입니다.
서비스 재시작 우회 방법은 커뮤니티에서 확인되었지만 이상적인 방법은 아님
한 사용자는 icewhale-files-backup.service를 다시 시작하면 작업이 실행된다는 사실을 확인한 뒤, cron으로 해당 서비스를 재시작하도록 예약했습니다. 또 다른 사용자는 같은 목적에 Zima Cron을 사용했습니다. 원 게시자는 일반적인 crontab 설정이 ZimaOS 업데이트로 삭제될 수 있다고 언급했습니다.
현재의 ZimaOS 백업 가이드에서는 이제 이전의 서비스 재시작 방식에 의존하지 않고, 독립적으로 예약된 작업을 설명합니다.
이후 버전에서는 다른 백업 실패가 나타남
1.6.1로 업그레이드한 후 한 사용자는 작업이 실행되는 것처럼 보이지만 파일이 전혀 이동하지 않는다고 보고했습니다. 이는 “오전 1시 트리거가 아예 실행되지 않음”과는 다른 증상이므로 두 문제를 পৃথ로 진단해야 합니다.
오래된 우회 방법을 유지하기 전에 현재 백업 앱 사용
현재 안정 버전의 ZimaOS에서 작업을 다시 생성하고, 명시적인 일정을 설정하며, 기기 시간대를 확인한 다음 첫 번째 성공적인 실행 후 테스트 파일을 복원해 보세요. ZimaOS 백업 개요에서 현재 제품 모델을 확인할 수 있습니다.
결론
1.5.3 관련 글은 LAN/NAS 백업 소스에서 실제 일정 예약 문제가 발생했음을 보여주지만, 매일 밤 서비스를 다시 시작하는 방법은 어디까지나 우회 방법일 뿐이었습니다. 현재 ZimaOS에서는 최신 일정 예약 기능으로 작업을 재현하고, 시간대와 로그를 확인하며, “작업이 시작되지 않음”과 “작업은 시작했지만 아무것도 전송하지 않음”을 별개의 문제로 다루세요.
