Support

You can always copy the backup archive to your site's root, upload kickstart.php and perform the backup restoration. This is described in the Quick Start Guide.

Alternatively, if you have access to your Joomla! site's back-end you can go to Components, Akeeba Backup, Manage Backups and click on the Import button. This will allow you to import backup archives in the Manage Backups page which in turn will allow you to use the integrated restoration feature.

I am not sure what you tried and fails. Do you have a recent backup? Did you try copying it to the root of the site and running Kickstart against it? If you can provide a specific error message I might be able to help. Otherwise you're telling me that Akeeba Backup doesn't work. Mind you, it's been downloaded more than 5 million times (I stopped counting after that mark, reached in November 2012) and I've stood many times in front of an audience doing a live backup, full site erase and resurrecting the site from its grave :)

Regarding best practices, there is only one guideline: you need frequent and tested backups. Regarding restoration it's equally simple: upload the archive and kickstart.php, run Kickstart from the web browser and follow the on-screen instructions. The Quick Start Guide, the User's Guide, the videos and the various third party resources (tutorials, videos) is nothing but an elaboration on these simple principles.

For what is worth, Akeeba Backup was deliberately designed to be used remotely (without physical access to the server). You just need the bare minimum: FTP access and a web browser. From that point it depends on where your backup archives are stored and your available access. If they are stored in your computer at home you're pretty much screwed until you get there. If you have limited Internet connectivity and uploading backups is not possible, you're screwed. I mean, you somehow need to upload your backups and Kickstart. If your backups are on your server or on Amazon S3 you only need to upload kickstart.php and the rest can be performed from your browser. So, "remotely" is a very relative term that takes a lot of interpretation. There's no single set of instructions which work in all "remote" situations.

FYI the 502 means that your host has screwed up. Search it up when you get back home and remember that GD is using a server cluster. Speaking of which. You are using the worst quality host out there. What do you expect? Smooth experience? Their servers are abysmal. That's the problem you have, not my software. Besides, as far as I understand, the only backup you have is from 6 months ago and it restored fine. Then you did something misguided. You started restoring files from the last 30 days without updating the database. And you wonder why this does not work! And you have the nerve to accuse MY SOFTWARE for breaking your site? The one you have been systematically screwing up for two days?!

Look. I already told you. The restoration procedure in your case should be:
Delete existing files and folders because you have created a mess
Upload the backup archive
Upload Kickstart
Run Kickstart and proceed with the restoration script
Wait 10-30 minutes after the restoration. GoDaddy's crappy servers will only see the updated .htaccess after that long.

If you cannot follow this procedure because you are not on your computer and don't have access to your backups it's not a problem with my software, it's a problem with your readiness. Is that clear? I cannot help with readiness problems, random actions I have not recommended.

For what is worth, if you believe Admin Tools is to blame just delete the plugins/system/admintools directory. That removes all of my AT code that's loading on your site. The problem will persist and you'll finally come to do a proper restoration which is the only way to recover your site and the exact reason you are using Akeeba Backup, just like thousands of paying and dozens of thousands of non-paying users.