中断したSFTP転送を再試行する

現在のSFTPゲートウェイでは、ダウンロードとアップロードの復旧方法が異なります。読み取りはオフセットを受け付けるため、変更されていないリモートファイルのダウンロードは再開できます。書き込みハンドルは空の状態で開始され、CLOSE時にのみ確定します。サーバーは既存の先頭部分を再読み込みしないため、アップロードのResume、Append、reput、put -aを使うと先頭のバイトが欠ける可能性があります。これらは使用しないでください。

CLOSEが成功する前に中断したアップロードは、通常、確定済みのリモートファイルを残しません。確定後にクライアントがレスポンスを受け取れなかった場合、完全なファイルや新しいバージョンがすでに存在することがあります。不要な置換を避けるため、再実行する前にdosyaで確認してください。

手順

1. 失敗した操作がアップロードかダウンロードか、転送元と転送先のパス、最後のクライアントメッセージ、両側に現在表示されている容量を記録します。汎用の再開ボタンはまだ押さないでください。
2. ダウンロードの場合、ローカルへの部分的なコピーを開始してからリモートの名前、バイト数、バージョンが変わっていないことを確認します。いずれかが変わっていたら、ローカルの部分ファイルを削除または隔離して先頭からやり直してください。
3. 変更されていないダウンロードはクライアントのオフセット読み取り機能で再開し、最終容量とローカルのチェックサムを信頼できる転送元と比較します。dosyaは64 MiB以上のファイルに対する大きな読み取りを、範囲が制限されたキャッシュから提供します。
4. アップロードの場合、dosyaのファイルで対象フォルダーを確認し、SFTPでも一覧を更新します。転送先に完全なファイルがすでにあれば残してください。そうでなければ、一意の一時的な名前でローカルファイル全体をオフセット0からアップロードし直します。
5. やり直したアップロードの最終CLOSEレスポンスを待ち、リモートの一覧で名前と容量を比較して、ダウンロードし直してチェックサムを確認します。別のコピーの置換や削除は検証後にのみ行ってください。
6. 再試行でAPI 429が返された場合は、指定された待機時間に従ってください。ネットワークエラーや5xxエラーの後にCLOSEの結果が不明な場合は、再び書き込む前に転送先を確認します。内容が異なる場合は両方のファイルを保持してください。

既存の名前への完全なアップロードは、dosyaのバージョン管理された書き込み処理に従い、保持ルールに基づいて以前のバージョンを残しながら現在のバイトを置き換えることがあります。新しい名前でやり直すと、検証が完了するまで既存ファイルの現在のバイトを変更せずに済みます。現在のゲートウェイでは空のアップロードは確定されません。

現在のアップロード上限は352 MiBです。ワークスペースのポリシー、残りのストレージ、ロールや認証情報の制限により、より小さなファイルも拒否される場合があります。適用中の上限を超えて失敗する場合は、オフセットを使った回避策ではなく、対応している別のアップロード方法を使用してください。

期待される結果

変更されていないダウンロードが再開され、検証済みの完全なローカルファイルになります。またはアップロードが先頭からやり直され、検証済みのリモートコピーが1件だけ確定されます。不完全な先頭部分が有効なdosyaのアップロードとして扱われることはありません。

関連ガイド

• SFTPクライアントを接続する
• SFTPのトラブルシューティング