Bash 协助rsync每小时/每天/每周备份快照脚本

我一直在使用的修改版本，并一直有一些问题，调整它做什么，我想。他只拍每小时一次的快照；我希望通过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 ;

以下是每日脚本（每周/每月脚本基本相同）：

每小时一次的脚本效果很好。我正在挣扎的是从每小时->每天（和每天->每周，等等）的过渡

目前，脚本的功能是这样的，比如说，如果每小时脚本在一天内运行6次，然后每天脚本运行（“hourly.n”缩写为“hr.n”，“b_m”代表单个快照）：

因为hourly.sh会将hourly.2转换为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.2$BUP/daily.0行并将其放入脚本中。我在这方面遇到了三个问题：


它似乎比rsync脚本要花更长的时间，尽管从技术上讲它只是复制一些硬链接
因为这些都是硬链接，所以在我的例子中，第一个备份将是完整大小（~20GB）；后续运行应生成更新文件大小的快照（确实如此）。我希望最大的快照在树中逐渐向后移动（最终是每月一次）。这条
cp-al
线似乎将其稳定地保持在每日.0，并且它永远不会回到每日.1，以此类推（这可能是对
du
工作原理的误解）
我不知道如何不中断备份链，这会强制创建一个新的快照（完整的20GB）必须重新创建。换句话说，hourly.2不断转储到daily.0…但最终
mv$BUP/daily.0$BUP/daily.1
将使daily.0不再存在。因此，下次hourry.sh运行时，必须从头开始重新创建它

在任何情况下，我都希望能清楚地知道我想要完成什么。我希望能得到帮助，在不破坏硬链接链的情况下，将每个脚本（每小时、每天、每周）转换到下一个“bucket”（每天、每周、每月）

如上表所示，我还希望不会丢失重要的快照

非常感谢您的建议。
好的，我对硬链接做了一个测试，下面是我的感受：

➜  rsync -az0 /home/jan/tmp/Source /home/jan/tmp/Dir1
➜  rsync -az0 /home/jan/tmp/Source /home/jan/tmp/Dir2 --link-dest=/home/jan/tmp/Dir1
➜  du -hs /home/jan/tmp/Source
124M    /home/jan/tmp/Source
➜  du -hs /home/jan/tmp/Dir1
124M    /home/jan/tmp/Dir1
➜  du -hs /home/jan/tmp/Dir2
124M    /home/jan/tmp/Dir2

您可以看到，所有指向文件的硬链接实际上都是等效的。这意味着，就其本身而言，每个备份都是“完整”备份，如果您仅对该备份执行“du”，则可以获得完整的文件大小

➜  du -hs /home/jan/tmp/Dir1 /home/jan/tmp/Dir2
124M    /home/jan/tmp/Dir1
0   /home/jan/tmp/Dir2

但是，如果对所有硬链接都执行“du”（如上面的第6个命令），它将识别硬链接，并为以前遇到的所有硬链接显示“零”大小。但是，这只取决于参数的顺序，而不取决于哪个硬链接是“第一”：

针对您的实际问题：

与其做一个
cp-al$BUP/hourly.2$BUP/daily.0
，然后删除hourly.2，你不能只做一个
mv$BUP/hourly.2$BUP/daily.0
，什么会快得多呢？
对于你的第二个问题：你是什么意思，最大的快照会向后移动？据我所知，你的第一次备份和下面的所有备份都应该是“等效”。硬链接文件不关心先存在哪个链接。在使用du检查大小时，第一次备份和增量备份的大小是否不同？（假设备份之间没有太大变化…）@JanRüegg:du的
du
结果不同。我通常会
du-sh/media/bup/vault.*
。其中一个总是显示20GB左右（假设脚本没有中断）其余的是10到100兆字节，这取决于发生了什么变化。我有时会在20GB的范围内看到不止一个，因此我认为硬链接链被破坏了……也许我只是不明白
du
是如何测量大小的？它会“重复计数”吗或者我应该在总文件夹上使用du，而不是让它遍历所有快照？@Hendy：通常没有硬链接“链”，但所有文件都只链接到硬盘上的相同数据。这也意味着，单个文件上的“du”应该给出完整的大小，但执行“du”在所有这些文件上都不会重复计算（至少对我来说是这样，经过一个快速测试…你有一个特殊的文件系统或类似的东西吗？）@JanRüegg：没有特殊的文件系统，这就是我的行为……这就是为什么我认为从hourly.2->daily.0过渡到hourly.2的过程中有些不对劲的原因……因为似乎有两组非常大的快照。我将重试并验证，因为我已经对脚本进行了一些修改。我可以按照上面的建议尝试rsnapshot，尽管它看起来很简单ke overkill。感谢您对
du
的解释。这非常有帮助。是的，
mv
会更快，事后来看，我用
cp-al
命令做了我打算做的事情（我在选择
cp
而不是
mv
时考虑不正确）。我仍然没有解决每日运行时每小时快照丢失x个数的问题，但也许我需要做更多的每小时快照来弥补这一问题。再次感谢您的帮助。也许我的问题主要是基于对硬链接和
du
的误解。太好了！很高兴我能提供帮助。在这种情况下，您可以标记为接受答案就解决了问题？对不起。我读到它的时候其实是想解决的，但时间不到三分钟，所以我不得不等待……然后完全忘记了：）
➜  rsync -az0 /home/jan/tmp/Source /home/jan/tmp/Dir1
➜  rsync -az0 /home/jan/tmp/Source /home/jan/tmp/Dir2 --link-dest=/home/jan/tmp/Dir1
➜  du -hs /home/jan/tmp/Source
124M    /home/jan/tmp/Source
➜  du -hs /home/jan/tmp/Dir1
124M    /home/jan/tmp/Dir1
➜  du -hs /home/jan/tmp/Dir2
124M    /home/jan/tmp/Dir2

➜  du -hs /home/jan/tmp/Dir1 /home/jan/tmp/Dir2
124M    /home/jan/tmp/Dir1
0   /home/jan/tmp/Dir2

➜  du -hs /home/jan/tmp/Dir2 /home/jan/tmp/Dir1
124M    /home/jan/tmp/Dir2
0   /home/jan/tmp/Dir1