I'm a big fan of Duplicity and I use to backup my laptop to my office based server over
scp which in its turn encrypts everything with EncFS and syncs everything up to my SpiderOak account. I was going under a typical maintenance today and I run
duplicity collection-status to see how many backup sets I have.
Surprisingly duplicity returned only one full backup set more than a year old and no other backup sets. After some digging I found that the returned backup set was indeed the only full set I had but besides that I had many incremental sets. Re-running the collection-status command returns some of the incremental backup sets and running it for a third time I get different -smaller- number of sets. My initial thought was that duplicity broke due to the large number of incremental sets or maybe EncFS cannot handle that many files in the same directory.
Fortunately duplicity has a very verbose log setting
-v 9 which returned interesting SSH logs
ssh: [chan 1] Sesch channel 1 request ok
ssh: [chan 1] EOF received (1)
ssh: [chan 1] EOF sent (1)
I tried the
--timeout flag to increase timeout with no luck. Finally running duplicity with the
sftp backend made the problem go away. All my backup sets were available and nothing strange in the SSH logs. I do not have any hard facts on why I chose to go with
scp backend in the first place but it appears to be less stable compared to
sftp, albeit this is the first time I run into problems with it.