That's very helpful---thanks much! I imagine I'll go ahead
and just make dirvish-expire do the right thing here,
though; I can't see any reason one would ever want it to
expire the most recent backup.
Bart
In message <[EMAIL PROTECTED]> you wrote:
> On Thu, 2008-01-03 at 14:19 -0800, Barton C Massey wrote:
>
> > It looks like dirvish-expire has no qualms about removing
> > the most recent image in a vault. This seems to me to be a
> > bad idea.
>
> <snip>
>
> > Any chance someone could fix this so that dirvish-expire
> > will leave the most recent bits alone, at least as an
> > option?
> >
> > Bart Massey
>
> At the risk of getting flamed for cutting & pasting from my own
> post from last summer, does this help ? :
>
> On Sat, 2007-08-25 at 16:44 -0500, Tony wrote:
> > By design, dirvish-expire will not delete your most recent backup
> image
> > if it is the only image left in the vault, regardless of whether the
> > image is ready to expire or not.
> >
> > However, if there are older images in the vault (perhaps set to never
> > expire) and your most recent backup is past its expiry date then
> > dirvish-expire will delete it ! This can leave you without a recent
> > backup.
> >
> > Normally this might not happen but I have a system that I only backup
> > once a week - retaining the backups for a month. Recently I ran into
> an
> > issue where I was travelling and the system was turned off.
> Eventually,
> > dirvish-expire started deleting my recent backups and I was left with
> > only a really old image.
> >
> > I suppose it should be possible to modify dirvish-expire to not delete
> > the most current backup regardless of its expiry date. However, I
> took
> > another route, as I use Daniel Petcher's technique of having a post
> > execution script to maintain symbolic links to the two more recent
> > backups (search the wiki for details). I thus modified
> dirvish-expire
> > to look for those links and if found, to ignore the expiry dates for
> > those archives.
> >
> > Here's the diff file of what I did to dirvish-expire.pl :
> >
> > 161c161,180
> > < $$Options{quiet} or printf "%-15s %-15s %-16.16s %s\n",
> > ---
> > >
> > > ## 20070825 - don't allow backups tagged current or recent to be
> > expired
> > >
> > > $recent = readlink( substr($$expire{path},0,-8)."recent") ;
> > > $current = readlink( substr($$expire{path},0,-8)."current") ;
> > > if (($recent eq $$expire{path}."/tree") || ($current eq
> > $$expire{path}."/tree"))
> > > {
> > > $$Options{quiet} or printf "%-15s %-15s %-16.16s %s <-
> ignored
> > (recent or current)\n",
> > > $$expire{vault} . ':' . $$expire{branch},
> > > $$expire{image},
> > > $created,
> > > $expired;
> > >
> > > next;
> > > }
> > >
> > > ## 20070825 - don't allow backups tagged current or recent to be
> > expired
> > >
> > >
> > > $$Options{quiet} or printf "%-15s %-15s %-16.16s %s \n",
> >
> >
> > I realize this solves an obscure issue but it might help somebody.
> >
> > Note : the use of substr to truncate the vault address is a bit of a
> > hack (it assumes the backups are always stored in 8 digit yyyymmdd
> > subdirectories). I have a version that uses
> > $path =~ s/\/[A-Za-z0-9]+$/\/tree/ ;
> > to do the same thing more generically but the resulting code is
> actually
> > a little harder to read IMHO.
> >
> > Tony
> >
>
>
>
> _______________________________________________
> Dirvish mailing list
> [email protected]
> http://www.dirvish.org/mailman/listinfo/dirvish
_______________________________________________
Dirvish mailing list
[email protected]
http://www.dirvish.org/mailman/listinfo/dirvish
