☰

使用 rsync --delete 时丢失硬链接的权限

tag-icon • tag-icon backup permissions rsync
使用 rsync --delete 时丢失硬链接的权限

使用基于云的存储介质（Strato 的 HiDrive 产品），我采用了使用 的备份方案rsync。在工作时间，我的大多数本地服务器文件都会通过 cronjob 备份到云中。我的备份脚本大量利用 rsync 的功能，不复制未更改的文件，而是硬链接它们。这看起来像

rsync -av -M--perms  \
            $inp_sig $REMOTE_USER@$RSYNC_HOST:$REMOTE_BASIS/$CURRENT_SNAPSHOT \
            --exclude-from=$EXCLUDE_FILES \
            --link-dest=$link_destination/

其中所有显示的变量都已由脚本预先设置为正确的值。 所有这些都运行良好。

晚上，另一个脚本启动，清除不再使用的快照。对于删除任务，我使用另一个脚本，其核心rsync命令如下：

empty_dir=`mktemp -d`
rsync -d --delete-before --inplace --perms \
            $empty_dir/  $REMOTE_USER@$RSYNC_HOST:$REMOTE_BASIS/$snap/ || \
                    log_rsync ERROR: could not delete $snap
rm $empty_dir

这个也行得通 - 差不多。问题是所有链接文件的所有权限都因删除而被压缩rsync（它们最终都具有644其中一些应该具有的权限444）。

我已经解决这个问题好几天了，尝试了rsync各种删除选项的组合。我试过-rdvs.-r或-a; --deletevs. --delete-before，但都无济于事。从手册页中我了解到这个选项--inplace应该可以解决问题：

该选项改变了 rsync 在需要更新文件数据时传输文件的方式：rsync 不再采用默认的方法，即创建文件的新副本并在完成后将其移动到位，而是将更新的数据直接写入目标文件……硬链接不会中断。

这让我想到不是使用--inplace应该会导致硬链接中断。但在我们的例子中，硬链接无论如何都会中断（对于具有不同权限位的文件）。

它们还具有一个cifs非常适合少量文件操作的界面。但rm -rf在快照目录上执行删除操作绝对不可行 - 它在典型的备份快照上持续数小时，而且我每晚必须执行大约 16 到 20 次删除。rsync 变体运行大约两分钟。

那么，我是否因为对 的理解有限或隐含的限制而迷失了方向rsync？还是我只是因为rsync提供商方面的 实施不佳而运气不好？

答案1

问题没有完全解决，但是已经得到解决。

我在帖子中描述的问题是由于 的实施造成的rsync。我提交了一份错误报告到 Bugzilla 并得到明确的迹象表明，rsync在递归删除目录时确实没有正确处理权限位。

他们指出了使用该--super选项的解决方法：

empty_dir=`mktemp -d`
rsync -d --delete --super \
        $empty_dir/  $REMOTE_USER@$RSYNC_HOST:$REMOTE_BASIS/$snap/ || \
                log_rsync ERROR: could not delete $snap
rm $empty_dir

是的，该选项可能会有副作用--super。对于我的应用程序来说，该解决方法就足够了。

相关内容