中断したSFTP転送を再開する

ダウンロードは、ローカルの部分ファイルが現在のリモートファイルの変更されていない先頭部分である場合にのみ再開してください。中断したアップロードは先頭からやり直してください。 dosyaのSFTPサーバーはオフセット読み取りに対応していますが、書き込みハンドルはOPENのたびに空のバッファーで開始します。クライアントのアップロード再開機能では既存の先頭部分を安全に再構築できません。

この違いはクライアントが再開と上書きの両方を提供していても重要です。一般的なSFTPクライアントに機能があっても、接続先のストレージサーバーがそれに対応しているとは限りません。

再開するか判断する

中断した転送方向	安全な復旧方法
dosyaからコンピューターへのダウンロード	リモートファイルとローカルの先頭部分が変わっていない場合にのみ、OpenSSHのregetなどオフセットに対応したクライアントを使用します。
コンピューターからdosyaへのアップロード	Resume/Appendを無効にし、元のファイル全体を再送します。できれば一意のテスト用または復旧用ファイル名を使用します。
方向または部分ファイルの正体が不明	ローカルの部分ファイルのコピーを保持し、別のパスに新しく転送を開始します。

ダウンロードを再開する場合、クライアントは通常、ローカルの部分ファイルの長さを起点に読み取ります。サーバーはバイトオフセット付きのREADリクエストを受け付け、そのオフセットがリモートの容量に達するとEOFを返します。部分ファイルのバイトデータとリモートの先頭部分は比較せず、切断されたセッション間で固定されたスナップショットを確保する交渉も行いません。名前や容量が同じだけでは内容が変わっていない証拠にはなりません。

手順：OpenSSHで変更されていないダウンロードを再開する

1. 中断したファイルを現在のローカルパスに残してください。どのワークスペース、リモートフォルダー、ファイル名から作成されたかを確認します。別のファイルの名前を変えて部分ファイルの代わりにしないでください。
2. メールアドレスとAPIキーの認証情報、信頼できるSSHホスト鍵を使って再接続します。

sftp -P 2222 -o User=you@example.com -o PreferredAuthentications=password -o PubkeyAuthentication=no sftp.dosya.dev

3. プロンプトで同じリモートのワークスペースとフォルダーに入ります。ls -lの情報を元の転送と比較してください。転送元が小さくなった、バージョンが変わった、または別のファイルである場合は、新しくダウンロードする必要があります。別のメンバーや連携が置き換えた可能性がある場合は、代わりにgetを使って新しいローカルパスに保存してください。
4. 変更されていない転送元と、その正しい部分ファイルについて、次を実行します。

sftp> cd "My Workspace"
sftp> reget source.bin ./source.partial.bin

両方のファイル名を実際のパスに置き換えてください。OpenSSHのsftpマニュアルにはregetがダウンロードの再開として記載されており、既存の内容が変わっていると結果が破損する可能性があると警告されています。インストール済みクライアントのマニュアルで、このコマンドに対応しているか確認してください。アップロードを再開するreputで代用しないでください。 5. 完了後、最終バイト数と完全なSHA-256を、信頼できる元ファイルまたは別途ダウンロードした比較用ファイルと比較してください。再開したダウンロードは、先頭部分が一致しなくても期待した容量に達する場合があります。

macOSではshasum -a 256 source.partial.bin source.reference.binを実行して両方のハッシュを表示し、2つのハッシュ値を自分で比較してください。このコマンドは等しいか自動で確認しません。Windows PowerShellでは各ローカルコピーにGet-FileHash -Algorithm SHA256を使い、表示されたハッシュ値を比較してください。SHA-256値が一致すれば完全なバイトデータの一致を確認できます。ファイル名の比較では確認できません。

期待される結果

再開したダウンロードのバイト数全体とSHA-256が元ファイルと一致します。やり直したアップロードは最終クローズが成功すると完全なクラウドファイルとして表示され、以前のサーバー側の部分データには依存しません。

無害なダウンロード再開テスト

元のバイトデータがすでにローカルにある使い捨てのリモートサンプルを、新しい名前で使用してください。同時に編集しないでください。機密ファイルや取り替えのきかないファイルは避けます。resume-check.partial.binにダウンロードし、いくらかのバイトを受信した後にクライアントを中断して、そのローカルの部分ファイルを残してください。同じ転送元に再接続し、regetでまったく同じ部分ファイルのパスに転送します。

リモートまたは転送元の容量、最終的なローカル容量、SHA-256を元ファイルと比較してください。クライアントが部分ファイルを削除した場合や中断前に完了した場合は、再開する部分ファイルがありません。十分に大きい無害なサンプルでのみやり直してください。このテストで確認できるのはそのクライアントのダウンロード処理であり、本番環境でアップロードを再開できる根拠にはなりません。このガイドの作成時に実際のプロトコルテストは行っていません。

