I think this was discussed not that long ago, and I seem to remember
making a comment to the fact, but it's really, really disastrous to
one's snapshot volume when a host is unavailable.
This is because rather than simply rolling snapshot n-1 up to n (where n
== current, which makes n and n-1 identical of course) when a machine is
unavailable, snapshot "n" remains *empty* for that machine. Now when
the machine comes back online and rsnapshot goes to take it's next
backup, no hard links to snapshot n (or n-1 or n-2, etc.) are made and
snapshot n consumes as much new space as there is data on the newly
available machine!
Without having looked at the code for this particular use-case, this
seems to be a failing in the use of the --link-dest rsnapshot rather
than "cp -al; rsnapshot", because in the latter case, if the rsync
fails, at least the cp -al will have rolled up n-1 to n.
So, how to solve this problem for the --link-dest case?
Perhaps if rsync fails for some fatal reason (i.e. not "source file
bla-bla-bla changed while reading it", etc.) then perhaps an rsync
--link-dest between n-1 and n should be done to "fill out" whatever
failed during the original rsync. Any thoughts on this idea?
~sigh~ Now I have to go cleaning up my snapshot volume restoring the
hard link pool where (incorrectly) new files have been created. Silly,
silly, silly.
b.
|