TKLBAM Restore failure (Amazon Web Services)

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

@StuC: No multiple routes, no load balancers.

I finally gave up after 3 days of restoring without success.  Almost 8 out of 10 times reading the files failed (often after hours of waiting). When it didn't it stopped during the restore phase (very early in this stage). I've been watching the restore closely with top, df and du during the process to ensure no filesystem was overfilling and if the expected processes were still running...

The only things I doubt on which might have had an effect on the backup created and therefor the result of the restore:

1) during this cycle of full backup and incrementals the location of the database files was changed from /var/lib/mysql to /mnt/var/lib/mysql (due to space restrictions)

2) the location of all the webserver and database data was on /mnt/var (and in sub folders), which caused the reason for restore (since when my server was upgraded from small to a medium sized, CPU optimed sized server at AWS this whole volume is replaced, and no longer contains the data previously on this volume)...

3) total size of the backup was 30GB with a full backup made at Sept. 6 and incrementals up to Sept. 23 which might be too much to deal with by the TKLBAM software???

All and all I'm very disappointed in this solution, I've lost app. 9 days of production data (luckily I had some export of the most important databases from the 14th still available)... I wrote my own backup scripts to secure my data for the future...

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?

I'm not sure when the change was made, so without a lot of itterating long during trials this is going to be diffficult.  After three days of restoring attempts I gave up and rebuild from a previous export...

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?

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

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.

Can't connect errors won't be avoided but perhaps using the --limits= switch you could just download the DB. At least then you might have a better chance of it downloading the bit you really need (assuming the DB is the bits that is most important). You could also try that to download specific parts of the FS if need be.

Have you double checked your networking/internet to make 100% sure nothing is going weird there?

Another TKLBAM switch that might be of use is the --simulate switch. Perhaps that might give you a better idea of what/where it is actually going wrong?

Also even though at the commandline it is showing an error, it might be worth checking the error log (IIRC /var/log/tklbam) as perhaps that has some additional info?

FWIW TKLBAM is currently a free service. But by default it is configured to use Amazon S3 storage (which you pay for). TurnKey Linux do not get a cut of that (actually it costs TurnKey to do it because of the way Amazon billing works), that is purely the Amazon cost of storage. It's a bit like giving you a car but you still need to pay for fuel...!

Additionally you have the option of storing you backups locally (or on a multitude of other options - so long as you can configure it - this is documented). Then you have to take responsibility for any storage costs associated directly yourself (rather than it being done via Amazon DevPay)

That's not to fob you off, as ideally TKLBAM should just work and it should be supported. On the flipside though it is free open source software which you are free to adjust (or pay someone to adjust) if you so desire. The code is available via GitHub.

TKLBAM accepts the --raw-download=path/to/backup/ switch which should do what you are asking (I think?). Source

[update] Sorry I just reread a little of this thread and I think I understand what you are saying... You actually want to download direct from the S3 bucket (without using TKLBAM at all? TBH I have no idea of how you would go about that...