You cannot backup remote sites. We explored that idea but it's impractical in the real world.
Accessing the site's files over FTP / SFTP is too slow and subject to timeouts, rate limiting and other server-side protections which make it impractical for taking a backup of anything but the smallest sites on the fastest servers (think about 2-3 hours to remotely backup a site that takes roughly 10 seconds to backup when Solo is installed locally).
Accessing the site's database is usually a non-starter. Most hosts don't allow remote MySQL access and those who do require a static IP from the accessor. Therefore most sites would be impossible to back up and those which are theoretically possible would be hard to setup by the majority of our target audience.
Trying to iron out the implementation details we essentially came to the realization that we'd need to have most of Akeeba Solo installed on the site to be backed up so the backup can run locally, then feed the archive files to the remote backup server. However, that would be a pointless idea since Akeeba Solo Professional already allows you to do that in conjunction with Akeeba Remote CLI. Therefore the solution for remote backups is to install Solo on the server that contains the sites to be backed up and use Akeeba Remote CLI. This feature has been implemented as the JSON API and is available since version 1 of Akeeba Solo.
Remote restoration has the same problems as backing up, i.e. file and database access. While we allow you to extract a backup in a remote server the rest of the restoration (the ANGIE restoration script) runs on the remote server itself. This feature has been implemented as the Site Transfer Wizard and is available since version 1 of Akeeba Solo.
Nicholas K. Dionysopoulos
Lead Developer and Director