首先,我认识到这些不是 duply 和 duplicity 的最新版本。客户端在各种操作系统版本上运行服务器,我们目前从系统存储库安装 duply 和 duplicity。我搜索过,没有发现任何迹象表明这个问题在较新版本中已修复。如果有人能告诉我这是个问题,我们会更新系统以安装这些软件包的更新版本。但在投入精力之前,我更愿意确切地知道。
我们使用 duplicity 备份文件,由 duply 管理,并通过 cron 运行。在完整备份运行时,我们托管设施的维护活动使接收服务器脱机。后来,当尝试从该备份恢复以准备替换该服务器时,我发现备份已损坏,维护期间有几个 0 字节文件。我没有收到来自 cron 的有关错误的电子邮件,并且记录的输出显示虽然 rsync 报告了错误,但 duplicity 没有识别出错误(“错误 0”):
Start duply v1.11, time is 2022-12-30 02:00:01.
Using profile '/etc/duply/sites'.
Using installed duplicity version 0.7.06, python 2.7.12, gpg 1.4.20 (Home: ~/.gnupg), awk '
GNU Awk 4.1.3, API: 1.1 (GNU MPFR 3.1.4, GNU MP 6.1.0)', grep 'grep (GNU grep) 2.25', bash
'4.3.48(1)-release (x86_64-pc-linux-gnu)'.
Checking TEMP_DIR '/tmp' is a folder and writable (OK)
Test - En/Decryption skipped. (Testing disabled)
--- Start running command PRE at 02:00:02.363 ---
Skipping n/a script '/etc/duply/sites/pre'.
--- Finished state OK at 02:00:02.415 - Runtime 00:00:00.051 ---
--- Start running command BKP at 02:00:02.433 ---
Attempt 1 failed. BackendException: Error running 'rsync -e 'ssh -oBatchMode=yes' /tmp/duplicity-upULdT-tempdir/mktemp-i_a13g-605 USER@SERVER:PATH/sites/duplicity-full.20221230T070002Z.vol604.difftar.gpg': returned 255, with output:
packet_write_wait: Connection to 12.34.567.890 port 22: Broken pipe
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.1]
--------------[ Backup Statistics ]--------------
StartTime 1672383612.11 (Fri Dec 30 02:00:12 2022)
EndTime 1672388712.14 (Fri Dec 30 03:25:12 2022)
ElapsedTime 5100.03 (1 hour 25 minutes)
SourceFiles 21623
SourceFileSize 18523309075 (17.3 GB)
NewFiles 21623
NewFileSize 18523309075 (17.3 GB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 21623
RawDeltaSize 18514613173 (17.2 GB)
TotalDestinationSizeChange 17904721458 (16.7 GB)
Errors 0
-------------------------------------------------
--- Finished state OK at 03:25:32.689 - Runtime 01:25:30.256 ---
--- Start running command POST at 03:25:32.700 ---
Skipping n/a script '/etc/duply/sites/post'.
--- Finished state OK at 03:25:32.715 - Runtime 00:00:00.014 ---
损坏的文件:
-rw------- 1 backup adm 26268756 Dec 30 03:08 duplicity-full.20221230T070002Z.vol597.difftar.gpg
-rw------- 1 backup adm 0 Dec 30 03:08 duplicity-full.20221230T070002Z.vol598.difftar.gpg
-rw------- 1 backup adm 0 Dec 30 03:08 duplicity-full.20221230T070002Z.vol599.difftar.gpg
-rw------- 1 backup adm 0 Dec 30 03:08 duplicity-full.20221230T070002Z.vol600.difftar.gpg
-rw------- 1 backup adm 0 Dec 30 03:08 duplicity-full.20221230T070002Z.vol601.difftar.gpg
-rw------- 1 backup adm 0 Dec 30 03:08 duplicity-full.20221230T070002Z.vol602.difftar.gpg
-rw------- 1 backup adm 0 Dec 30 03:08 duplicity-full.20221230T070002Z.vol603.difftar.gpg
-rw------- 1 backup adm 26281466 Dec 30 03:22 duplicity-full.20221230T070002Z.vol604.difftar.gpg
将来可以做些什么来防止这种情况发生?我不介意备份因服务器问题而失败。我确实想知道它失败了,这样我就可以处理它。我查看了 duply、duplicity 和 rsync 页面,没有看到任何其他可指定的会影响此情况的选项。
答案1
这些版本总体来说比较老旧,不再维护。请升级到最新的 duply 2.4.2/duplicity 1.2.1,并检查是否仍能重现错误。如果能,请提交错误单https://gitlab.com/duplicity/duplicity/-/issues。
由于您的版本比较旧,因此很可能像这样明显的错误已经被修复了。
如果升级版本带来的挑战太大,您可能需要考虑使用 sftp:// 或其他后端,如果 rsync 在您的情况下不可靠。
此外,您可以考虑定期验证您的备份,这样将来就不会再出现类似的意外。