系统：全新更新的 ubuntu Xenial Xerus 16.04.2。从只安装了 openssh 的干净的最小系统开始。为了安装 backuppc 3.3.2，我执行了以下操作：
apt-get install backuppc rsync libfile-rsyncp-perl par2 smbfs
Apt 完成了其余的工作，安装了 apache2 和 perl 等依赖项。如果您认为这可能很重要，我将编辑问题并粘贴 apt 日志中的相关行。
之后，我完成了备份第一台主机所需的所有配置，几天后我回到测试实验室检查它的运行情况。我不得不说，backuppc 是一款漂亮的软件，它的表现完全符合我的预期——甚至比我预期的还要好！
我只是注意到在主屏幕上没有显示池的图表；故障排除仅从 apache 日志中返回了一条信息：
ERROR: opening '/var/lib/backuppc/log/pool.rrd': Permission denied
绝对是权限问题： /var/lib/backuppc 归 backuppc:backuppc 所有，而 apache 在 www-data 帐户下运行。
谷歌搜索错误返回了这样的修复：
Resource | Actual perms | Solution's perms
/var/lib/backuppc | 2750 | 2751
/var/lib/backuppc/log | 750 | 751
/var/lib/backuppc/log/pool.rrd | 640 | 754
这些权限更改修复了问题，现在显示图表。无论如何，我仍然担心权限更改后暴露服务的安全性。在这种情况下，我计划在安全和隔离的环境中实施，但如果客户要求公开服务，或者更糟糕的是，如果他自己公开服务怎么办？如果生产环境中出现问题，我不想在他们将去恢复的地方留下潜在的安全漏洞。
另一种解决方案可能是将 backuppc 的用户添加到 www-data 组，但从安全角度来看，这可能会更糟。
另一种解决方案可能是修补由 backuppc 运行的代码以处理此类问题（可能还有 sudoers 文件中的某些行），但我没有编程技能，除了 bash 脚本之外我什么也看不懂。
所以我的问题是： 为了实现图形显示，哪一个是最安全的解决方案？
如果该文件是唯一让您头疼的文件，您不妨将日志文件夹移动到 www-data 用户可以读取它并且 backuppc 用户可以写入它的位置。然后符号链接它。
它胜过将 /var/lib/backuppc/ 完全开放给系统上的每个用户，特别是如果该文件夹下的子目录和文件依赖于仅限于 backuppc:backuppc 的主文件夹的安全性。
关于将 backuppc 添加到 www-data 组，不会让 www-data 访问 backuppc 拥有的文件。你的意思是相反的吗？在任何情况下，我都同意这是一个坏主意，除非所有敏感数据都只能由 backuppc 用户而不是组读取。
为什么您遵循的指南建议将 /var/lib/backuppc/log/pool.rrd 从 640 -> 754（可由所有者和组执行）而不是 640 -> 644 更改为我。
注意：我使用 BackupPC 已经有几年了，所以我不太记得 /var/lib/backuppc 文件夹中的权限，或者日志目录包含的其他潜在敏感信息。
希望这可以帮助！
使用 .htaccess 限制图形访问。您只能允许使用 .htaccess 访问您的客户端。