Feature suggestion: Ability to keep a certain number of snapshots

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature suggestion: Ability to keep a certain number of snapshots

Peter Schuller
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 <[hidden email]>'
Key retrieval: Send an E-Mail to [hidden email]
E-Mail: [hidden email] Web: http://www.scode.org



_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Feature suggestion: Ability to keep a certain number of snapshots

dean gaudet-4
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


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Feature suggestion: Ability to keep a certain number of snapshots

sim-6
> 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


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Feature suggestion: Ability to keep a certain number of snapshots

Peter Schuller
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 <[hidden email]>'
Key retrieval: Send an E-Mail to [hidden email]
E-Mail: [hidden email] Web: http://www.scode.org



_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Feature suggestion: Ability to keep a certain number of snapshots

Charles Duffy-6
In reply to this post by Peter Schuller
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.


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Feature suggestion: Ability to keep a certain number of snapshots

dean gaudet-4
In reply to this post by sim-6
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


_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Feature suggestion: Ability to keep a certain number of snapshots

Peter Schuller
In reply to this post by Charles Duffy-6
> 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 <[hidden email]>'
Key retrieval: Send an E-Mail to [hidden email]
E-Mail: [hidden email] Web: http://www.scode.org




_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
Reply | Threaded
Open this post in threaded view
|

Re: Feature suggestion: Ability to keep a certain number of snapshots

Ben Escoto
In reply to this post by Charles Duffy-6
>>>>> Charles Duffy <[hidden email]>
>>>>> 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

_______________________________________________
rdiff-backup-users mailing list at [hidden email]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki

attachment0 (196 bytes) Download Attachment