On 3/23/2011 2:35 PM, Eric Searcy wrote:
On Mar 17, 2011, at 3:37 AM, Dave Howorth wrote:
Of course that begs the whole question of how to test it ... ?
Who needs to test? ;-)
On the "it should be fairly simple" point I believe the last line in default.hist is
always the most recent non-branched successful backup (failures don't get logged). This should
automatically allow one to handle things like --image "blahname" backups that don't go
into the sort order nicely, and also avoid needing to parse summary.gz logs.
Speaking of branches, maybe you should never delete the last successful backup
from any branch? (each last line from *.hist)
As far as I know, dirvish-expire does not use the hist files, nor do I
think it really should. It appears to load the summary file which
contains everything that is stored in the .hist file, but is located
with the image. I occasionally modify the Expire tag on already run
backups to extend their lifetime. Mostly I just delete the Expire
header and I'd hate to see an image get deleted because I forgot to
update the corresponding .hist entry. The only potential benefit I see
to the .hist file is that is contains the history of images already
expired, though I'm not really sure what value that is.
I do think a simple fix need to be made to dirvish-expire to not remove
the most recent image made when all images have expired. Recently I
brought an old backup drive into the rotation again, it had been sitting
idle for more than a year and all images were expired. For each vault,
it first complained that it could not remove the oldest image due to
there being no unexpired images, then proceeded to delete all more
recent images. This meant a lot of wasted time in in syncing up the
backups as this put it almost two full years old in backups for the
reference point. I am looking at making a patch for this particular
case, but I do see merit in adding logic so that the most recent image
is not deleted by default. In most cases it won't be a problem since
the backups will be run more often then the shortest expiry period, but,
especially in the case where nothing is unexpired, deleting the newest
backup is usually not the best option.
Eric
_______________________________________________
Dirvish mailing list
[email protected]
http://www.dirvish.org/mailman/listinfo/dirvish
--
Loren M. Lang
[email protected]
http://www.alzatex.com/
Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B
_______________________________________________
Dirvish mailing list
[email protected]
http://www.dirvish.org/mailman/listinfo/dirvish
