2017-08-01 3 views
0

私は二枚舌を使ってUbuntuの16.04からアマゾンS3へのバックアップに大規模なファイルシステム(〜800ギガバイト)をしようとしています。それはファイルシステムのほとんどをバックアップしたように見えますが、終わりに向かって立ち往生し続けます。アマゾンS3へのUbuntu 16.04二枚舌のバックアップは「ピアで[errnoが104]接続のリセット」で失敗

私は今、このコマンドを複数回実行しているし、それが同じ場所(バックアップに約8時間)で中止/失敗し続けて:私は、最新のPPAに二枚舌をアップグレードしようとした私の最初の試みの後

$ duplicity --no-encryption --s3-use-ia --archive-dir /var/abc/tmp --tempdir /var/abc/tmp --exclude /var/abc/tmp /var/abc s3://s3-us-west-2.amazonaws.com/mybucket 

Local and Remote metadata are synchronized, no sync needed. 
Warning, found incomplete backup sets, probably left from aborted session 
Last full backup left a partial set, restarting. 
Last full backup date: Tue Jul 25 11:13:45 2017 
RESTART: Volumes 32085 to 32085 failed to upload before termination. 
     Restarting backup at volume 32085. 
Restarting after volume 32084, file backups/resourcespace.20170730.sql.gz, block 399 
Attempt 1 failed. error: [Errno 104] Connection reset by peer 
Attempt 2 failed. error: [Errno 104] Connection reset by peer 
Attempt 3 failed. error: [Errno 104] Connection reset by peer 
Attempt 4 failed. error: [Errno 104] Connection reset by peer 
Giving up after 5 attempts. error: [Errno 104] Connection reset by peer 

今は0.7.13.1を実行しています。もう一度やり直してください - 同じ失敗です。

次の私は(PIP経由)2.38.0から2.48.0へのbotoをアップグレードしても同じ失敗を見ています。

私はいくつか古いポストを見出しましたが、これはAmazon側で何らかの5GBの制限があるために起こったことを示唆していましたが、これらの投稿はDuplicityの0.7シリーズで修正されるはずです)。

さらなるトラブルシューティングを進める方法についてのご意見は、ありがとうございます。

答えて

0

ここにフォローアップしたいと思っています。正確な答えは少し不明ですが、私は最終的にこれを実現することができました。

はもともと私が中断された/部分バックアップを持っていた、私は二枚舌をアップグレードし、その後のbo​​to、その後、私はそれが完了するまでに得ることができるかどうかを確認するために中止されたバックアップを再開しようとしました。

その上諦めた後、私は次のようでした:

  1. をすべて更新されたコードをやり直すために元のバックアップを削除しました。
  2. 記録するボリュームの数を減らすために、--volsize 1024 to Duplicityを追加しました。
  3. --s3-use-multiprocessingを追加すると、処理が高速になりました。

これらの手順の1つ以上がErrno 104の問題を解決しました。これでバックアップが完了しました。私は新しいバックアップを実行したときに一時的なdirsで物事が異なって見えたので、おそらく古いコードから古いバックアップを再開することが問題を引き起こしていたことは非常に疑わしいです。しかし、それはvolsize(それは20MBから1024MBになった)に関連したものだったかもしれません。

私の署名ファイルは7.7ギガバイトで、まだかなり大きいではありませんが、もはや問題を引き起こしています。

クリーンバックアップですべてが正常に動作しているようです。

0

私は同じ正確な問題を抱えていました。 AWSアクセス&の秘密鍵が間違っていたことが判明しました。それらを更新することで問題は解決されました。

あなたのケースではないかもしれませんが、影響を受ける他の人に役立つ可能性があります。

+0

ありがとう@yajo。私の場合、S3バケット(AWS Web UIで確認済み)に約700GB相当のデータを記録していたので、確かにOKと認証されました。私の最善*推測*は、最後にダイジェストなどをアップロードしようとしていたことです。 – DanJ

関連する問題