2026年4月のこのスレッドは、バックアップとセルフホスト型メールを扱う「ZimaOSを使い始めたばかりで圧倒されているユーザー」の幅広い投稿として始まりました。メールの問題は最終的に二次的なものとなり、ユーザーはMailcowを必要十分に使える状態にしました。未解決の技術的な問題はZimaOS Backupで、表示されるサイズに一貫性がなく、初回実行は通常完了する一方、その後の実行ではディスク活動がないまま停止することがありました。
この情報が特に有用なのは、ユーザーが複数のZimaBoard 2、複数の内蔵・外付けドライブ、Synologyのネットワーク保存先、そして後のZimaOS 1.6.1を試しているためです。したがって、この問題を単一の不良USBディスクや、1つの誤ったネットワークパスだけの問題として要約すべきではありません。
ユーザーが望んでいたのはアーカイブ形式ではなく、シンプルな災害対策バックアップでした
望まれていたワークフローは単純なものでした。1:1形式のバックアップを手動で開始し、認識しやすいフォルダー構造を維持し、暗号化や不透明なパッケージを避け、ZimaBoard 2全体が故障した場合でも迅速に復旧できるようにすることです。
この想定は、過去のコピーを意図的に保持するバージョン管理バックアップソフトとは異なります。世代保持を有効にしている場合、保存先の使用量が現在のソースデータセットのサイズを上回ることは正当です。
メールサーバー側の問題は最終的に切り分けられた
元の投稿では、Synology Mail Plusの置き換えに苦労していることも説明されていました。Zima-JerryはStalwartを提案しましたが、ユーザーには特にPOP3による取得機能が必要でした。4月16日までに、ユーザーはMailcowが動作し、他のアプリケーションにも満足していると報告しました。
この結果は、後のBackupに関する議論が、Mailcow自体がストレージ問題を引き起こした証拠だと誤解されるのを防ぐため、記録しておく価値があります。
バックアップ先のサイズが実際と一致しなかった
あるボードでは、ソース側の約800 GBが保存先ディレクトリでは約2.7 TBに相当していました。別のボードでは、ソース側の約105 GBに対し、保存先では約2 GB分が不足しているように見えました。
バージョン保持によって一部の容量増加は説明できますが、2回目の実行停止は説明できません
Zima-Jerryは「予約バージョン」機能が有効になっているか尋ねました。以前のバージョンを保持すると、バックアップ先の容量が現在のライブソースより大きくなるのは正常な場合があります。
しかし、その後ユーザーは新しくフォーマットした外付けUSBディスクでテストをやり直し、別の失敗を記録しました。初回のバックアップは完了しましたが、2回目は一部のデータをコピーした後、進行しなくなりました。
クリーンなUSBテストで2回目の実行失敗を再現
ユーザーは古いジョブを削除し、ZimaBoard 2を再起動し、外付けドライブをフォーマットして、バージョン保持を有効にした新しい手動バックアップを作成しました。初回の実行にはほぼ2日かかり、約1.25 TBのコピーに成功しました。
Filesを通じてドライブを取り外して再接続すると、2回目の実行では一部の変更がコピーされた後、進行状況バーが停止し、USBのアクティビティLEDも消えました。Synologyを保存先にした場合も同じ挙動が発生していました。
IceWhaleがバックアップの挙動をエスカレーション
Zima-Jerryは、入念なテストに感謝し、調査のため開発チームに問題を引き継ぐと述べました。
その後のIceWhale関連の返信では、既知の問題領域が2つに分けられました。すべての /media/ZimaOS-HD 以前はDockerのパイプ／ソケットの内容も含まれており、バックアップ進行状況の表示精度にもなお改善が必要でした。
システムドライブ全体のバックアップは、復元可能なシステムイメージとは異なります
その後、議論は災害復旧に移りました。チームからの返信では、システムディスク全体を無差別にバックアップすると、使い捨てのDocker／ランタイムファイルまで含まれてしまい、「このフォルダーを復元すればZimaOSシステム全体が以前とまったく同じ状態に戻る」というサポート対象のワークフローが自動的に提供されるわけではないと説明されました。
災害対策では、ユーザーデータ、アプリケーションデータ、データベース、設定、そして交換可能なコンテナイメージを区別してください。
ZimaOS 1.6.0でストレージ復旧メタデータが変更
後の公式回答では、ZimaOS 1.6.0以降、ストレージデバイスをどのようにマウントすべきかを示す情報もストレージ自体に書き込まれるようになったと説明されています。これは、システムディスクに問題が発生した後でも、RAIDまたは単一ディスクのストレージを再認識しやすくすることを目的としています。
これによりアレイの復旧性は向上しますが、RAIDがバックアップになるわけではなく、ソースユーザーの2回目のBackup実行時のハングがそれだけで解消されるわけでもありません。
ユーザーはZimaOS 1.6.1でも問題を再現しました
4月27日、元の投稿者は、初回バックアップは引き続き正常に動作したものの、2回目以降の実行では6時間以上ハングし、その後の書き込みアクティビティがなかったと報告しました。Backupを閉じて再度開くと、保存先が0 Bと表示されることがありました。
4台の内蔵ドライブ、2台の外付けUSBドライブ、3台のZimaBoard 2システムでそのパターンをテストしたと述べています。
現在のバックアップワークフローは進化しています
現在のZimaOSドキュメントでは、3-2-1戦略の一環として、ローカル、USB、NAS、クラウドの保存先へのスケジュールバックアップタスクが説明されています。
1.5.x/1.6.1のインターフェースが現在も同じように動作すると想定するのではなく、現在のZimaOSバックアップワークフローと保存先オプションを使用してください。
現在のガイドだけでは、このスレッドにある過去の2回目実行時の不具合がすべて修正されたことは証明できないため、使用するバージョンで実際の復元動作を確認してください。
進行状況バー以外でバックアップを検証する
- 可能な範囲で、ソースと保存先のファイル数を比較する。
- Backup UIだけでなく、実際の保存先の容量を確認する。
- 2回目、3回目の増分実行またはバージョン管理付き実行をテストする。
- 代表的なファイルを別の場所に復元する。
- どのアプリケーションのデータベースや設定を別途バックアップする必要があるかを記載します。
ZimaOSバックアップに関するよくある質問
ソース側の問題はSynology NASでのみ発生しましたか？
いいえ。ユーザーは外付けUSBドライブでも同様のフリーズを再現しました。
最初のバックアップは失敗しましたか？
管理された初回実行は完了しましたが、繰り返し発生する問題はその後の実行で現れました。
ZimaOS 1.6.1では問題は解消しましたか？
いいえ。元の投稿者は、そこで再現することも明確に述べています。
バックアップ先が現在のソースより大きくなることは、正当な動作ですか？
はい、バージョン保持が有効な場合はそうですが、それだけではスレッド内のすべての表示問題やジョブのフリーズ症状を説明できません。
