Support

The restoration script's CLI mode is a drop-in replacement for UNiTE's core feature: unattended site restoration. The other two features in UNiTE (taking/downloading backups, and extracting backup archives) can be handled by Remote CLI and Kickstart. In fact, UNiTE was using these two products under the hood for these features.

I have already documented how you can put it all together: https://www.akeeba.com/documentation/brs/cli.html#cli-replace-unite 

As you can see, it's basically your Option B.

You can change the command line to Remote CLI to download (and afterwards delete) the backup it's taking remotely, as explained in https://www.akeeba.com/documentation/arccli/options.html under "backup" (it's the --download switch, which allows you to combine the options from the backup and download commands, without having to pass the id as it's automatically detected when taking a backup).

As for the configuration file, you can run php ./cli.php config:make to get the default config.yml.php configuration file for the restoration script.

On your target server you'll just need to have Remote CLI, Kickstart, your config.yml.php file, and your shell script in a directory outside the web root. You can run your shell script to have Remote CLI take a backup and download the backup archive into your site's root (deleting the copy on the source site), run Kickstart to extract it, copy the config.yml.php into the installation directory, run php ./cli.php execute, then clean up (delete the backup archive and the installation directory).

If you prefer, you can use Ansible, Chef, or something similar as well. Having separate commands gives you more flexibility in defining the conditions for taking / downloading a backup, and when to execute an unattended restoration.

The installation/cli.php is part of the Backup Restoration Script which is included inside the backup archive itself.

Other than that, yes, you are correct.

Better would be if I could keep these mirrored standby server in sync every hour, during the day, every day. But don't you agree, this approach will take too much system/network resources.

Correct. And you have the right idea about how to go about it.

Create a new backup profile of type "Full site, incremental files". Use the Database Tables Exclusion feature to exclude all tables except what changes often throughout the day. Important! If it's articles, categories, or anything else that has a Permissions tab remember to include the #__assets table.

This backup will only back up the files which have changed, and your high churn database tables. You can run it every few hours (I'd say hourly may be an overkill; every 3 to 6 hours is typically fine for most sites) and restore it on top of your existing hot copy.

Use a full site backup whenever you normally take a full site backup e.g. daily, weekly, monthly. On these dates, pull the full backup onto your hot copy server and restore it after removing all existing files. You will also need to do that when you upgrade Joomla itself since Joomla updates may delete files and restoring a backup does NOT remove deleted files which could lead to the hot copy being broken depending on what changes Joomla has made.

P.s.: Yes I know, I am a little paranoid while using hosting parties like SiteGround, (A2)hosting.com, but “Just because you’re paranoid doesn’t mean they aren’t out to get you.” - Woody Allen ;-)

You can never be too paranoid about data preservation. I have first hand experience. In 2013 when surprise capital controls in Cyprus gave me all of 60 hours to figure out how to move my hosting and my operations before losing access due to non-payment my paranoia proved to be just the right amount. My clients hosted on OVH who shared our paranoia level survived the unprecedented data centre fire which brought other people's sites down for months (and in many cases forever). I've had clients whose host's data centre got wiped out in a flash flood, or a wildfire. Not to mention I've seen data centres getting disconnected for all kinds of improbable reasons, ranging from an idiot in a backhoe ignoring the yellow warning net and digging through a fibre optic bundle, and an earthquake breaking the undersea cable of the data centre's upstream's backbone provider. If I have learned anything in these 25+ years I've been dealing with networking is that it WILL break. It's not a matter of if, it's a matter of when.