Principles of operation

There are two available "cycle types" that govern the timing and order of overwriting old backups: a "Simple" cycle that keeps backups at fixed intervals, and a "Hanoi" cycle that keeps backups on a decaying schedule. Only the Simple cycle allows incremental backups.

SimpleCycle

The cycling of backup sets here is rudimentary, taking its inspiration from the  cron job approach given on the js3tream page. The principle is that we'll sort the snapshots into a fixed number of "slots"; every new backup simply overwrites the oldest slot, so we don't need to explicitly purge old files.

This is a fairly crappy schedule, in that the rotation doesn't decay over time. We just keep a certain number of daily backups (full or diff), and that's it.

Note also that the present scheme means that, once the oldest full backup is deleted, the diffs based on it will still be stored until they are overwritten, but may not be all that useful. For instance, if you do daily diffs and weekly fulls for two weeks, then at some point you'll go from this situation, where you can reconstruct your data for any day from the last two weeks (F = full, D = diff, time flowing to the right):

FDDDDDDFDDDDDD

to this one:

 DDDDDDFDDDDDDF

where the full backup on which the six oldest diffs are based is gone, so in fact you can only fully reconstruct the last 8 days. You can still retrieve files that changed on the days represented by the old diffs, of course.

HanoiCycle

The decaying properties of the Hanoi schedule are excellently described  elsewhere. Briefly: full backups are made every day, but are overwritten in an order that results in ages distributed as powers of two, e.g. 1, 2, 4, 8, and 16 days old (etc.).

Next: Configuration Options