Different backup jobs can not be started individually

[Bzzz]

Hi,
I need to report something that is already marked as an limitation in the GUI. It's great that this is known, but not fixing it won't solve the problems involved...

When creating more than only the default profile, sbackup is not able to run them individually. One solution is to mark every unwanted task as disabled, so that it is ignored. Upon deactivating the default profile, the GUI responds that one cannot disable it; instead, the task you want should be set up as the default one (and the contents of the default job as optional). Nice said, but not very useful. I haven't found a way to just mark the other one as default, and doing nasty things in the system folders to swap the config files is extremely user-unfriendly.

The new task I just set up is to backup a special documents folder. I have about 20 revisions of that folder stored on an USB memory stick .As I'm unable to find a free Windows backup tool that doesn't require admin rights to install and that is capable of incremental backups with proper folder naming (not folder syncing, no required .svn/.git system files in the working copy), I decided to outsource that task onto my main machine that is already running sbackup for complete system backups. So I'd like to create pseudo-history backups by putting in revision after revision in the backup path, running the task, and converting my huge archive into a set of incremental backups. Every future version is backed up daily, so that's fine.
Problem is: Every revision of that folder also creates a forced backup of my system folders, as this is the default task. OK, that's just ~50 MB if I do not do anything else in parallel and don't wait very long between the single procedure steps, but it is very annoying to have a full HDD scan because of that when just indexing a few MB of new data in the documents folder...

//using sbackup 0.11.4 from Ubuntu sources, 12.04 Beta

[Jean-Peer Lorenz (peer.loz)]

Thank you for using sbackup and for taking the time reporting this bug.

As you already stated this is a limitation of the current implementation. It will be fixed in future versions of sbackup (help appreciated). I will mark this as wishlist to keep track of it.

Thanks for your help and patience.