中断したアップロードを復旧する

ゲートウェイは接続ごとに書き込みチャンクを収集し、閉じるでdosyaへのアップロードの確定処理を開始します。確定前のバッファー済みチャンクは永続的なリモートの部分ファイルとして公開されません。そのため、CLOSE前に接続が切れると再開できる保存済みの先頭部分はありません。CLOSE中またはその後に接続が切れた場合、バックエンドの操作がすでに確定している可能性があります。アップロードが失敗したと判断する前に、ファイル、容量、ダウンロードしたバイトデータを確認してください。

新しい書き込みOPENは、ファイル名がすでに存在していても空のチャンクから開始します。この実装では追記、切り詰め、排他的作成のフラグは以前のバイトデータの保持や名前の衝突防止を保証しません。小さなアップロードでは送信されなかった隙間が組み立て時に0で埋められる場合があり、大きなマルチパートの組み立てでは連続していない隙間は拒否されます。そのため、オフセット部分だけを再開するアップロードは失敗するか、既存ファイルを破損した内容に置き換える可能性があります。再開、Append、reput、put -a、クライアントの自動アップロード再開モードは使用しないでください。

復旧するには完全なローカルの元ファイルを保持してください。新しい移動先ファイル名を選び、再接続して、オフセット0からファイル全体を送る通常のputを使用します。クローズの結果を待ってから、完了したクラウドコピーを別のローカルパスにダウンロードして全バイトまたはハッシュを比較してください。既存の移動先の整理や意図的な置換は検証後にのみ行ってください。

同じクラウドファイル名がすでにある場合、通常の全体アップロードはdosyaの置換とバージョン管理の処理を使用します。以前のバージョンには保持制限があります。標準の保持数は10件で、無料プランのオーナーの古いバージョンは7日後の削除対象です。上書きしても無期限のバックアップは保証されません。クライアントのrmやrmdirは、許可されている場合、クラウドコンテンツをゴミ箱に移動し、関連する共有リンクを無効化します。再開を容易にするために正常とわかっているリモートの元ファイルを削除しないでください。完全に消去すると保存データは元に戻せません。

制限、時間、エラー

提供されているSFTPゲートウェイのアップロード上限は352 MiBですが、利用可能なストレージ、ワークスペースの容量やファイル形式のポリシー、明示的なキーやロールの制限はさらに厳しい場合があります。残りの部分だけをアップロードしても上限は回避できません。書き込まれた最大オフセットが容量の確認に使われます。通常のダウンロードはオフセット読み取りを使用し、64 MiB以上ではファイル全体を一度に読む代わりに範囲を限定して取得します。オフセット再開はローカルクライアントへの再転送量を減らせますが、新規または更新されたダウンロード許可はそれぞれ転送元ファイル全体の容量で計上されます。ダウンロードを開き直すと新しい許可が要求され、有効期限切れの範囲ダウンロードURLの更新でも別の許可が要求されることがあります。そのため、再開しても残りの部分だけが下り転送枠に計上されるとは限りません。

クラウドストレージへの転送は最終クローズ時に開始されるため、その段階で一時停止することがあります。これはResumeを待つ永続的なSFTP部分ファイルではありません。成功または明示的な失敗を待ってから移動先を確認してください。完了までの時間は保証されません。

エラーまたは疑わしい結果	対処
no such file / no such file or directory	リモートのワークスペースとパスを再確認し、転送元が移動または削除されたか調べてください。
handle is not open for reading または unknown or already-closed file handle	新しいダウンロードハンドルで再接続してください。切断されたハンドルは再利用できません。
write past the … MB per-file limit	適切な別のアップロード方法でファイル全体を送信してください。オフセットで再試行を繰り返しても上限は上がりません。
upload finished with … bytes of non-contiguous data still parked	オフセット0からアップロードをやり直してください。クライアントが欠落した範囲を残しました。
close failed: API …	APIのステータスやポリシーの詳細とファイル画面を確認してください。進行率は確定の受領確認ではありません。
容量は正しいがハッシュが異なる	問題のコピーを保持し、確認済みの転送元から新しいパスに完全なダウンロードをやり直してください。

対応するSFTPサインインまたはロールのキャッシュには、キーやロールの判定が最大60秒間残る場合があります。API認可には別のキャッシュがあるため、この期間は失効完了までの上限を保証しません。無効化が反映された後に変更したアクセス範囲を確認してください。アップロードのクローズ時には権限が再確認されます。送信されたバイトを受け付けた後でも、移動先へのアクセスが失効していると最終確定が拒否される場合があります。再開前にアクセスや回数制限の問題を解決し、フォルダーアンカーやIP許可制限のない専用SFTPキーを使用してください。

関連ガイド

• SFTP接続、信頼、認証情報
• ファイルのバージョンと復旧