是什么导致这种重复的“重新启动”与“退出代码‘50’失败？”

Question

这是Duply输出的一部分，运行在20.04系统上。

 19 |Start duply v2.2, time is 2022-03-31 03:24:01.
 20 |Using profile '/etc/duply/system'.
 21 |Using installed duplicity version 0.8.12, python 3.8.10 (/usr/bin/python3), gpg 
     2.2.19 (Home: /root/.gnupg), awk 'GNU Awk 5.0.1, API: 2.0 (GNU MPFR 4.0.2, G
     NU MP 6.2.0)', grep 'grep (GNU grep) 3.4', bash '5.0.17(1)-relea
     se (x86_64-pc-linux-gnu)'.
 22 |Autoset found secret key of first GPG_KEY entry '6DC41962' for signing.
 23 |Checking TEMP_DIR '/tmp' is a folder and writable (OK)
 24 |Test - Encrypt to '6DC41962' & Sign with '6DC41962' (OK)
 25 |Test - Decrypt (OK)
 26 |Test - Compare (OK)
 27 |Cleanup - Delete '/tmp/duply.2031592.1648697042_*'(OK)
 29 |--- Start running command BKP at 03:24:02.958 ---
 30 |Reading globbing filelist /etc/duply/system/exclude
 31 |Synchronizing remote metadata to local cache...
 32 |Deleting local /root/.cache/duplicity/duply_system/duplicity-full-signatures.202
     20322T032402Z.sigtar.gpg (not authoritative at backend).
 33 |Last full backup left a partial set, restarting.
 34 |Last full backup date: Tue Mar 22 03:24:02 2022
 35 |Reuse configured PASSPHRASE as SIGN_PASSPHRASE
 36 |RESTART: Volumes 1060 to 1060 failed to upload before termination.
 37 |         Restarting backup at volume 1060.
 38 |Restarting after volume 1059, file var/lib/autopostgresqlbackup/weekly/REDACTE
     D/redacted_week.11.2022-03-19_06h25m.sql.gz, block 298
 39 |Attempt 1 failed. BrokenPipeError: Broken pipe
 40 |Attempt 2 failed. BrokenPipeError: Broken pipe
 41 |Attempt 3 failed. BrokenPipeError: Broken pipe
 42 |Attempt 4 failed. BrokenPipeError: Broken pipe
 43 |Giving up after 5 attempts. BrokenPipeError: Broken pipe
 44 |04:57:25.120 Task 'BKP' failed with exit code '50'.
 45 |--- Finished state FAILED 'code 50' at 04:57:25.120 - Runtime 01:33:22.1
     61 ---

这种情况已经连续几天发生了。

我看过那个.sql.gz文件，看上去不错。file命令说，这正是我所期望的(gzip‘expect )，…我在想，也许文件或文件系统在那个“块298”上被破坏了。

退出代码'50‘代表什么？

是写到后端BrokenPipeError的管道中的…或…？

对此有什么想法吗？

更新4月6日

后端“目标”是一个s3+http:// URL。这是一个运行生产服务的Linode系统；网络连接良好(或者我希望有其他问题，以及监视警报等等)。

正如答案中所建议的那样，我试图强制进行清理。这是伪善尽职尽责的。然后我又开始了另一个备份..。产量略有不同，但管道还是坏了.

 19 |Start duply v2.2, time is 2022-04-06 03:24:01.
 20 |Using profile '/etc/duply/system'.
 21 |Using installed duplicity version 0.8.12, python 3.8.10 (/usr/bin/python3), gpg 
     2.2.19 (Home: /root/.gnupg), awk 'GNU Awk 5.0.1, API: 2.0 (GNU MPFR 4.0.2, G
     NU MP 6.2.0)', grep 'grep (GNU grep) 3.4', bash '5.0.17(1)-relea
     se (x86_64-pc-linux-gnu)'.
 22 |Autoset found secret key of first GPG_KEY entry '6DC41962' for signing.
 23 |Checking TEMP_DIR '/tmp' is a folder and writable (OK)
 24 |Test - Encrypt to '6DC41962' & Sign with '6DC41962' (OK)
 25 |Test - Decrypt (OK)
 26 |Test - Compare (OK)
 27 |Cleanup - Delete '/tmp/duply.761614.1649215441_*'(OK)
 29 |--- Start running command BKP at 03:24:02.723 ---
 30 |Reading globbing filelist /etc/duply/system/exclude
 31 |Local and Remote metadata are synchronized, no sync needed.
 32 |Last full backup date: Sat Feb 19 03:24:03 2022
 33 |Last full backup is too old, forcing full backup
 34 |Reuse configured PASSPHRASE as SIGN_PASSPHRASE
 35 |Attempt 1 failed. BrokenPipeError: Broken pipe
 36 |Attempt 2 failed. BrokenPipeError: Broken pipe
 37 |Attempt 3 failed. BrokenPipeError: Broken pipe
 38 |Attempt 4 failed. BrokenPipeError: Broken pipe
 39 |Giving up after 5 attempts. BrokenPipeError: Broken pipe
 40 |16:21:20.829 Task 'BKP' failed with exit code '50'.
 41 |--- Finished state FAILED 'code 50' at 16:21:20.829 - Runtime 12:57:18.1
     06 ---

当它得到BrokenPipeError时，我如何知道它在做什么？

Answer 1

返回以关闭此循环…答案是。。。

将Boto从"boto“更新为"boto3".

我最终尝试建立一个完全不同的、与S3兼容的存储提供商。但是当我尝试使用这个新目标时，我得到了各种各样奇怪的错误--不是配置错误，而是看起来像坏了的API错误。

结果显示，我的备份目标是使用模式“boto http://”(简单地说是“s3://”的同义词)，并选择使用"boto“第1版的后端。所有这些都是不推荐的；boto v1和它使用的Amazon S3。

我安装了boto3 (显然boto2死在藤蔓上了？)通过我的Ubuntu20.04/焦点系统的python3-boto3包…

然后将我的后端目标更改为“boto3 3+s3:/”方法，它可以很好地工作，不需要对我的信任进行任何其他更改。

Answer 2

经验表明，BrokenPipeError可以意味着：

• 糟糕的网络连接
• 半睡眠目标USB设备
• 缺失数据

从您的日志来看，问题似乎来自于这里：

 36 |RESTART: Volumes 1060 to 1060 failed to upload before termination.
 37 |         Restarting backup at volume 1060.
 38 |Restarting after volume 1059, file var/lib/autopostgresqlbackup/weekly/REDACTE
     D/redacted_week.11.2022-03-19_06h25m.sql.gz, block 298

在以前的备份中似乎缺少了卷，因此不可能重复完成归档过程。您可以通过在终端中使用cleanup和--force选项来解决这个问题：

duplicity cleanup --force /path/to/target