[Dirvish] expiry rules

Jon Radel 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 Radel
jon at radel.com

More information about the Dirvish mailing list