元のユーザーの問題は、単に「2台のZimaOSボックス間でデータをコピーできない」というものではありませんでした。ZimaOS 1.5.xを実行しているシステム間で約600 GBを移動していたところ、両方のサーバー自体はオンラインのままだったにもかかわらず、Filesの転送が「ホストがダウンしています」というメッセージで繰り返し停止していました。
この過去の挙動は、現在のZimaOSとは分けて考える必要があります。IceWhaleは現在、別のNASからデータを移動する際にFilesのLANストレージを使用することを明確に推奨しています。また、現在のBackupアプリでは別のZimaデバイスを保存先に指定でき、再開可能で耐障害性のあるジョブを利用できます。非常に大規模な転送では、1回限りの目に見えるコピー、再開可能な保護タスク、最速の物理的なデータ移送のどれを目的とするかに応じて方法を選択してください。
両方のホストがオンラインのままでも、元のFiles転送は繰り返しリセットされた
ユーザーは、古いZimaOSボックスから送信する場合と、新しいボックスから取得する場合の両方向を試しました。どちらの場合も、ソースのダッシュボードには引き続きアクセスできたにもかかわらず、ブラウザーベースのFilesワークフローは最終的に停止しました。
コミュニティでは、最も再開しやすいCLIオプションとしてrsyncが推奨された
コミュニティからの返信では、転送が中断されても最初からやり直さずに再実行できるよう、部分転送に対応したSSH経由のrsyncが提案されました。これは上級者向けの有用な案内ですが、IceWhaleのスタッフによる投稿ではなく、元のユーザーも実際に使用したとは確認していません。
現在のIceWhaleの案内でも、NAS間の移行にはFilesを使用する
現在のZimaOSドキュメントでは、古いNASをFilesのLANストレージとして追加し、フォルダーを新しいZimaOSストレージへコピーする方法を推奨しています。したがって、以前の1.5.xのタイムアウトを「大規模な移行にはFilesを絶対に使わない」と一般化すべきではありません。
通常の目に見えるコピーには、現在のLANストレージ移行ワークフローを使用してください。
現在のBackupでは別のZimaデバイスを保存先に指定できる
手動で保存先を閲覧するよりも再開機能が重要な長時間転送では、現在のBackupアプリで別のZimaデバイスを保存先として使用できます。IceWhaleは、スケジュール設定、リアルタイムの進捗表示、再開、耐障害性を案内しています。
現在の再開可能なZima間バックアップワークフローを参照してください。
SMBはブラウザーコピーの仕組みに代わる分かりやすい方法
元のコミュニティでは、保存先にソースのSMB共有をマウントし、保存先側からコピーする方法も推奨されました。ユーザーは以前、マウントしたSMB共有を使って古いNASからZimaOSへ正常にデータを移動していました。
ボックスが物理的に近い場合は、USBまたはNVMeによる移送が最速になることがある
数百GBから数TBのデータでは、高速な外付けSSD/NVMeを使うことで、ネットワークに関する要因をすべて回避できます。その代わり、ソースから移送用ドライブへ、続いて移送用ドライブから保存先へという2回のコピーが必要です。
小さなファイルが多いと、移行が大幅に遅く見えることがある
AppData、サムネイル、写真のサイドカーファイル、コードツリー、その他のメタデータが多いデータセットは、各ファイルでオープン、作成、メタデータ処理が必要になるため、大容量のメディアファイルよりもはるかに遅く移動することがあります。
ソースを削除する前に確認する
移行後は、代表的なフォルダー、可能な範囲でのファイル数、保存先にある重要なファイルを開けるかどうかを確認してください。新しいボックスを正常に使用でき、バックアップが存在するまで、ソースはそのまま保持してください。
FilesとBackupは異なる移行上の問題を解決する
ソースを参照し、特定のフォルダーを選び、コピーされたファイルを保存先ですぐに確認したい場合は、Filesが分かりやすい選択肢です。転送に数時間または数日かかる見込みで、再開機能や耐障害性、スケジュール設定、復元可能なタスク履歴を重視する場合は、Backupの方が適しています。
Backupジョブを透過的な「移動」と呼ばないでください。Backupは独自の復元方式を持つ保護されたコピーを作成するため、ソースを削除する前に保存先の構成を確認してください。
コピー手段を最適化する前にネットワーク経路を確認する
公称1 GbEのリンクでは、両方のマシンが実際にギガビットイーサネットでネゴシエートされていること、Wi-Fiや100 Mb/sの区間が含まれていないこと、スイッチとケーブルが正常であることを確認してください。コピー ツールが物理リンクの遅さを上回ることはできません。
次に、大きなファイルを1つテストしてください。大きなファイルは速いのにディレクトリツリーが遅い場合は、実効ネットワーク帯域幅よりも、データセット内のファイル数やメタデータ処理の負荷が大きな要因である可能性があります。
ユーザーファイルと稼働中のAppDataでは扱いが異なる
動画、写真、ドキュメントは通常のファイルとしてコピーできます。稼働中のアプリケーションデータベースやAppDataは、コピーの整合性を保つために、アプリケーションの停止、エクスポート、またはアプリケーションに対応した移行手順が必要になる場合があります。
稼働中のデータベースディレクトリを2台のボックス間でコピーすれば、正常なアプリケーション移行になるとは限りません。
共有権限は意図的に保持または再構築する
すべてのバイトが到着していても、保存先のZimaOSボックスには独自のユーザー、共有定義、コンテナのマッピングがあります。必要なSamba権限とアプリのボリュームパスを再作成し、想定する非管理者ユーザーとしてアクセスをテストしてください。
重要なデータには2段階の切り替えを使用する
大規模な稼働中NASの移行では、まず古いボックスを稼働させたまま大量のデータをコピーします。切り替え直前に書き込みを停止または一時停止し、最後の増分または再開可能なパスを実行して保存先を確認した後、クライアントを新しいボックスへ切り替えます。これによりダウンタイムを減らし、唯一の正常なコピーを早すぎる段階で削除することを避けられます。
ZimaOSボックス間移行に関するFAQ
この事例は、大規模なコピーではFilesが常に信頼できないことを証明していますか？
いいえ。これは1.5.xで発生した障害事例を記録したものです。現在のIceWhaleの案内では、NAS移行にFiles/LANストレージを引き続き使用しています。
現在、再開可能なZima間転送に対応している選択肢はどれですか？
現在のBackupアプリでは、別のZimaデバイスを保存先に指定でき、再開および耐障害性の機能を利用できます。
rsyncは、元のユーザーが最終的に使用した方法として確認されていますか？
いいえ。rsyncはコミュニティからの助言であり、ユーザーは後に移行が完了したと述べましたが、最終的な転送方法は記録していません。
