Backup Central

Hi,

Does rdiff-backup plan to support backup rotation? Perhaps
grandfather-father-son or even towers of hanoi backup rotation?

The reason I ask is that my current backup scripts (home grown
python) use a g-f-s scheme, and recently I had to take advantage of
this to restore from last April's monthly backup. Before moving
across to rdiff-backup permanently I'd like to get an equivalent to
this feature.

The way I'd see it working is to define n subdirectories within the
nominated backup directory (each a logical tape, if you will). From
this, rdiff-backup would determine which subdirectory directory to
backup to, based on the nominated backup schedule. In addition, it
could create a symlink so that the current backup could be maintained
to keep the "current snapshot" nature of rdiff-backup.

I don't know if this has been thought about, comments appreciated.

Alastair Rankine wrote:
Does rdiff-backup plan to support backup rotation? Perhaps
grandfather-father-son or even towers of hanoi backup rotation?

rdiff-backup already allows you to restore from any arbitrary date in
the past, and to purge all backups before a given date.

GFS and Towers of Hannoi are _techniques_ to achieve a result rather
than an end in themselves. What is it you actually want to be able to do
that you do not believe rdiff-backup provides today? I suspect we can
help you do it with rdiff-backup as it stands.

Regards,
Keith

From my perspective, the ideal approach to keeping older backups at a
lower density than new ones would be writing code to be able to merge
reverse-diffs, such that two historical diffs could be replaced with
only one containing the changes from both -- and excluding the
intermediate changes from an item which changed multiple times between
the merged set.

Anything else requires storing extra or redundant information beyond
what is currently done now.

On 20/10/2005, at 12:19 AM, Charles Duffy wrote:

From my perspective, the ideal approach to keeping older backups at
a lower density than new ones would be writing code to be able to
merge reverse-diffs, such that two historical diffs could be
replaced with only one containing the changes from both -- and
excluding the intermediate changes from an item which changed
multiple times between the merged set.

Anything else requires storing extra or redundant information
beyond what is currently done now.

This would also suit my needs. In fact it is better than my idea.

My proposal would have resulted in many full backups (with no diffs)
for the older data, but may have been easier to implement.

Either way is good!