TBH I have no idea what is going on here and why you are having these errors... There seem to have been a few people experiencing issues with backups (although I haven't) but you are the only poster (that I have seen) having issues with restore... 

The only thing I could suggest is that you try contacting the devs direct via the Hub's Feedback (blue button on left hand side when logged in).

I did a 22G restore and had a number of these BotoServerError but it completed OK.

Just out of interest do you have multiple routes to the internet or load ballancing? That idea crossed my mind as we run different connection types and I watched the traffic flipping between WANs as other users fired up services during the restore process.

Stu

It's easy for me to be wise after the fact but the biggest issue would appear to be that incremental backups across file system rework. I'd not trust that on local tape.

Full backup, change layout, new full backup on another tape (NEW LAYOUT) to me.

Not sure its fair to blame TKLBAM but then I have not use many fancy incremental solutions so this may be everyday fare to others.

I might change the frequency of full backups on servers (small scale) I look after as its is quite possible I could be opening myself to issues I don't need.

Question;

Could you restore the server (to a virtual box locally) to just before the layout change, then make the layout change and try the next incremental? if that works make as many backups as physical reality allows - delete the TKLBAM backups and backup/restore to the online service?

The new version of TKLBAM should make mixing and matching TKLBAM with whatever local backup setup you want much easier. Instead of forcing you to go through Duplicity and make "fancy incremental backups" you can ask TKLBAM to just dump the system backup data to a plain old directory and let you do whatever you want with it. It also supports restoring from a directory.

Example use case:

# on system A
tklbam-backup --dump=/tmp/mybackup
tar jcvf mybackup.tar.bz2 /tmp/mybackup

# on system B
cd /tmp
tar jxvf mybackup.tar.bz2
tklbam-restore /tmp/mybackup

FWIW, TKLBAM v1.3 is the new version in TurnKey 13 RC3 package archive. I'm working on backporting it to TurnKey 12 right now.

That sounds a great option to have.

Where net connections are slow/busy the ability to manipulate local backups in such a simple form should make testing or secondary backups so much quicker. I was a reluctant convert to cloud backup and bandwidth used during restore checks or changes presented a bit of a log jam for us UK users where significant parts of the country are still on slow ADSL.

The flexibility and just plain can-do of this system grows daily, I'd be genuinely lost without the ability to set up a particular server in minutes now.

I've had conversations about a possible requirement and in the time is takes to describe the need I've had a VM downloaded and ready for test. Awesome service.