[Dirvish] expiry rules
jon at radel.com
Wed Mar 16 14:56:04 UTC 2011
On 3/16/11 6:21 AM, Dave Howorth wrote:
> Third, I think you're misunderstanding the implications of how
> dirvish/rsync works. Because it uses hard links, you really only have
> one backup copy anyway. So any warm fuzzy feeling you get from "having
> more than one copy" is illusory. If you want more than one physical
> copy, you need multiple dirvish vaults for each backup or some other
> method of making physical copies. So what you'd like dirvish to do
> strikes me as pointless.
I was nodding my head in agreement to your message until the very end of
this. This has come up before on the mailing list. If I understand the
OP correctly, his primary desire is that dirvish apply a higher level
understanding of the "value" of a given backup and expire based on this,
rather than "mindless" application of the expiry date assigned at backup
The classic example I remember from some years ago was the person who
was terribly bent out of shape that after his disk failed dirvish
continued to delete images until he was left with a single image. It
had been successful, but it was very far from being the latest image at
the time of failure.
Dirvish doesn't deal with this situation very well in the opinion of
many. There is no reason I can think of that a tool couldn't be written
to manipulate the expiry dates to meet the requirements of local policy.
I've not heard of any such, but it doesn't mean they're not out there.
Personally, when I have something blow up, one of my actions on my
checklist is to add a decade to the expiry time on the most promising
image in every dirvish vault that backs up what are now smoking ruins.
jon at radel.com
More information about the Dirvish