why conflict with sbackup?

Asked by Anton on 2009-02-27

Wanting for more sophistication, I want to try using nssbackup in stead of sbackup. (I've also joined the dev team to speed things up, since it all looks very promising).

However, sbackup currently seems slightly more stable and reliable. I'd therefore like to use sbackup, while working on nssbackup.

THis isn't possible when using the deb packages, due to nssbackup giving conflict with sbackup.

So, the question is, why is this listed as a conflict? Are there really things that are incompatible between them? I know nssbackup is intended to replace sbackup, but should that not be up to the users (or distro builders) to decide?

Question information

Language:
English Edit question
Status:
Answered
For:
nssbackup Edit question
Assignee:
No assignee Edit question
Last query:
2009-03-02
Last reply:
2009-03-02
Jean-Peer Lorenz (peer.loz) said : #1

Hey Anton,

I want to try to answer your questions.

>However, sbackup currently seems slightly more stable and reliable.

I really don't think so. In my opinion sbackup contains many (partly blocker) bugs and does not create reliable backups. This was the reason for me to turn to NSsbackup.

>So, the question is, why is this listed as a conflict?

Since both packages have the same purpose it is nor reasonable neither useful for `end-users` to install them beside each other. Main reason might be the backup format: NSsbackup is compatible with sbackup i.e. it uses mainly the same configuration file structure (that's actually all). But this does not mean that sbackup is able to handle data that was created by NSsbackup.

>Are there really things that are incompatible between them?

In fact, due to sophisticated features provided by NSsbackup here is a completelly different backup format in use. You can upgrade your existing backups with the help of NSsbackup, but there is no possibility to read such backups in sbackup again. So, in my opinion (and from the view of end-users) the packages conflict.

>but should that not be up to the users (or distro builders) to decide?

Of course, and the user can decide all the time. You can install NSsbackup (this removes sbackup) and test it, whether it meets your needs. As a smart user, one shouldn't do this with important data ;) The software is eventually crappy. Now, you can decide to use it or to go back to sbackup. If you decide to use NSsbackup you can manually upgrade your exsiting backups. If not, you can re-install sbackup (this removes NSsbackup) and everything is as it was before.

>I'd therefore like to use sbackup, while working on nssbackup.

No problem, you can do so. You can work on the source code and use sbackup. (You cannot and should not modify the files installed from a Debian package, of course!)

Some questions from me:

What are you actually going to work on?
Would you help translating NSsbackup?
Before implementing new features the is a lot of work to be done related to documentation, website etc. Do you have some time/experience?

Thank you, HTH.
Jean-Peer

Anton (feenstra) said : #2

Jean-Peer Lorenz wrote:
[...]
> I really don't think so. In my opinion sbackup contains many (partly
> blocker) bugs and does not create reliable backups. This was the reason
> for me to turn to NSsbackup.
[...]

OK, clear enough. Thanks for your elaborate explanations!

> What are you actually going to work on?

Well, the ideas I had stemmed from my experiences with sbackup. So, I'm
currently re-evaluating them. One thing that springs to mind, is that
you currently cannot set a maximum backup size when compressing. Since
vanilla tar has an option for multi-volume backups, this should be
fixable in nssbackup. It should be useful as well. Another feature might
be something like auto-detect the max filesize, but I'm not sure if that
is feasible.

Finally, but I think that is fixed already, is that sbackup wouldn't
recognize a truncated backup. In other words, verification of the backup
data after backup. There, perhaps, an auto-repair feature might be good,
so nssbackup would try and continue where the problems started. That
might also be good for interrupted backups, especially for remote ones.

> Would you help translating NSsbackup?

Possibly, I'm native dutch, I don't know if that's there already?

> Before implementing new features the is a lot of work to be done related to documentation, website etc. Do you have some time/experience?

Little time, and little experience. But I'm happy to spend some time
learning how to do things properly.

--
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 |
| | <email address hidden> - www.few.vu.nl/~feenstra/ |
| | "You Could Be a Shadow" (The Breeders) |
|_____________|_______________________________________________________|

Jean-Peer Lorenz (peer.loz) said : #3

Hey Anton,

very nice. Help is always appreciated.

Some final comments:

>vanilla tar has an option for multi-volume backups

NSsbackup supports uncompressed multi-volume backups create with TAR. However (AFAIK) does TAR currently not support compressed multi-volume backups and I think it takes quite a long time till this feature will be supported by TAR. For this reason I've created a blueprint (https://blueprints.launchpad.net/nssbackup/+spec/use-dar-for-backups) for using DAR as a long-term goal. This would indeed solve quite a lot of problems/feature requests. But before starting any work on this I think the most important aim is to make NSsbackup a stable piece of software, to merge it with sbackup and to enhance all the documentation stuff. Many usecases can be well covered by using TAR. Moreover some modifications on the software's infrastructure will be necessary.

>auto-detect the max filesize

Yes, I think this would be useful and feasible but has low priority. Maybe you create a blueprint for this?!

>verification of the backup

This must be done next (with high priority). I hope, the TAR included `verify` functionality can be used (see https://blueprints.launchpad.net/nssbackup/+spec/integrity-check),

For translations have a look at NSsbackup's translations site within Launchpad. You can easyly contribute and you are allways asked to send suggestions for string replacements (better suited strings for the application - so anybody can understand what is meant by an option, text field etc.)

Thank you for your interest.
Best regards. Jean-Peer

Can you help with this problem?

Provide an answer of your own, or ask Anton for more information if necessary.

To post a message you must log in.