この設計目標は妥当です。RAID 0 SSDは本当に最大スループットが必要なワークロードにのみ使用し、その高リスクな作業用プールを独立したHDDバックアップで保護して、少なくとも1つのコピーをオフサイトに保管します。RAID 0には冗長性がないため、SSDが1台故障するだけで作業用アレイ全体がオフラインになる可能性があります。
2025年のコミュニティでの回答では、単独で運用するローテーション式HDDと毎晩のrsyncが推奨されていましたが、元の投稿者は重要な異議を唱えました。ZimaOSにはすでにBackupのAutoモードがあり、古いHDDを同じベイに戻したときに自動認識されるのかを知りたかったのです。このスレッドは、その疑問への回答がないまま終了しました。現在のIceWhale公式ドキュメントでは、より明確なサポート対象の基本構成が示されています。Backupアプリは、スケジュールタスク、複数の独立した保存先、再開・障害耐性、バージョン付き復元ポイントに対応しています。ただし、現在公開されているドキュメントには、「古いHDDを同じベイにホットスワップすれば、ディスクの識別情報に基づいて自動的に照合される」ことを保証するワークフローの記載はありません。
RAID 0には実用的なバックアップ計画が必要
RAID 0は、パリティやミラーリングなしでSSDを結合し、容量と性能を向上させます。メンバーディスクが1台故障するだけで、アレイ全体が失われる可能性があります。プロフェッショナルな作業では、バックアップを後から追加するものではなく、設計の一部として扱うべきです。
単独運用のバックアップHDDはRAID 1よりローテーションに適している
コミュニティでは、2台の26 TB HDDをRAID 1で組み合わせるのではなく、それぞれを独立して運用することが推奨されました。こうすれば各ディスクが完全な取り外し可能・オフサイト保管可能なコピーになり、ドライブをローテーションするたびにミラーを再構築する必要もありません。
これはコミュニティによる設計上の推奨であり、IceWhaleの要件ではありません。RAID 1は、両方のHDDを接続したまま運用する場合の可用性を高められますが、物理的なローテーションやオフサイト保管の仕組みとしては扱いにくい構成です。
現在のZimaOS Backupは中核となる3-2-1ワークフローに対応している
現在のIceWhale公式ドキュメントによると、1つのBackupアプリで、Zima、USB、LAN、クラウドをソースまたは保存先として使用でき、タスクをスケジュール実行し、中断した転送を再開し、バージョンや復元ポイントを保持できます。また、1つのソースから異なる保存先へ複数のタスクを管理できます。
現在のZimaOS Backupモデルを使用してください。
2025年の「Autoは変更のたびに即時実行」という表現をそのまま固定的に解釈しない
元の投稿者は、ファイルが変更されるとZima/USBソースが即時実行できるというUI上の説明を引用していました。同じ時期に行われた別の公式コミュニティ上の議論では、ZimaOS BackupのAutoは特定の時刻、通常は早朝に実行されると説明されていました。元の情報自体では、これらの説明がどう両立するのかは明らかにされていません。
現在公開されているドキュメントではスケジュールバックアップが説明されており、変更のたびにファイルシステムイベントを検知して複製することは保証されていません。本番環境の計画では、古いUI上の表現に頼らず、現在文書化されているスケジュールを使用してください。
rsyncはミラーリング・転送ツールであり、自動的にバージョン管理バックアップになるわけではない
コミュニティのスクリプトでは、次のコマンドが使用されていました。
rsync -avh --delete ...--deleteフラグを使うと、保存先はRAID 0ソースでの削除を反映したミラーになります。ミラーとしては便利ですが、誤って削除した内容までバックアップディスクに反映される可能性があります。
rsyncを使用する場合は、破壊的なフラグを付けずに開始し、--dry-runを使用して、対象パスを確認してください。削除からの復旧が必要な場合は、スナップショットやバージョン管理を別途設計します。
ドライブのローテーションには、安定した識別情報と明示的な確認が必要
ディスクを1つの物理ベイに差し替えても、挿入したディスクが常に同じマウント名やパスになるとは限りません。堅牢なローテーション手順では、安定したデバイスまたはストレージの識別情報でディスクを特定し、想定した保存先がマウントされていることを確認してからバックアップを開始します。
「何か」が以前の保存先パスにマウントされているというだけの理由で、破壊的なミラーリングジョブを実行しないでください。
重要な作業では、数か月ごとより頻繁にオフサイトコピーをローテーションする
3〜4か月ごとのローテーションでは、オンサイトの作業用プールとローカルバックアップを同時に失った場合に、復旧可能時点の大きな空白が生じます。適切な間隔は変更量や業務上許容できる損失によって異なりますが、重要なプロフェッショナルデータでは、通常より頻繁なオフサイト運用が適しています。
ローテーションを信頼する前に復元をテストする
各バックアップHDDから代表的なプロジェクトやファイルを復元し、チェックサムまたはアプリケーションで読み取り可能かどうかを確認してください。そのうえで、ディスクをオフサイトに移す前に、最後に成功したバックアップの日付を記録します。
RAID 0バックアップに関するFAQ
バックアップHDDをRAID 1にすることは、独立したバックアップをローテーションするのと同じですか？
いいえ。RAID 1は、両方のドライブがミラーの一部である間の可用性を高めます。一方、独立したディスクは取り外して別々のコピーとしてオフサイトに保管しやすくなります。
現在のZimaOS公式ドキュメントでは、変更ごとの完全なリアルタイム複製が保証されていますか？
現在公開されているBackupのドキュメントでは、スケジュールタスク、再開・障害耐性、バージョン管理が説明されており、ファイルシステムイベントによるミラーリングが保証されているわけではありません。
rsync --deleteはZimaOS Backupより自動的に安全ですか？
いいえ。これは削除を意図的にミラーリングするため、保存先を慎重に検証する必要があります。また、誤操作から復旧したい場合は、別途バージョン管理も必要です。
