Brandysnap -- a new rsync-based snapshot management script

[Chris Dennis]

Brandysnap is an rsync-based script with a difference.

Unlike dirvish, it does not assign importance to snapshots when they are
created. All snapshots are created equal, and then they are managed so
that the required number of old snapshots is maintained.

Unlike rsnapshot, brandysnap does not get its snapshots out of sync if
runs are missed, and it is very easy to configure.

The link between brandysnap and cron is very simple: just make sure
brandysnap is run often enough to create the first level of snapshots.
There is no need for separate runs to rotate the snapshot names at the
required intervals.

Defining which snapshots to keep is simple and intuitive. For example

     4d7,7w3,4m11,3y

means 'keep 4 snapshots a day for the last 7 days, 7 a week for the 3
weeks before that, then 4 a month for 11 months, then 3 a year forever'.
This example is referred to in the explanations below. Such
specifications can be as simple or as complex as you like.

Brandysnap is flexible. It can be ultra-cautious, refusing to delete old
snapshots unless there are enough to completely fill the requested
schedule. Or it can be more relaxed, and apply the rules more simply.
The periods 'day', 'week', 'month', etc. can be aligned on real calendar
periods, or they can be considered as simple spans of time working
backwards from 'now'.

Brandysnap is effectively stateless: it does not keep any sort of list
or database of information about previous runs. It uses the existing
snapshots as the basis for deciding what needs to be done. The snapshots
it creates are simple directories, which can be accessed without any
special tools.

Brandysnap is a Perl script designed to run on Linux. If there is
demand, I hope to make it work on other operating systems too.

It uses rsync (http://rsync.samba.org/) to do all the hard work,
including the network and authentication stuff.

Most of the cleverness in brandysnap is in deciding which snapshots to
keep. As time passes, existing snapshots move into the realm of later
specs, which require fewer snapshots to be kept. For example, after a
week of keeping 4 snapshots a day, only 7 snapshots out of the existing
28 may still be required. Brandysnap chooses 7 that are spread out
across the week to give the most useful set for future recovery.

But, and this is the important bit, if runs have been missed for any
reason, brandysnap will skip over incomplete periods. For example, if
the destination is an external USB drive and someone forgot to plug it
in, there will be snapshots missing. Brandysnap does not assume that a
'4d7' spec has been completed after 7 days: it only does so when it has
found 7 days each with at least 4 snapshots. Only then does it start
looking for weeks with at least 7 snapshots.

If you don't intend to create snapshots at weekends, specify something like

     4d5,7w3,4m11,3y

and brandysnap will automatically skip over the weekend days.

There are options to fine-tune the way brandysnap behaves.

The output includes an analysis of the existing snapshots and the way
snapshots have been chosen to be kept or deleted.

At present (3 July 2011), brandysnap is still being developed and should 
be considered 'experimental'.  Do not use it for anything important (yet).

Brandysnap can be downloaded from GitHub at

     https://github.com/StarsoftAnalysis/brandysnap

where you can follow its development and read more details.

Hopefully it will prove useful.  I look forward to hearing comments and 
ideas.

cheers

Chris
-- 
Chris Dennis                                    cgdennis at btinternet.com
Fordingbridge, Hampshire, UK