Support

When you run a backup from the backend, Akeeba Backup's Javascript running inside your browser is trying to execute each backup step right after the other, without any waiting time. When you use a service that makes use of Akeeba Backup's Remote JSON API, like Watchful.li, it's up to the service to decide if the backup steps are to run in quick succession or add a dealy between them for reasons that have to do with bandwidth availability or other implementation details on their end.

Moreover, remember that when running a backup there are network conditions to take under considerations and which could add a delay between two successive backup steps. This is because each backup step is implemented as a separate request to your server. This is on purpose, it avoids server timeouts which plague other site backup solutions. These delays can add up, as I will explain below.

Furthermore, the other major difference is that remote backups work by accessing the frontend of your site. If you have one or more extensions with long loading times running in the frontend (in the order of 1-3 seconds) these small waiting times add up to a big difference since the occur on every single backup step. For example, if the loading time of the frontend is 5 seconds and you have 100 steps required to take a backup you would be adding 500 seconds or 8 minutes and 20 seconds more to the backup time.

Without a backup log file it is impossible for us to tell you if there are waiting times between backup steps. If you do look at the log file you can check how much time elapses between two relatively adjacent lines marked as "====== Finished Step number N ======" and "====== Starting Step number N+1 ======" where N is an integer larger than 2 (the first two steps are run internally, one after the other). For example, this is how it looks for the time between step 3 and 4 on one of my sites:

DEBUG   |190328 22:48:32|====== Finished Step number 3 ======
DEBUG   |190328 22:48:32|Kettenrad :: Setting the break flag between domains
DEBUG   |190328 22:48:32|*** Engine steps batching: Break flag detected.
DEBUG   |190328 22:48:32|*** Batching of engine steps finished. I will now return control to the caller.
DEBUG   |190328 22:48:32|No need to sleep; execution time: 5.7330131530762 msec; min. exec. time: 0 msec
DEBUG   |190328 22:48:32|Saving Kettenrad instance cli
DEBUG   |190328 22:48:35|Kettenrad :: Attempting to load from database (cli) [cli.id25]
DEBUG   |190328 22:48:35| -- Loaded stored Akeeba Factory (cli) [cli.id25]
DEBUG   |190328 22:48:35|====== Starting Step number 4 ======

In this example, step number 3 ended at 22:48:32 and step 4 started at 22:48:35. Therefore there was a 3 second delay outside of Akeeba Backup (Akeeba Backup's code starts running at the "Kettenrad :: Attempting to load" mark and stops running at the "Saving Kettenrad instance" mark).

I hope this information helps!