Or was there a really long chain of incremental backups?

Those things might make it very slow (in which case it may appear hung for a little while) although I would expect it to provide some feedback.

I wonder if perhaps moving your MySQL DB has caused the issue? Perhaps it hasn't been backing up your DB? Have you been regularly checking your backups to make sure they are ok previous to this restore?

But 14GB is pretty big backup for a website! I would think that that could be trimmed down a bit. Without looking at what your backup contains my suspicion is that perhaps there is significant cached files and other cruft being backed up that you probably don't want/need.

ncdu is a handy commandline app to see where all your storage space is being taken up. It isn't installed by default but you can install it easily like this:

apt-get update && apt-get install ncdu

The process I would take would be to clean up your server as much as possible, including going through your site and getting rid of old revisions of pages that are no longer relevant (assuming that you use the revision feature of Drupal), clearing the cache (from within Drupal), removing any modules that aren't being used (and remember that when you uninstall a module through Drupal the files still remain on the server - they still need to be deleted - when I do this, to be on the safe side, I move them first then check that everything still works before I delete). Also you can compact your DB and see where all that leaves you.

Then use ncdu to see where all your storage space is being taken up and (carefully) delete what is no longer needed (but only if you are really sure!). It is probably worth reading up on the TKLBAM docs, especailly the added features and power that came with v1.4 (AFAIK v13.0 appliances come with it by default). I'm not sure if the TKLBAM man docs have been updated to include all the new features, but the blog announcement and the release notes give lots of detail.

As for my testing regime; I like to test each full backup and occasionally test incremental ones. The beauty of using the Hub/AWS means that you can test these backups in a 'throw away' server. I find TKLBAM reliable and am yet to have any major issues with it (touch wood) but I'd rather be sure than have to deal with the repercussions of something going wrong if/when I really need it.

Just to go back to your initial issue though, have you checked the logs at all? They should be in /var/log and as of TKLBAM v1.4 it should write logs as it goes (earlier versions only wrote the log when it was finished, making troubleshooting incomplete backups/restores hard).

Re backup chain: As you are probably aware there are 2 types of backup: Full (which as the name suggests is a full standalone backup) and incremental (just the files that have changed since the last full or incremental backup. So an incremental backup relies on all the previous incremental backups, all the way back to the last full backup - this is known as a chain.

Incremental backups are great in that they don't take up anywhere near as much space as a full backup. Also if you want to roll back just a day or 2 (depending on your backup frequency) then you don't need to download your whole full backup. But as the chain gets longer then your restore becomes slower and more prone to issues. If one link in the chain gets corrupted or broken then all bets are off - you will only be able to restore to the backup after the broken one (or all the way back to the last full - i.e. everything between the broken incremental and the full is lost). If you are doing daily backups then a month ago is probably not too bad, although personally I prefer the inconvenience and increased cost of more regular full backups. But as I have suggested it is a tradeoff so you need to decide what is the best balance for you. On servers that are important I prefer to do more regular full backups (one per fortnight with daily incremental backups) and I generally only keep 2 full ones.