[Nssbackup-team] [Fwd: Re: Logarithmic purge disabled]

2010-08-23 Thread Jean-Peer Lorenz
 Weitergeleitete Nachricht 
Von: Jean-Peer Lorenz peer@gmx.net
An: Anton Feenstra feens...@few.vu.nl
Betreff: Re: Logarithmic purge disabled
Datum: Mon, 23 Aug 2010 10:54:16 +0200

Good morning Anton,

Thank you for looking into SBackup and your bug tracking. Another
maintainer able to fix minor flaws would be great. Software maintenance
is really time consuming.

I'm sorry to tell you, that I've already fixed the purge issue. I'll
prepare an updated release within the next days. I've re-implemented it
similar to the simple purge: only freestanding snapshots are removed and
the removal process is repeated until no freestanding snapshot or at
least 1 snapshot remain (within a certain period).

The more I think about rebasing of snapshots, the more I dislike the
whole idea. It is always dangerous to modify backuped data, even more if
it stored in 'foreign' formats (here tar). Moreover, the current
implementation of writing TAR snapshot files (snar files) contains
errors and updating tarballs in only possible for uncompressed tars. So,
I consider to cut rebasing completely. But that's another story...

 I don't get why it becomes so expensive?
Because of the current implementation. Each path that is processed is
compared to every stored path in sequential manner.



Regards,
Jean-Peer



Am Montag, den 23.08.2010, 09:37 +0200 schrieb Anton Feenstra:
 Hi Jean-Peer,
 
 I'm considering what  how to implement. It seems the rebase operations, 
 although a nice idea, quickly become too costly.
 
 As an alternative, I'm considering changing the purge logic to purge 
 incremental snapshots only when their base (full) snapshot is scheduled 
 to purge as well. This is the easy part. More tricky is that we do not 
 want to purge a full (base) snapshot when any of its incremental (child) 
 snapshots should be retained (though I'm not sure when exactly this 
 condition could apply). I'm thinking now on how to implement this (will 
 come back on that).
 
 I think it would be best to add a config option for this, like:
 - purge incremental snapshots individually by re-basing (may be slow)
 *or*
 - purge incremental shapshots together with their base (full) snapshot
 
 As a sidenote, I think I understand the basic logic of the rebasing, 
 however I don't get why it becomes so expensive?
 




signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Mailing list: https://launchpad.net/~nssbackup-team
Post to : nssbackup-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~nssbackup-team
More help   : https://help.launchpad.net/ListHelp


Re: [Nssbackup-team] [Fwd: Re: Logarithmic purge disabled]

2010-08-23 Thread Anton Feenstra

On 23/08/10 10:55, Jean-Peer Lorenz wrote:

 Weitergeleitete Nachricht 
Von: Jean-Peer Lorenzpeer@gmx.net
An: Anton Feenstrafeens...@few.vu.nl
Betreff: Re: Logarithmic purge disabled
Datum: Mon, 23 Aug 2010 10:54:16 +0200

Good morning Anton,

Thank you for looking into SBackup and your bug tracking. Another
maintainer able to fix minor flaws would be great. Software maintenance
is really time consuming.


You're welcome!


I'm sorry to tell you, that I've already fixed the purge issue. I'll
prepare an updated release within the next days. I've re-implemented it
similar to the simple purge: only freestanding snapshots are removed and
the removal process is repeated until no freestanding snapshot or at
least 1 snapshot remain (within a certain period).


Great to have this fixed, as this was keeping me back from using nssbackup.

Basically, this is now again the old sbackup behaviour, is that right?


The more I think about rebasing of snapshots, the more I dislike the
whole idea. It is always dangerous to modify backuped data, even more if
it stored in 'foreign' formats (here tar). Moreover, the current
implementation of writing TAR snapshot files (snar files) contains
errors and updating tarballs in only possible for uncompressed tars. So,
I consider to cut rebasing completely. But that's another story...


Yes, that was also my feeling when this rebasing was discussed on the 
nssbackup-team.




--
Groetjes,

Anton
 _ ___
| |   |
|  _   _  ___,| K. Anton Feenstra |
| / \ / \'| | | IBIVU/Bioinformatics - Free University  Amsterdam |
|(   |   )| | | De Boelelaan 1083A - 1081 HV Amsterdam - Netherlands  |
| \_/ \_/ | | | Tel +31 20 59 87783 - Fax +31 20 59 87653 - Room P136 |
| | feens...@few.vu.nl - www.few.vu.nl/~feenstra/ |
| | Interfacing Space and Beyond... (P. J. Harvey)  |
|_|___|

___
Mailing list: https://launchpad.net/~nssbackup-team
Post to : nssbackup-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~nssbackup-team
More help   : https://help.launchpad.net/ListHelp