☰

4 月 6 日更新

tag-icon • tag-icon 20.04 duplicity
4 月 6 日更新

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

 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 压缩的文本）...我在想也许文件或文件系统在那个“块 298”上可能已损坏。

退出代码 '50' 代表什么？
BrokenPipeError 是来自写入后端的管道……还是……？
对此有什么看法？

4 月 6 日更新

后端“目标”是一个s3+http://URL。这是一个正在运行生产服务的 Linode 系统；网络连接良好（或者我预计会有其他问题、监控警报等）。

正如答案中所建议的那样，我尝试强制清理。 Duplicity 尽职尽责地做到了。然后我开始了另一次备份……输出略有不同，但管道仍然损坏……

 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 时，我如何知道它在做什么？

答案1

经验表明这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

似乎缺少了上一次备份的卷，这使得 Duplicity 无法完成存档过程。您可能可以通过使用终端中的选项cleanup来解决此问题：--force

duplicity cleanup --force /path/to/target

答案2

绕回来结束这个循环……答案是……

更新 Boto 从“boto”为“boto3”。

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

事实证明，我的备份目标使用的是架构“s3+http://”（简称“s3://”），并选择了使用“boto”[版本 1] 的后端。所有这些都已弃用；boto v1 及其使用的 Amazon S3 API。

python3-boto3我通过适用于我的 Ubuntu 20.04/Focal 系统的软件包安装了 boto3（显然 boto2 失败了？） …

然后将我的后端目标更改为方法“boto3 + s3：//”，并且它可以完美运行，无需对我的配置进行任何其他更改。

相关内容