Restic: 使用--include进行还原会在创建失败的目录时创建具有错误权限的目录。

创建于 2017-10-31  ·  5评论  ·  资料来源: restic/restic

restic version

Restic 0.7.3
在Linux / amd64上用go1.9编译

您是如何精确地休息的?

请参阅下面的详细信息

您使用了什么后端/服务器/服务?

客户:Debian稳定版(9.2)
服务器:使用OpenSSH的LAN中的FreeBSD 11.1服务器(OpenSSH_7.2p2,OpenSSL 1.0.2k-freebsd 2017年1月26日)

预期行为

即使仅还原层次结构中较深的文件,也应使用原始权限和所有权创建所有目录。

实际行为

还原位于层次结构深处的文件时,将使用与原始文件不同的用户和权限来还原下行目录。

重现行为的步骤

mkdir testdir#创建目录
touch testdir / testfile#在其中创建一个文件
chmod 755 testdir testdir / testfile#确保权限为755
su#切换到root
restic -r sftp:rakor @ SERVER :/ usr / home / rakor / resticbackuptest backup testdir#进行备份
restic -r sftp:rakor @ SERVER :/ usr / home / rakor / resticbackuptest restore最新-t testrestore -i testfile#恢复文件(不是整个目录)
ls -lR testrestore#使用正确的所有者和权限还原文件。 但是,使用用户“ root”和权限700还原到文件的目录。
testrestore /:
注射剂4
drwx ------ 2根根4096 Okt 31 21:30 testdir

testrestore / testdir:
仪表0
-rwxr-xr-x 1 rakor rakor 0 Okt 31 21:25测试文件

您是否知道可能是什么原因造成的?

我认为下降的目录不是“还原”的,而是“安全默认值”的“创建”。

您有解决该问题的想法吗?

恢复空目录,而不仅仅是创建它们。

restore bug

最有用的评论

对我来说,这肯定看起来像是恢复功能中的错误/问题。 如果我要将原本属于某个用户的数据还原到该用户可以访问的目录中,则我希望该用户能够访问已还原的数据,即使仅还原了一部分。 恢复目录属性(owner / access / etc)似乎是实现此目的的自然方法。

同样,当前的行为被认为是对这些中间目录的恢复(“还原”了它们的存在,但它们的属性没有恢复),这似乎是不一致/不合逻辑的。

所有5条评论

感谢您提出这个问题。 我不确定以正确的方式在中间目录上设置先前的访问权限,让我考虑一下。

关于此事还有其他想法吗?

对我来说,这肯定看起来像是恢复功能中的错误/问题。 如果我要将原本属于某个用户的数据还原到该用户可以访问的目录中,则我希望该用户能够访问已还原的数据,即使仅还原了一部分。 恢复目录属性(owner / access / etc)似乎是实现此目的的自然方法。

同样,当前的行为被认为是对这些中间目录的恢复(“还原”了它们的存在,但它们的属性没有恢复),这似乎是不一致/不合逻辑的。

我认为这是一个错误。 如果我想还原部分备份,则还原后的副本应该可用。 当前,如果不执行restic ls操作来发现自动创建的每个路径元素的正确权限,所有者和组,将无法使用。 这确实使文件/目录的恢复变得困难。

我同意应通过restic还原的内容应以一致的方式进行还原(即,使用运行还原的用户的“默认”权限,或使用已备份的原始文件和文件夹的权限等),两者的结合)。

但是,我可以在两种类型的权限中看到一个用例:

  • 一些用户需要/希望将数据还原到新的上下文中,并且他们希望所有权和权限为“默认”,就好像他们自己重新创建了相同的目录和文件一样。
  • 一些用户需要/希望将数据还原到与他们备份时相同或相等的上下文中,并希望结果与备份的原始文件具有相同的所有权和/或权限。
  • 有些用户只想保留权限,而不要保留所有权(尽管他们可以轻松地自己更正所有权)。

我认为前进的合理方法是,可以通过restore命令的某些选项来控制restic恢复哪些所有权和/或权限。

有人可以确认这还是个问题吗? 自0.7.3发布以来,我们对中间目录的权限(和时间戳)进行了一些更改...

此页面是否有帮助?
0 / 5 - 0 等级