【发布时间】：2012-03-31 00:11:57
【问题描述】：
我一直在使用 rsync snapshot script from Mike Rubel 的修改版本，并且在调整它以执行我想要的操作时遇到了一些问题。他只拍每小时一次的快照；我希望通过 crontab 每小时、每天、每周和每月都有快照。
这是我的每小时脚本：
if [ -d $BUP/temp ] ; then
rm -rf $BUP/temp ;
fi;
rsync -avzO --delete --exclude-from=$CONFIG/rsync-excludes /home/jwhendy/ $DAT/jwhendy/ ;
rsync -avzO --delete --exclude=vault* --link-dest=../vault.hourly.0 $DAT/ $BUP/temp ;
if [ -d $BUP/vault.hourly.2 ] ; then
rm -rf $BUP/vault.hourly.2 ;
fi;
if [ -d $BUP/vault.hourly.1 ] ; then
mv $BUP/vault.hourly.1 $BUP/vault.hourly.2 ;
fi;
if [ -d $BUP/vault.hourly.0 ] ; then
mv $BUP/vault.hourly.0 $BUP/vault.hourly.1 ;
fi;
mv $BUP/temp $BUP/vault.hourly.0 ;
这是每日脚本（每周/每月几乎相同）：
if [ -d $BUP/vault.daily.2 ] ; then
rm -rf $BUP/vault.daily.2 ;
fi;
if [ -d $BUP/vault.daily.1 ] ; then
mv $BUP/vault.daily.1 $BUP/vault.daily.2 ;
fi;
if [ -d $BUP/vault.daily.0 ] ; then
mv $BUP/vault.daily.0 $BUP/vault.daily.1 ;
fi;
if [ -d $BUP/vault.hourly.2 ] ; then
cp -al $BUP/vault.hourly.2 $BUP/vault.daily.0 ;
fi;
每小时脚本效果很好。我正在苦苦挣扎的是从每小时 -> 每天（以及每天 -> 每周等）的过渡。
目前，脚本会这样运行，比如说，如果每小时脚本一天运行 6 次，然后每天运行脚本（“hourly.n”缩写为“hr.n”，“b_m”代表单个快照）：
| hour 1 | hour 2 | hour 3 | hour 4 | hour 5 | end of day |
|------------+------------+------------+------------+------------+---------------|
| hr.0 (b_0) | hr.0 (b_1) | hr.0 (b_2) | hr.0 (b_3) | hr.0 (b_4) | hr.0 (b_5) |
| | hr.1 (b_0) | hr.1 (b_1) | hr.1 (b_2) | hr.1 (b_3) | hr.1 (b_4) |
| | | hr.2 (b_0) | hr.2 (b_1) | hr.2 (b_2) | hr.2 (b_3) |
| | | | | | daily.0 (b_3) |
由于 hourly.sh 会破坏 hourly.2（如果存在），我们可以看到 daily.0 是第一次使用 b_3 创建的，而我丢失了 b_0、b_1 和 b_2。在删除它之前，我更愿意每小时将 hourly.2 增量转储到 daily.0 中。这样，在任何给定时间，我都会拥有 hourly.0、1 和 2，而 daily.0 将包含在删除之前的最新版本的 hourly.2。
希望这是有道理的。
我尝试将cp -al $BUP/hourly.2 $BUP/daily.0 ; 行放入每小时脚本中。我遇到了三个问题：
- 它似乎比单独的 rsync 脚本花费的时间要长得多，即使它技术上只是复制一些硬链接
- 因为这些是硬链接，在我的情况下，第一个备份将是完整大小（~20GB）；随后的运行应该生成更新文件大小的快照（它确实如此）。我希望最大的快照会在树中逐渐移动得越来越远（最终在每月.2 处）。这条
cp -al行似乎在daily.0 上保持稳定，并且永远不会回到daily.1 等等（这可能是对du工作方式的误解。 - 我不知道如何不破坏备份链，这会迫使必须重新创建一个新快照（完整的 20GB）。换句话说，hourly.2 不断转储到 daily.0... 但最终
mv $BUP/daily.0 $BUP/daily.1将使 daily.0 不再存在。因此，下次运行 hourly.sh 时，必须从头开始重新创建它。
无论如何，希望我要完成的工作很清楚。我需要帮助将每个脚本（每小时、每天、每周）转换到下一个“桶”（每天、每周、每月），而无需中断硬链接链。
我还希望在此过程中不要丢失重要的快照，如上表所示。
非常感谢您的任何建议。
【问题讨论】：
-
第二个问题：你的意思是，最大的快照向后移动？据我所知，您的第一次备份和以下所有备份都应该是“等效的”。硬链接文件不关心哪个链接首先存在。使用 du 检查大小时，第一次备份和增量备份的大小是否不同？ （假设您在备份之间没有太大变化......）
-
@JanRüegg：
du我得到了不同的结果。我通常做du -sh /media/bup/vault.*。其中一个总是显示约 20GB，并且（假设脚本没有被中断）其余的在 10 到 100 兆字节之间，具体取决于发生了什么变化。我有时会在 20GB 范围内看到不止一个，所以我认为硬链接链被破坏了......也许我只是不明白du是如何测量大小的？它会不会“重复计数”，还是应该在整个文件夹上使用 du，而不是让它遍历所有快照？ -
@Hendy：通常没有硬链接“链”之类的东西，但所有文件都只是链接到硬盘上的相同数据。这也意味着，其中一个上的“du”应该给出完整尺寸，但对所有这些都做“du”不会重复计算。 （至少对我来说是这样，经过快速测试......你有特殊的文件系统或类似的东西吗？）
-
@JanRüegg：没有特殊的文件系统，这就是我的行为方式......这就是为什么我认为我从 hourly.2 -> daily.0 的过渡过程中出现了一些问题......因为似乎是两组非常大的快照。我会再试一次并验证，因为我一直在修改脚本。我可以按照上面的建议尝试 rsnapshot，尽管它看起来有点过头了。