Large migrations · Verification · プログレスバーの背後にある証拠
クラウド間で数百 GB を移動: すべてのファイルが到着したことをどのように確認しますか?
500 GB では、「アップロードが完了したように見えた」という証拠にはなりません。信頼性の高い移行には、永続的なインベントリ、すべてのオブジェクトの状態遷移、中断後の反復可能な回復、移行先自体からの証明が必要です。
更新日 ; 16 分で読めます.
簡単な回答
FileArk は、ライブラリをファイルごとのレコードと永続的なキュー メッセージに分割します。ワーカーは 1 つの配信をコピーし、返された宛先 ID を保存し、サイズを検証し、その正確なオブジェクトを読み取り、SHA-256 をソース ペイロードと比較します。これらのチェックが完了し、データベースの更新が成功した場合にのみ、レコードが検証され、メッセージが確認されます。
なぜスケールによって「働いた」の意味が変わるのか
10 個のファイルは簡単に検査できます。 1 万ファイルはそうではありません。大規模な個人ライブラリでは、小さなドキュメント、数ギガバイトのビデオ、空のファイル、ネストされたフォルダー、Unicode 名、アーカイブされたプロジェクト、クラウドネイティブ形式を組み合わせることができます。印象的に見えるパーセンテージの中に、1 つの失敗が隠れている可能性があります。
合計は役に立ちますが、不完全です。 2 つのライブラリは見かけ上のサイズが同じであるにもかかわらず、一方のライブラリにはオブジェクトが欠落しているか、無関係なファイルによってバランスがとれた切り詰められたオブジェクトが含まれている可能性があります。ファイル数は、ネイティブ ドキュメントのエクスポート後またはプロバイダー オブジェクトの除外後でも異なる場合があります。
有用な真実の単位はファイル ジョブです。つまり、どのソース オブジェクトが読み取られたか、どの宛先オブジェクトが作成されたか、比較されたバイト数、検証がいつ完了したか、未解決の試みが残っているかどうかです。
注釈付きの完全な FileArk ライフサイクル
Start が受け入れられると、API はまずスキャン ジョブを MongoDB に書き込み、次に発行者確認を有効にして永続的な RabbitMQ キューに永続スキャン メッセージを発行します。パブリッシュが失敗した場合、ジョブは失敗とマークされ、API はスキャンを安全にキューに入れることができなかったことを報告します。
スキャナーは両方のプロバイダーを認証し、選択されたソースをインベントリし、検出されたバイトに対して有限の宛先クォータをチェックし、各ソース ファイルのデータベース レコードを更新/挿入します。永続的な移行メッセージを発行し、それらの発行が成功した場合にのみスキャンが完了とマークします。
移行ワーカーは手動の確認応答とプリフェッチ数 1 を使用します。コンテンツの読み取り、アップロード、再読み取り、検証、および永続化が行われている間、配信は確認されないままになります。したがって、停止した接続またはプロセスは、未完了の作業をキューに戻すことができます。
データベース行はチェックリスト項目であり、使い捨ての簿記ではありません
すべてのファイル レコードは [保留中] から始まり、試行中に [進行中] に移行し、検証後にのみ [アップロード] に達します。試行回数、最終試行時刻、エラーの詳細、宛先オブジェクト ID、両方の SHA-256 ダイジェスト、検証方法、および VerifiedAt はレコードに添付されたままになります。
完了したレコードは、進行状況および監査証跡としてデータベースに残ります。 「ファイルを削除する」とは、証拠を削除するのではなく、制御された状態の変更を意味します。重複したキューの配信ではその状態が検査され、すでにアップロード済みで VerifiedAt とマークされているレコードが即座に確認されます。
試行が 3 回失敗すると、永続的な問題は失敗となり、試行サイクルの完了タイムスタンプが表示されます。これにより、例外が表示され、ダッシュボードがスタックしているように見える間に有害なメッセージが永久に回転するのを防ぎます。
Pending
→ InProgress (attempt recorded)
→ destination ID stored
→ destination size matches
→ exact destination object re-downloaded
→ source SHA-256 == destination SHA-256
→ Uploaded + VerifiedAt persisted
→ queue message acknowledgedファイルが複数回配信される理由
信頼できるキューは通常、クラウド API、メッセージ ブローカー、データベース全体で魔法のように 1 回限りの配信ではなく、少なくとも 1 回の配信を提供します。 OneDrive または Google Drive がアップロードを受け入れた後、ワーカーが完了を書き込む前にクラッシュが発生する可能性があります。
FileArk は、冪等レコードと宛先リカバリによってその不確実性を処理します。ワーカーはまず、レコードがすでに検証されているかどうかを確認します。そうでない場合は、保存された宛先 ID を使用するか、再アップロードを決定する前に、中断された結果の予想される宛先パスと正確なサイズを検索できます。
次に、回復候補は、同じ正確なオブジェクトのハッシュ検証を受けます。見慣れたファイル名を見つけるだけでは十分ではありません。重要なのは、中断された試みを楽観的な成功に変えるのではなく、証拠に戻すことです。
目的地と作業者の能力をチェック
ファイルごとのジョブが公開される前に、プロバイダーが有限のクォータを提供するたびに、スキャナーは負でないソース メタデータ サイズを合計し、その要件を宛先の報告された残りのストレージと比較します。宛先のサイズが小さすぎると、既知の行き止まりに作業を送り込む代わりに、スキャンに失敗します。
この数字はプリフライトであり、保証ではありません。アカウント アクティビティは実行中にスペースを消費する可能性があり、プロバイダー クォータ レポートに遅延が生じる可能性があり、エクスポートされたクラウド ネイティブ ファイルは従来のソース サイズではない可能性があります。プロバイダーの強制とファイルごとのエラー処理はアクティブなままです。
コンピュータのディスクはステージングには使用されません。移行ワーカーでは、ボリュームに予期されるオブジェクト用のスペースと 2 GB の予約が追加された後でのみ、メモリしきい値を超えるファイルが分離された一時ディレクトリに配置されます。一時コンテンツは、試行が成功するかスローされるかに関係なく、クリーンアップで削除されます。
宛先 ID と SHA-256 が重要な理由
ファイル名は一意の ID ではありません。宛先には、同じ表示名を持つ 2 つのファイルがすでに含まれているか、メタデータのリストが確定するまでに時間がかかる可能性があります。アップロード応答はプロバイダー オブジェクト ID を提供し、FileArk は最終検証段階の前にその ID を保存します。
ワーカーはソース ペイロード ストリーム全体で SHA-256 を計算してアップロードし、その ID で正確な宛先オブジェクトを開いて、再度 SHA-256 を計算します。サイズが等しいと、明らかな切り捨てが検出されます。等しい暗号ダイジェストは、より強力なバイトレベルのチェックです。
転送されたファイル表現のみが対象となります。ダイジェストでは、共有ルール、コメント、バージョン、ラベル、ショートカット、保持設定、またはエクスポートされた Google ドキュメントがユーザーに表示される方法を検証できません。これらは受け入れタスクのままです。
ソースの削除は意図的に通常の成功パスから外れています
最も安全なデフォルトはコピーのみで、FileArk の削除オプションは有効にしない限りオフになっています。削除が無効になっている場合、削除は要求されないため、検証が失敗してもオリジナルを削除できません。
移動後の削除を意図的に有効にした場合でも、ワーカーは送信元プロバイダーの削除操作を呼び出す前に、宛先 ID、サイズ、SHA-256 検証を待機します。かけがえのないライブラリや非常に大規模なライブラリの運用上のより強力な選択肢は、依然としてオプションをオフのままにし、人間が承認した重複期間を使用することです。
移行は「検証済みのコピーが到着しましたか?」と答えます。保持は「古いコピーはいつ削除できますか?」という質問に答えます。それらを別個の証拠を持つ別個の決定として扱います。
同じ制御モデルが双方向で機能します
OneDrive から Google Drive への場合、ソース ペイロードは Microsoft Graph から読み取られ、宛先オブジェクトは返された ID によって Google Drive を通じて検証されます。 Google ドライブから OneDrive への場合、ソースは Google ドライブを通じてダウンロードまたはエクスポートされ、新しい OneDrive アイテムは Microsoft Graph を通じて読み取られます。
キュー、データベースの状態、制限された試行回数、キャパシティ プリフライト、ソース ダイジェスト、宛先 ID、宛先ダイジェスト、および確認応答の順序は、方向に中立です。プロバイダー アダプターは、さまざまなアップロード、フォルダー、コンテンツ API を処理します。
非対称性はコンテンツの意味論です。 Google ネイティブのドキュメントはエクスポートする必要があり、両方のプラットフォームにはサービス固有の共有とバージョンの動作があります。バイト検証されたファイル コンテンツは、すべてのコラボレーション機能の完全なクローンとして販売されるべきではありません。
4 部構成の受け入れ計画を使用する
システムレコードを調整する
完了数、保留中数、進行中数、失敗数を確認します。全体の割合が高いため、失敗したアイテムを振り払う必要はありません。
リスク別のサンプル
失うと最も大きな問題となるファイルに加えて、大きなメディア、アーカイブ、古いドキュメント、英語以外の名前、ネストされたパス、変換されたクラウドネイティブ ファイルを開きます。
宛先の動作を検証する
実際のデバイスとユーザーからのアクセスをテストします。必要な共有を再構築し、Office またはエクスポートされた Google ファイルが期待どおりに開くことを確認します。
重複期間を保持する
通常の使用でデスティネーションを実行している間、ソースを利用可能かつ安定した状態に保ちます。キャンセルまたは削除の決定は後で行ってください。
よくある質問
FileArk はファイルごとにキューを使用しますか?
はい。スキャナーはソース ファイルごとにデータベース レコードを作成または再利用し、永続的な移行メッセージを発行します。ワーカーは手動の確認応答を使用してこれらのメッセージをプルします。
キューメッセージはいつ承認されますか?
宛先オブジェクト ID、サイズ、SHA-256 が検証され、Uploaded および VerifiedAt 状態が保持された後。未完了の配達は再配達することができます。
完了したファイル レコードはデータベースから削除されますか?
いいえ、完了は永続レコードの状態遷移です。この行には、宛先の ID、検証証拠、タイミング、および進行状況と監査のための試行情報が保持されます。
SHA-256 は移動されたアクセス許可とバージョンを証明できますか?
いいえ。これにより、宛先ファイルのバイトが転送されたソース ペイロードと一致することが証明されます。共有、権限、バージョン、コメント、ラベル、ショートカット、およびプロバイダー固有の動作については、個別の検証が必要です。
OneDrive から Google Drive への変換は、その逆と同じ方法で検証されますか?
コア ルールは両方向で同じです。つまり、ソース ペイロード ダイジェスト、宛先オブジェクト ID、宛先サイズ、正確なオブジェクトの再ダウンロード ダイジェスト、永続的な検証、キューの確認応答です。