问题标签 [duplicity]

执行时：duplicity --force remove-older-than 10D file:///fullSystemBackup/

产生以下错误：Specified archive directory '/home/bitnami/.cache/duplicity/abcxyz' does not exist, or is not a directory

我正在尝试使用基于重复性的重复备份。我的问题是我的远程目标（通过 WebDAV 的“GMX 媒体中心”）似乎将一个目录中的文件数量限制为 3000 个（没有记录 - 只有我的经验）。当达到此限制时，备份总是停止，因为WebDAV response status 507 with reason 'Insufficient Storage'.

我看到以下选项：

• 将源分成几个部分。然后我仍然要冒险达到目标目录中 3000 个文件的限制。
• 增加卷大小 ( --volsize)，但这也只会延迟问题。

我还有其他好的选择吗？

我正在对备份 Web 项目使用重复性。通过重复性处理三个不同的地方：存储、数据库和系统设置。

我实际上想停止备份存储并留下另外两个。

所以问题是我如何知道哪些缓存文件与存储备份相关，并且删除它们（或整个重复缓存文件夹）是否安全，因为它占用了太多空间

升级版：

我已将缓存移动到新位置并更改配置中缓存的路径，之后进行了几次测试运行以使一切正常。然后我删除了一个不需要的文件夹，其余所有备份仍然有效。所以移动/删除缓存文件夹绝对安全

我正在测试 duplicity 的恢复功能：

这会产生以下错误：

这个错误是什么意思？

我正在尝试使用重复包装脚本（duplicity-restore.sh）恢复文件，内容如下：

我很难恢复存储在名称中带有空格的目录中的文件。我尝试了以下方法：

没有引号或转义斜杠：

以上导致错误“在存档中找不到 dir1/dir2/dir - 未恢复文件。”

引用整个路径参数：

以上导致错误“预期 2 个参数，得到 15 个”

仅引用名称中带有空格的目录：

以上导致错误“预期 2 个参数，得到 15 个”

目录名称中每个空格旁边的转义斜杠：

以上导致错误“预期 2 个参数，得到 15 个”

看来，无论我如何尝试转义目录名称中的空格，Duplicity 都将每个空格视为一个单独的参数。我要恢复的文件有几个目录，所有目录的名称中都包含空格。

Duplicity 版本是 0.7.17，在 CentOS 7 上运行并备份到 Amazon S3 存储桶。

我想使用 duplicity 0.7.06（通过aptUbuntu 16.04.5 LTS 安装）将本地目录备份到远程服务器。~/.ssh/authorized_keys在远程服务器上设置了一个带有文件的用户帐户。

duplicity命令行如下：

重复性的调试输出为：

稍等片刻，又出现一行：

我可以通过 SSH 手动连接到远程服务器，而无需使用以下命令指定密码：

我也可以在scp不指定密码的情况下复制文件：

所以这似乎是重复或 paramiko 的问题。

根据“关于 SSH 后端的说明”手册部分，我在 duplicity 命令行中尝试了各种 SSH 后端：

帕拉米科+SCP

导致上述问题。

帕拉米科+sftp

导致上述问题。

pexpect+scp

pexpect+sftp

lftp+scp：

这在安装后有效lftp，但是，它需要密码身份验证，并且授权密钥无法按预期工作。

尝试使用duplicityFTPS（基于 SSL 的 FTP）服务器备份 Ubuntu 18.04.1 服务器。密码按照建议存储在FTP_PASSWORD环境变量中。双重性命令是：

问题是，当它转身并调用时，这会转化为以下内容lftp

在您将 open 命令更改为（不带ftps://主机名前缀：

我无法弄清楚的是：

• 如何告诉不要使用前缀duplicity构建open命令。ftps://
• 如何lftp使用前缀

lftp注意：FTPS 服务器可以与其他 FTP 客户端一起正常工作，只要我正确构建命令，它甚至可以正常工作open。

几年来，我已经成功地将我的本地文件备份到一个 mega.co.nz 使用 duplicity 的云驱动器帐户。

几周前，我创建了第二个 MEGA 帐户，并希望将更多数据备份到该帐户上。但是在这里，登录总是失败并返回 RequestError -8（详细的错误日志：见下文）。尽管我使用的 duplicity 命令是相同的（除了登录名），而且据我所知，帐户配置也是相同的。

我注意到的唯一区别：我的旧帐户有 50 GB 配额，新帐户只有 15 GB。

重复性 MEGA 后端是否可能适用于较旧的 MEGA 帐户，但不适用于较新的 MEGA 帐户？这是我目前唯一的解释，因为完全相同的重复性测试命令适用于旧命令，但如果我在新命令上尝试相同的命令，我会重现地得到 RequestError -8！

我确定我使用了正确的密码。我通过使用我的网络浏览器登录帐户来验证它。此外，如果凭据错误，它会抛出 RequestError -9，而不是 -8，我也使用旧帐户进行了测试。

有人可以帮帮我吗？是否是 duplicity 后端的错误，仅对较新的 MEGA 帐户有效？还是我做错了什么！？

以下是我用来测试两个帐户的命令（真实登录名替换为“nemax”）：首先是旧的/成功的：

这里是新的/不成功的：

我有一个运行良好的备份脚本。我最近更新了我的操作系统（到 Ubuntu 19.10）并尝试安装所有依赖项，但出现错误。

我的脚本是这样的：

我创建了.boto文件gsutil并且可以gsutil成功使用，因此身份验证似乎正在工作。

回溯看起来像一个编码/解码问题，但我不知道这是我做事方式的问题还是boto错误duplicity

我尝试按照此处的建议解码存储桶变量。

现在我得到一个SSLCertVerificationError，如下：

当我决定在备份中包含其他文件夹时，我遇到了一个错误，我想知道如何更正它。

我的完整duplicity命令是

如果我不包括--include参数，它运行良好，一旦它们被包括在内，我会收到一个FilePrefixError: /home/MINE/Shareable**.

是的，所有这些路径都存在。对我来说，似乎重复性期望包含的路径是相对于/home/MINE/webapps/webapp2而不是绝对路径。

我该如何纠正？

笔记

以一条新消息结束：