I glanced at the source code, and it appears pretty trivial (a change to
options.c and a change to backup.c) to implement a user-selected backup
script. All it appears to involve is adding an option to the command
line and an extra if statement in backup.c....
I might give it a shot in my ample spare time... It would make rsync a
lot more useful to me anyway.... A welcome change from the 5 hour
public meeting I just had to chair - and I have cpu cycles to spare.
--Yan
Martin Schwenke wrote:
>
> >>>>> "yan" == yan seiner <[EMAIL PROTECTED]> writes:
>
> yan> I've been trying to come up with a scripting solution for
> yan> this for some time, and I'm convinced there isn't one.
>
> yan> You definitely want to handle the revisions in the same way
> yan> as logrotate: keep a certain depth, delete the oldest, and
> yan> renumber all the older ones.
>
> Another option that I've implemented is based on amount of free disk
> space rather than number of incremental backups. I keep all of the
> (date/time based) incrementals on their own filesystem. Before
> starting a new backup I check whether the disk usage on the filesystem
> is above a certain threshold and, if it is, I delete the oldest
> incremental. Repeat until disk usage on the incremental filesystem is
> below the threshold and then do the new backup.
>
> In this way I don't have to guess the number of incremental backups
> that I can afford to keep... it is based purely on free disk space.
> Naturally, if there's an unusual amount of activity on a particular
> day then this system can also be screwed over... :-)
>
> Someone else noted that it is more useful to keep a certain number of
> revisions of files, rather than a certain number of days worth of
> backups. It would be relatively easy to implement this sort of scheme
> on top of date/time-based incrementals. Use "find" on each
> incremental directory (starting at the oldest) and either keep a map
> (using TDB?) of filenames and information about the various copies
> around the place or use locate to find how many copies there are of
> each file... or a combination of the 2: the map would say how many
> copies there are, but not where they are; if you're over the threshold
> then use locate to find and remove the oldest ones...
>
> It isn't cheap, but what else does your system have to do on a Sunday
> morning? :-)
>
> I might implement something like that...
>
> peace & happiness,
> martin
