Brian Martin wrote: >> I saw the "dirvish-expire --time time_expression" command, but that >> doesn't >> accelerate the expiry of existing backups, either. > > Some of my back-up strategies involve keeping some back-ups for 6-months or > a year. Since I don't really know if my retention periods match my back-up > capacity for at least one complete cycle of the longest retention period, I > can have a lot of back-ups piled up by the time I find out I need to make > some changes to the retention period policies. > > As an alternative to the current approach of determining the retention > period for a back-up at the time of the back-up, how about having > dirvish-expire recalculate the expiration dates each time it runs based on > its current rules? That way, if I find I've set my retention periods too > high (say 365 days), and decide I want to back down to something shorter > (say 280 days), I can just adjust the rule set and the next run of > dirvish-expire will dispose of everything that is now too old.
There's a general and a particular problem with this approach. The general problem is that it's difficult to make changes to dirvish components. Backup systems need to be very reliable, so we need to be very conservative. The dirvish codebase is somewhat complex. Most important, there's no test suite. In the absence of a test suite, most people who use dirvish extensively are unwilling to run the risk of breaking something. And people who use it extensively are those most likely to devote the time necessary to make changes! So creating tests is probably the most important contribution that can be made at the moment. The particular problem is that if you implement this proposal and then make a slight mistake editing your configuration, you could lose valuable backups! The way it works at the moment, all that happens is that newly created backups have bad expiration dates and you can fix them before any damage is done. > A variation would be leave dirvish-expire as-is by default, but to add an > option to recalculate expiration dates according to the current rules. That > would be fine with me, too. Thoughts? This is better but it suffers from the same problems. I'd suggest making a separate script that just recalculates all the expiry dates. Then the next time dirvish-expire runs it will delete all the unwanted backups. But before it runs, you have time to check that the new script has done what you expected. The new script could be based on code from dirvish-expire or written from scratch. Over time as the new code is proven and as tests are developed, the functionality could be moved into dirvish if it seemed a good idea. Perhaps somebody already has a script that does something like this? Cheers, Dave _______________________________________________ Dirvish mailing list [email protected] http://www.dirvish.org/mailman/listinfo/dirvish
