Support

It's generally good. Some notes:

> use the live site url in the restoration and configuration file

No. The live site should be EMPTY. It's only there for very specific servers with a broken configuration. You don't have one of these. Empty it and leave it empty.

> Turn on the mail in the Joomla plugin

You can disable email sending in Joomla's Global Configuration. This setting can be managed at restoration time in the Site Setup page.

> I am aware of your warning about using a browser for any of this process

I have said you should not use a browser to download files from your site. You don't do that, so why are you worried?

Using Dropbox is just fine a method as any. If I didn't think that Dropbox can be reliable enough for backups I wouldn't implement a connector to it. Also keep in mind that when a previously reliable method becomes unreliable I will remove it without a second thought (as I did a couple of years ago with pCloud).

> Is there a list of servers that dont work somewhere for this field?

No, it actually has to do with the server configuration.

By default, all web servers (Apache, LiteSpeed, IIS, NginX, …) forward the Host HTTP header to PHP. This is the header sent by the client trying to access your site and has your site's domain name. This is used by Joomla to determine the domain it is running on.

Some servers are configured to not forward this, in a wrong attempt to address the issue addressed by Admin Tools' Allowed Domains feature — check its documentation to understand the problem. These servers won't work without setting the $live_site. They were incredibly rare in 2001 when this feature was introduced; think about one in 100,000 or less. They are even more rare now.

> I have done a few with this method and if I recall corectly then I dont need to delete the live site folders and files

As long as you stick to the same Joomla version family (major and minor version, e.g. 4.2) and you do not remove or update any extensions: you don't need to delete anything. If you changed the Joomla version family and/or removed or updated any third party extensions you'll need to delete existing files and folders. Remember that extracting the backup can only add and overwrite files; it will not remove files by default.

> One other question comes to mind for post restoration, if it fails or I want to restore the previous live site is there a method to do that

Using Kickstart. It's documented and we also have video tutorials (Restoring on Any Site).

The whole point of an Akeeba Backup archive is that if your server burns down —as it literally happened with OVH a couple years ago!— all you need to restore your site is the Akeeba Backup archive and the free of charge Kickstart you can download from our site. Akeeba Backup was designed as a site transfer and disaster recovery tool from its very beginning in 2006, when it was called JoomlaPack.

> I assume when I do the restoration it will overwrite all the Akeeba backups that were there and replace them with only the ones from my dev site?

Backup records? Yes. Backup files? No.

Hint: you can always completely exclude the #__akeebabackup_backups and #__akeebabackup_profiles tables from the dev site's backup profile. Restoring the backup with the same database table name prefix you were already using on your live site will not delete or replace the contents of these tables which hold the backup records and backup profiles respectively. Therefore you're not losing your backup definitions and backup history upon restoration.