Keith Lofstrom wrote: > 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. > Currently how does one configure dirvish to not erase your most current backup, I don't see a way, short of having it be your only backup, or never expiring any backups. Mind you, I'm no expert. > 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. > I don't believe that only the most recent should be the only preserved backup, but I fail to see the harm in having an option to set this. Different setups require different needs. I would personally also like to see dirvish-expire carry forward or backwards the expire time for failed backups, and trump smaller values. I.E. If every monday the backup is preserved for one year, and monday fails, then either Sunday is modified to have a one year backup (if it is less than a year) backup, or Tuesday is. > 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 > >
While I do agree that the misunderstanding should be fixed first, which I have learnt my lesson with, I don't see the harm in having an option in dirvish to make sure the most recent image is never expired. If my laptops harddrive dies in the middle of finals, I may not have the time or the foresight to stop dirvish-expire from killing my most recent data. To state another way, I don't see what benifiet expirying the most recent image gains anyone, in any scenerio, it's certainly not space. If the philosophy is to make power users out of every user, then dirvish should also respect expiry rules on the last image and kill it even though that will toast the last of the data. Steve R _______________________________________________ Dirvish mailing list [email protected] http://www.dirvish.org/mailman/listinfo/dirvish
