元の ZimaOS 1.5.3 の「常時」スケジュールには、LAN／クラウドのバックアップソースを毎日午前 1:00 にチェックすると実際に記載されていましたが、複数のユーザーからジョブが自動的に開始されないとの報告がありました。手動実行は機能したため、問題は基本的なソースや保存先へのアクセスではなく、スケジュールやサービスの動作にあると考えられました。
icewhale-files-backup.service を再起動する回避策によって一部のユーザーではジョブが実行されましたが、元の投稿者はこの方法を信頼できないと明確に述べています。これは診断用の回避策として扱い、通常のスケジューラーとして推奨すべきではありません。
1.5.3 の UI が示していた内容
Zima／USB ソースの場合、「常時」はファイルの変更に反応することを意味していました。クラウドまたは LAN ソースの場合、ツールチップにはデバイス時刻の午前 1:00 に 1 日 1 回チェックすると説明されていました。
手動実行に成功しても、スケジューラーが機能しているとは限らない
「今すぐ実行」が成功する場合、ソースの認証情報、パスへのアクセス、保存先への書き込みはおそらく正常です。次に確認すべきなのは、デバイスのタイムゾーン、タスクのスケジュール状態、および想定される実行時刻前後のバックアップサービスです。
サービス再起動の回避策はコミュニティで検証されたが、理想的ではない
あるユーザーは icewhale-files-backup.service を再起動するとジョブが実行されることを発見し、その再起動を cron でスケジュールしました。別のユーザーは同じ目的で Zima Cron を使用しました。元の投稿者は、通常の crontab は ZimaOS のアップデートで消去される可能性があると指摘しています。
現在のZimaOS バックアップガイドでは、この古いサービス再起動パターンに頼るのではなく、独立してスケジュール設定するタスクが説明されています。
後のバージョンでは別のバックアップ障害が発生した
1.6.1 へのアップグレード後、実行されたように見えるもののファイルを移動しないジョブが報告されました。これは「午前 1 時のトリガーがまったく実行されなかった」という症状とは異なるため、別々に診断する必要があります。
古い回避策を使い続ける前に、現在のバックアップアプリを使用する
現在の安定版 ZimaOS でタスクを再作成し、明示的なスケジュールを設定して、デバイスのタイムゾーンを確認してください。最初の正常な実行後には、テストファイルを復元します。ZimaOS バックアップ概要では、現在の製品モデルが説明されています。
まとめ
1.5.3 のスレッドは、LAN／NAS バックアップソースで実際にスケジューラーの問題が発生していたことを示していますが、毎晩サービスを再起動する方法はあくまで回避策でした。現在の ZimaOS では、最新のスケジューラーでタスクを再現し、タイムゾーンとログを確認してください。また、「ジョブが開始されなかった」ケースと「ジョブは開始されたが何も転送されなかった」ケースは分けて扱う必要があります。
