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.