[Dirvish] Expire removes most recent backup?

[Jon Radel]

Steve Ramage wrote:
> Paul Slootman wrote:
>>
>> If I do "rm -rf / tmp/bla" as root, that would be a disaster too.
>> However, I wouldn't want to see the rm command modified to stop me from
>> doing so.
>>   
> This isn't the correct analogy, as f will basically force it to go
> through and not prompt. You are overriding the default behavior in rm.
> Not sure what distro you run, but Ubuntu/Debian will make you type in
> something less "YES I KNOW WHAT I'M DOING" when trying to do something
> like remove the kernel package, or other harmful activity.

Well, no, not really.  The default behavior of rm as root is to pretty
much blow everything away.  Some Linux distributions alias the real "rm"
to "rm -i" for root so as to coddle those prone to blow away their
kernels when they didn't really mean to do so.  Ubuntu goes further and
tries to hide away any root shells entirely.

> But in this case there are two failures. One you deleted the file, and
> two dirvish deleted the image it contains.

The only failure involving dirvish is operator error to consider that
dirvish-expire will expire backups as configured and as clearly documented.

If you stop running backups as you planned, or something goes horribly
wrong elsewhere, stop running dirvish-expire until you've recovered what
needs recovering.

> In the case of the most recent image, the harddrive crashed, and you
> have to wait a week to get a new one.

Hard drive crash:

Step 1)  Secure most recent backup(s) very, very carefully.

Step 2)  Order hard drive

Expecting dirvish to rescue people who let dirvish-expire keep running
while they wait for replacement hardware is just too rich for words.

Now, that all said, if you want to patch dirvish-expire to optionally
never expire the most-recently-made good backup, instead of only never
expiring the last-to-expire good backup, I'm sure that said patch will
greeted with joy widely enough to make it worth your while to write and
test such a patch.

Grumpily yours,
Jon Radel
jon at radel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2890 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.dirvish.org/pipermail/dirvish/attachments/20080105/919ffa9a/attachment-0001.bin