There isn't one?
rsync has the --backup-dir= option.
keep each set of backups to a different directory, then merge them back into the main
heirarchy if needed. Since they're already sifted out, it'd be easy to archive them,
as well.
if it's a daily, --backup-dir=$(( $(date +%j) % 28 )) will keep 4 weeks worth, then go
back over the old ones.
Of course, you'd probably want to get that integer seperately, and use it to delete
the one you're about to write into, to keep it clean.
The point is, somebody already anticipated your need, and made it easy to script it.
Tim Conway
[EMAIL PROTECTED]
303.682.4917
Philips Semiconductor - Colorado TC
1880 Industrial Circle
Suite D
Longmont, CO 80501
[EMAIL PROTECTED]@[EMAIL PROTECTED] on 03/22/2001 03:17:35 AM
Sent by: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]@SMTP
cc:
Subject: Re: unlimited backup revisions?
Classification:
I've been trying to come up with a scripting solution for this for some time, and
I'm convinced there isn't one.
You definitely want to handle the revisions in the same way as logrotate: keep a
certain depth, delete the oldest, and renumber all the older ones.
If you want to get real ambitius, you could even include an option for compressing
the backups to save space.
My biggest concern is a disk failure on the primay during sync (unlikely, but I
had my main raid fail during sync, and it wiped out both my mirrors.) A managed
backup strategy is the only thing that saved my bacon.....
Some tools for managing the backups (listing them - what's the revision history on
this file type of query, donig a mass recover, etc) would be useful.
Just some random thoughts,
--Yan
"Sean J. Schluntz" wrote:
> >> That's what I figured. Well, I need it for a project so I guess you all
> >> won't mind if I code it and submit a patch ;)
> >>
> >> How does --revisions=XXX sound. --revisions=0 would be unlimited, any other
> >> number would be the limiter for the number of revisions.
> >
> >And when it reaches that number, do you want it to delete old
> >revisions, or stop making new revisions?
>
> You would delete the old one as you continue rolling down.
>
> >Perhaps something like --backup=numeric would be a better name. In
> >the long term it might be better to handle this with scripting.
>
> I don't see a good scripting solution to this. The closest I could come up
> with was using the --backup-dir and then remerging the tree after the copy
> and that is a real cluge. The scripting solution I see would be to clean
> up if you had the backup copys set to unlimited so you don't run out of
> disk space.
>
> -Sean
