Hi Jean-Peer - no problem (though it is inconvenient, I can always 'tar | ssh dd' as a workaround).
According to my software center history, I've been running 0.11.4-0ubuntu4 at least since september (I also ran 0.11.6-0~bpo70+1 for a while, but I don't remember if I that gave me problems -- if it did I must have reported that). This was on ubuntu 12.04.
With 14.04 upgrade, I got sbackup 0.11.6-0ubuntu1, since April 22.
I attach a sanitized sbackup.log. I cut out all but the first and last INFO on corrupt snapshots found, and all the messages about files found for in/exclusion.
Backup is to a local ssh server, which is running an ancient Scientific Linux (based on RedHat ca. 2007). As said, I can 'sudo ssh <user>@<backuphost>' without being prompted for password. As you can see in the log, sbackup *is* able to access the remote filesystem, because it can find the backup directories, recognize several as corrupt and find the latest succesfull backup (now 28 days ago).
Hi Jean-Peer - no problem (though it is inconvenient, I can always 'tar | ssh dd' as a workaround).
According to my software center history, I've been running 0.11.4-0ubuntu4 at least since september (I also ran 0.11.6-0~bpo70+1 for a while, but I don't remember if I that gave me problems -- if it did I must have reported that). This was on ubuntu 12.04.
With 14.04 upgrade, I got sbackup 0.11.6-0ubuntu1, since April 22.
I attach a sanitized sbackup.log. I cut out all but the first and last INFO on corrupt snapshots found, and all the messages about files found for in/exclusion.
Backup is to a local ssh server, which is running an ancient Scientific Linux (based on RedHat ca. 2007). As said, I can 'sudo ssh <user>@ <backuphost> ' without being prompted for password. As you can see in the log, sbackup *is* able to access the remote filesystem, because it can find the backup directories, recognize several as corrupt and find the latest succesfull backup (now 28 days ago).
Any pointers to where we should look further?