Backup Central

Hello,

I am always reluctant to use --remove-older-than in scripts because
there is always the possibility that the clock is screwed up for
whatever reason and it decides to remove all reverse diffs. Often I
would find it very useful to be able to say "keep the N newest
snapshots and remove the rest", which is safer.

In addition, it tends to give a pretty natural balance between
frequently changing backup targets and targets that seldom changes. If
a target changes relatively seldom (e.g., /etc) one might be more
inclined to want to keep 30 snapshots instead of 30 days (the latter
of which might translate into just the latest mirror).

Thoughts?

--
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller < at > infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey < at > scode.org
E-Mail: peter.schuller < at > infidyne.com Web: http://www.scode.org

On Wed, 18 Jan 2006, Peter Schuller wrote:

I am always reluctant to use --remove-older-than in scripts because
there is always the possibility that the clock is screwed up for
whatever reason and it decides to remove all reverse diffs. Often I
would find it very useful to be able to say "keep the N newest
snapshots and remove the rest", which is safer.

this is also useful when a few nightly cron jobs fail... because then
expiring by date means you'll end up with less than N increments...

-dean

On Wed, 18 Jan 2006, Peter Schuller wrote:
Often I would find it very useful to be able to say "keep the N newest
snapshots and remove the rest", which is safer.

Peter,
This feature already exists in rdiff-backup. From the 'Time Formats'
section of the man page:

6. A backup session specification which is a non-negative integer
followed by 'B'. For
instance, '0B' specifies the time of the current mirror, and '3B'
specifies the time of
the 3rd newest increment.


--
sim

Hello,

Peter,
This feature already exists in rdiff-backup. From the 'Time Formats'
section of the man page:

6. A backup session specification which is a non-negative integer
followed by 'B'. For
instance, '0B' specifies the time of the current mirror, and '3B'
specifies the time of
the 3rd newest increment.

Wow! Don't know how I missed that. My apologies - and thanks for the
pointer!

--
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller < at > infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey < at > scode.org
E-Mail: peter.schuller < at > infidyne.com Web: http://www.scode.org

Peter Schuller wrote:
Hello,

I am always reluctant to use --remove-older-than in scripts because
there is always the possibility that the clock is screwed up for
whatever reason and it decides to remove all reverse diffs. Often I
would find it very useful to be able to say "keep the N newest
snapshots and remove the rest", which is safer.

In addition, it tends to give a pretty natural balance between
frequently changing backup targets and targets that seldom changes. If
a target changes relatively seldom (e.g., /etc) one might be more
inclined to want to keep 30 snapshots instead of 30 days (the latter
of which might translate into just the latest mirror).

Thoughts?

I would find this extremely useful myself -- though it can be simulated
by getting a list of increments, backtracking through it to find the
30th (should it exist), and then calling remove-older-than with that
date. Much easier to have a remove-more-than option, though, I agree.

Do you think it would make sense to define behaviour for when both
remove-more-than and remove-older-than are used? It otherwise would be
ambiguous as to whether such indicates one wishes to remove anything
that matches *both* criteria, or anything that matches *either*
criteria. Personally, I think the former is more useful -- removing
anything that matches *either* could be done with two separate runs,
whereas removing anything that matches *both* couldn't.

On Wed, 18 Jan 2006, sim wrote:

On Wed, 18 Jan 2006, Peter Schuller wrote:
Often I would find it very useful to be able to say "keep the N newest
snapshots and remove the rest", which is safer.

Peter,
This feature already exists in rdiff-backup. From the 'Time Formats'
section of the man page:

6. A backup session specification which is a non-negative integer
followed by 'B'. For
instance, '0B' specifies the time of the current mirror, and '3B'
specifies the time of
the 3rd newest increment.

i just found and fixed an off-by-1 traceback in this... i had a directory
with 40 increments, and specifying 41B produced a traceback... but 40B and
42B were fine. committed the fix to 1.0.x and 1.1.x cvs.

-dean

I would find this extremely useful myself -- though it can be simulated
by getting a list of increments, backtracking through it to find the
30th (should it exist), and then calling remove-older-than with that
date. Much easier to have a remove-more-than option, though, I agree.

As has been pointed out (see previous post), this behavior turned out
to exist.

Do you think it would make sense to define behaviour for when both
remove-more-than and remove-older-than are used? It otherwise would be
ambiguous as to whether such indicates one wishes to remove anything
that matches *both* criteria, or anything that matches *either*
criteria. Personally, I think the former is more useful -- removing
anything that matches *either* could be done with two separate runs,
whereas removing anything that matches *both* couldn't.

I fully agree, and that is something that (unless I have missed
something *again*) is not currently supported. It is a particularly
useful criteria, because it will allow one to have a guaranteed
minimum retention period while still allowing for additional history
in cases where there is not much activity (or the reverse, if there is
a lot of activity and rdiff-backup is for some reason run very often).

--
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller < at > infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey < at > scode.org
E-Mail: peter.schuller < at > infidyne.com Web: http://www.scode.org

Charles Duffy <cduffy < at > spamcop.net>
wrote the following on Thu, 19 Jan 2006 09:05:57 -0600

Do you think it would make sense to define behaviour for when both
remove-more-than and remove-older-than are used? It otherwise would be
ambiguous as to whether such indicates one wishes to remove anything
that matches *both* criteria, or anything that matches *either*
criteria. Personally, I think the former is more useful -- removing
anything that matches *either* could be done with two separate runs,
whereas removing anything that matches *both* couldn't.

It's a good idea, and has been proposed before. The syntax was going to
be --retain-at-least <time>, where only increments matching both time
specifications would be deleted. I even have vague memories of writing
a bit of code about this, and was surprised to find no mention of
--retain-at-least in CVS.


--
Ben Escoto