[Feature request] make it backwards compatible because upgrade-backups is incredibly slow and not reliable

[Francesco Potortì]

I have backups in old format (1.4) and would like to convert them to the new format (1.5).
As suggested, I use sbackup-upgrade-backups.
It starts well, and after a couple of minutes it begins to create a snar file.
It takes seven hours to grow the snar file to 800kB on a Samba-mounted backup file system.

The problem is, it gets slower and slower. It has run for eight days now, and the snar file is little more than 4MB is size.

I noted snar file size and time a couple of times a day and plotted the file size versus time needed, and I get a scaring log-like behaviour: on a semilog plot I get a more or less straight line. If it goes on like this, it will need ten days to get to 5MB, and 100 days to get to the expected 10MB (the size of snar files of similar backups). I can provide the numbers if needed, but the plot is well fitted by a line that grows by 5MB per decade.

Clearly there is somethimg wrong here. Maybe these number can ring a bell in sbackup-upgrade-backups' ears.

[Thomas L. (tjl)]

For me:
19:29:56,066 - INFO: Creating the SNAR file

Right now (19:46:33) file size is: 392766 bytes

I have a locally connected USB 2.0 drive...

As I already noted in 1000896 - when you are in need of restoring a snapshot you usually don't have several days time to do that.

First having to convert the snapshot before being able to apply it - and risking the integrity of the very backup itself when doing that - is really not user friendly.

[Francesco Potortì (pot)]

I finished converting my old backups. While doing so, I logged times and snar file size as usual. During the last conversion, I observed that the behaviour had changed from an exponential to a quadratic one, so that generating a 9MB snar file required 20 days rather than the 60 that were needed before.

Since I see that the sbackup-upgrade-backup utility itself has not changed, I must assume that something else has. My guess is that either the Samba libraries have changed or the Python libraries have. Maybe sbackup-upgrade-backup uses some Python library which has been reimplemented with a faster algorithm.

[Jean-Peer Lorenz (peer.loz)]

Hello Francesco,

thank you for using sbackup and reporting this issue!

You are absolutely right! Performance of the upgrading process is a total nightmare and, also, touching existing snapshots is a BAD idea. Therefore, upgrading is highly not recommended.

I am working on making the restore backwards compatible and there is basic support for reading and writing arbitrary snapshot versions in my current development branch. Unfortunately, I'm short on time and cannot tell any release date when this will be finished. Help is highly appreciated.

Thank you for your help and sorry for any inconvenience!

Best regards,
Jean-Peer

[Jean-Peer Lorenz (peer.loz)]

I've finally removed support for upgrade-backups entirely. Rather, I've added a restore utility which provides legacy support using the 0.10.5 algorithm. The command must be executed from terminal, i.e. no graphical desktop icon will be provided. It can be used with command line interface (cli) and also with GTK gui.

Syntax:

'sbackup-legacy-restore BACKUP_PATH FILE_OR_DIR_TO_RESTORE [TARGET_DIR]'

or for more ease of use with gui:

'sbackup-legacy-restore --gui'.