This thread might be getting a wee bit hot.  Some folks have been
hurt by dirvish-expire, and are trying to fix it.  Good for them. 
As Paul tried to explain with his rm example, dirvish-expire is a
dangerous power tool, and people should be really really careful
before using it.  Good for Paul.  We don't need to get caught up in
the behavior of rm, or what people "ought" to know.  If people were
perfect, they would make perfect programs, perfect hard drives, and
never make missteaks (sic), and we would not need backups at all.

If dirvish-expire is configured and used correctly, it does not 
erase your most recent backup. dirvish-expire can be modified so
it does not erase the most recent backup even with some kinds of
misconfiguration, but there may be unknown side effects from that. 
If people rely on that added behavior, and it behaves unexpectedly
or disappears in a future release, we are back to square one, with
a now-more-complicated tool to fix.

The best solution would be a good, newbie-friendly explanation of
the current dirvish-expire behavior.  Emphasis on friendly.   Some
folks are new to the idea of backups, and may have stumbled on
dirvish as their first backup tool.  Good for them, but we need to
explain it better so they make the right choices and don't get hurt. 

We also need to explain why it is important to preserve many images,
not just the most recent.  For example, if your client has been
r00ted, you probably don't want to restore from the most recent
image.  While dirvish-expire helps reduce backup drive cost by
reducing image storage space, there are many risks associated
with that, including slower backup servers and increased disk wear. 
Previous experience with backup systems that use up N times the
space for N images doesn't apply here, and the tendency for dirvish
newbies will be to delete too many recent images because they expect
large space savings from that.  That newbie misunderstanding should
be fixed first.

If I used dirvish-expire, I would write the explanation myself.  If
someone else wants to write it, but doesn't trust their English
skills, I would be glad to help them edit it.  The wiki would be a
good place to start.

Keith

-- 
Keith Lofstrom          [EMAIL PROTECTED]         Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
_______________________________________________
Dirvish mailing list
[email protected]
http://www.dirvish.org/mailman/listinfo/dirvish

Reply via email to