我正在尝试定期拍摄大型文件夹的快照。
我在这里读过：http://www.mikerubel.org/computers/rsync_snapshots/#Incremental
只需复制硬链接即可cp -al拍摄文件夹的快照。
这一切都很好，但问题是在这个快照中，如果我更改一个文件，它会在所有快照中更改。我想要的是让系统在更改时创建一个新文件并链接到该文件。这样，每个快照都不会在编辑第一个文件时变得无效。
我怎样才能做到这一点？
ps我试过了rsync -a --delete --link-dest=../backup.1 source_directory/ backup.0/，但也有同样的问题。
答案1
这就是硬链接的工作原理。但是，有一些方法可以解决这个问题：
我想到了几个选项：
- 使用支持写时复制文件的文件系统，例如
btrfs.当然，如果您使用 btrfs，您只需使用其本机快照...如果您的文件系统支持它，您可以使用cp --reflink=always.不幸的是，ext4 不支持这一点。 - 仅在快照之间共享硬链接，而不是与原始快照共享硬链接。也就是说，第一次看到文件的给定版本时，将其复制到快照。但下次，将其链接到上一个快照中的链接。 （不知道十年前我用什么程序来执行此操作，但搜索结果是 dirvish、obnam、storebackup 和 rsnapshot）
- 根据文件的更改方式，您也许能够保证使用写入临时/重命名来更改它们，然后这将破坏硬链接，因此快照中的版本将保持原始状态。但这不太安全，因为错误可能会损坏您的快照。
- 拍摄整个文件系统的 LVM 快照。
当然，还有另一种选择——使用适当的备份系统。大多数人都可以设法仅备份已更改的文件。
答案2
您正在寻找的是一种形式写时复制，其中具有相同内容的多个文件使用磁盘上的相同空间，直到其中一个文件被修改。仅当执行写入操作的应用程序删除文件并使用相同名称创建新文件（通常通过使用不同名称创建新文件，然后将其移动到位来完成）时，硬链接才实现写时复制。您正在使用的应用程序显然没有执行此操作：它会覆盖现有文件。
某些应用程序可以配置为使用替换策略。有些应用程序默认使用替换策略，但当看到有多个硬链接的文件时使用覆盖策略，正是为了不破坏硬链接。如果您可以将应用程序配置为替换而不是覆盖，则当前的快照技术将起作用。
福尔牛修改程序以系统地对具有多个硬链接的文件使用替换策略。
或者，您可以将文件存储在执行写时复制或重复数据删除或具有快照功能的文件系统上，而不必担心硬链接：Btrfs或者兹夫斯。根据您的分区方案，使用 LVM 快照可能是一种选择。
我的建议是使用合适的快照工具。进行可靠的备份非常困难。你可能想要快照。
答案3
以下是我编写的 ruby 脚本，它将“cp -al”和 rsync 包装到一个可以手动或通过 cron 运行的漂亮脚本中。目标可以是本地或远程（通过 ssh）：
正如前面的评论中提到的，您问题的基本答案是，源需要与硬链接分开。例如，假设每天备份您的主目录：
来源：
- /home/flakrat
目的地：
- /数据/备份/每日
- /周一
- /周二
- /周三
- /周四
- ...
硬链接是通过对昨天的备份运行“cp -al”来创建的。假设运行时是星期二早上：
cd /data/backup/daily
rm -rf tuesday
cp -al monday tuesday
rsync -a --delete /home/flakrat /data/backup/daily/tuesday/
答案4
rdiff-backup 似乎可以满足您的要求，请检查一下。
使用 rsync 您必须首先进行完整备份，而不是使用硬链接。下一个备份可以指向上一个备份并硬链接到它。这样，您的备份就不会硬链接到您的工作文件（您正在修改的文件）。例子。如果我以前的备份是文件夹 backup.01，我的备份脚本将首先通过将文件夹重命名为 1 来增加文件夹，以便 backup.01 变为 backup.02。然后该脚本创建一个名为 backup.01 的新空文件夹。然后，它会将新备份同步到新文件夹中，并硬链接到 backup.02，以便只有新文件才会占用备份中的任何空间。 rsync 命令看起来像这样： rsync -rlt sourcepath backuppath/backup.01 --link-dest=backuppath/backup.02
所以你可以看到，所有的硬链接都发生在备份路径上。这样，在修改源路径中的文件时，您不必担心写入时复制。