本文へスキップ

100TB のデータを安全に移行する方法

所要時間、物理メディアによる初期搬送、再開可能なコピー、ファイル一覧、チェックサム、差分転送、切り替え時の検証から100TB移行を計画します。

WarpSend エンジニアリング レビュー Charlie 更新 5 分で読めます

100 TB を別拠点へ移す場合、初回コピーだけで何日もかかり、その間にも元のデータは更新されます。完了時刻を見積もるには、全量コピー、更新分の反映、検証、サービス切り替えに必要な時間を分ける必要があります。

まずネットワーク転送と物理メディアの搬送を比較し、その後に再開方法と検証手順を決めます。移行先で業務を再開し、問題があれば戻せる状態までを計画に含めてください。

ネットワーク下限を計算する

10 進数の TB を使い、通信のオーバーヘッドを含めない計算です。70% の列は計画用の仮定で、一般的な達成率ではありません。

持続速度100TB 下限回線の 70% 利用時
100Mbps92.6日132.3日
1Gbps9.3日13.2日
2Gbps4.6日6.6日
10Gbps22.2時間31.7時間

秒 = バイト × 8 ÷ ビット/秒。読み書き、ファイルごとのメタデータ、暗号化、再試行、検証は別です。転送時間計算ガイドに実測持続値を使い、スイッチの公称値をそのまま使わないでください。

複数 TB 移行の 5 原則

  1. ノート PC がエンドポイントでない限り、データを PC 経由にしない。
  2. 中断再開、失敗一覧、履歴を持つツールを使う。
  3. 初回一括コピーの後、書き込み停止後に差分を合わせる。
  4. 「Completed」だけでなく独立したファイル一覧で検証する。
  5. 実運用と復元テストが終わるまで切り戻し用の送信元を消さない。

4 つの上限を測る

  • **送信元ストレージ:**整合性検査、再構築、索引、業務負荷中も読めるか。
  • **宛先ストレージ:**メタデータ、チェックサム、暗号化、バックグラウンド処理中も書けるか。
  • **経路:**双方向スループット、遅い側の上り、RTT、損失、NAT/リレー、速度制御。
  • **ファイル構成:**100GB 1 本と数千万小ファイルは別の負荷。

オンラインか物理シードか

物理シードは初回データを暗号化メディアへコピーして輸送・インポートし、後の変更だけをネットワークで送ります。オンラインが数週間、WAN を業務と共有、流量費が高い、明確な差分が取れる場合に検討します。

シード時間 = 書き出しコピー + ソース検証 + 輸送 + 取り込みコピー + 宛先検証 + 最終差分

1Gbps を 70% 利用すると 100TB は約 13.2 日です。書き出し 2 日、検証 1 日、輸送 2 日、取り込み 2 日、差分 1 日なら約 8 日で物理搬送の方が早く終わる可能性があります。一方、持続数 Gbps 以上なら 2 回の追加コピーと配送が遅い場合があります。

初期データの搬送には、対象製品が正式に対応する手順を使います。Synology Snapshot Replication は初期コピーのエクスポートとインポートを提供しますが、通常のディスクコピーだけで別製品の複製状態を作れるとは限りません。

再開可能な転送を選ぶ

100 TB の転送では、中断するたびに完了済みデータを送り直すと、予定を大きく超える可能性があります。ファイルまたはチャンク単位の完了状態を保持でき、失敗一覧と時刻が残り、欠落や変更だけを再実行できるツールを選びます。必要な整合性検証にも対応しているか確認してください。

rsync の中断ファイル保持は有用ですが、--partial、--partial-dir、ACL、拡張属性、削除の扱いを公式マニュアルで確認し、代表データで試します。WarpDirect は対応エンドポイント間の再開可能な暗号化ファイル移動に使えますが、DSM パッケージ、スナップショット履歴、アプリケーション設定は移行しません。

送信元のファイル一覧を作る

データセット名、ファイル/ディレクトリ数、論理サイズと割り当て済みサイズ、大きなファイル、スパースファイル、ハードリンク、非対応名、所有者、権限、タイムスタンプ、拡張属性、必要なハッシュ、書き込みアプリを記録します。

「十分に同等」の定義も先に決めます。メディアアーカイブならパス、バイト、更新時刻、ハッシュ、ホームディレクトリなら所有者、グループ、ACL、拡張属性、データベース/VM ならアプリケーション整合性を保った書き出しが必要かもしれません。

一括コピー、差分、切り替え

  1. 稼働中に初回一括コピー。
  2. 失敗、非対応、権限を修正。
  3. 新規書き込みを停止または厳格に制御。
  4. 一括コピー後の追加・変更だけを送る。
  5. ファイル一覧、ハッシュ、アプリ、利用者権限を検証。
  6. サービスを宛先へ切り替える。
  7. 切り戻しの判断期間終了までソースを保持、可能なら読み取り専用。

最終差分の量と検証にかかる時間が、切り替え時の停止時間に影響します。

3 層で検証する

層問い証拠
転送内容受信内容は送信内容と一致したかチェックサム、再試行ログ、完了済みチャンク
ファイル一覧必要な全パスを選んだか両端のファイル一覧、件数、バイト、欠落一覧
アプリケーション業務が宛先で動くかメディア再生、プロジェクト、DB 復旧、権限、利用者の受領確認

全量のハッシュ計算にも容量とストレージ性能に応じた時間がかかるため、一括コピー前または中に生成して別保管し、最終差分では必要な比較だけを更新します。最速のコピーでも、宛先が完全・利用可能・復元可能でなければ移行成功ではありません。

よくある質問

100TB の転送には何日かかりますか?

ネットワークだけの理論下限は 100Mbps で約 92.6 日、1Gbps で 9.3 日、2Gbps で 4.6 日、10Gbps で 22.2 時間です。実際は利用率、ストレージ、ファイル数、再試行、検証を加えます。

100TB はドライブを配送した方が速いですか?

上りが遅い、または高価なら多くの場合そうです。ただしドライブへのコピー、暗号化、両端検証、輸送、インポート、最終差分まで含めて比較します。

大規模移行の完全性をどう検証しますか?

送信元のファイル一覧を作り、パス、件数、総バイトを比較し、リスクに応じて暗号学的ハッシュを使います。停止後の差分を行い、利用者とアプリが検証するまでソースを読み取り専用で保持します。

5TB や 20TB にも同じ手順を使えますか?

使えます。棚卸し、測定、再開可能経路、初回一括コピー、書き込み停止、差分、検証、切り戻し用コピーは同じで、規模が大きいほど記録と切り替えを厳格にします。