Support

I can see in your log file that it takes 16 minutes to upload the JPS file via SFTP. If you read the documentation, we've already explained why this causes web-based backups (as opposed to CLI-based backups) to fail with a timeout. Indeed, you get an HTTP 504 Gateway Timeout error, exactly as we said you would. We also explain the solution is to set a Part Size for Split Archives that's relatively small, typically in the area of 10 to 50 MiB. See https://www.akeeba.com/documentation/akeeba-solo/restoring-backups.html#general-guidlines-cloud-remote-backup under "Most failed uploads are caused by timeouts". Also keep in mind that this part of the documentation is identical across all our backup products.

Why is that? Because Akeeba Backup for Joomla, AKeeba Backup for Wordpress, and Akeeba Solo share the same backup engine. The upload can not work any differently between backup products; it's the same code.

The most likely difference is that on Joomla you were taking the backups with a CLI CRON job, whereas now on Solo you're trying a backup over the web. If you had tried taking a backup over the web with Akeeba Backup for Joomla! you'd have the same issue. Likewise, if you had tried taking a backup with a CLI CRON job using Solo you wouldn't have had an issue.

You're welcome!

Well, the FTP backup's log file says that the backup archive is indeed tiny:

DEBUG   |20240612 14:42:04|Total size of backup archive (in bytes): 794321

That's 775.71 KiB. The reason is that you have set the site's root folder also as your output directory.

Exactly the same thing with the SFTP backup... which is for another site?

I have several remarks here.

1. When you are trying to troubleshoot you must keep everything the same except one and only one variable between runs. Otherwise, you cannot be sure which of the myriad of variables you changed had any effect, or if two or more changed variables combined in a way that you got the same effect for a different reason. Therefore, using many different sites to test one problem is a big no-no. Modify the configuration of the same site, only changing one thing at a time between runs.

2. Never set your backup output directory to coincide with a directory whose contents you want to back up. The backup output directory and all its contents (its files and subdirectories) are automatically excluded from the backup. This is a sanity feature. It prevents an infinite backup, where the backup engine tries to back up the increasingly bigger backup archive.

3. Never set your backup output directory to a site's root. Remember that Akeeba Backup will overwrite your .htaccess and web.config files in there, and add a blank index.html file to prevent web access. When you do that to a site's root, you will end up making that site inaccessible from the web!

4. You should build your backup process up, not try to do everything all at once. First, make sure that you can take a full site backup, stored locally. Then, configure its upload to a remote location and check it works. Finally, set up the automation. Note that this is exactly what I do with my own sites. Trying to do everything all at once is a recipe for trouble. It is only human to expect a problem in the last thing you configured; in your case, setting up the remote storage. In most cases the problem will have to do with a previous step of the setup, which is now out of mind. Doing one thing at a time and verifying it ensures that the first and last thing we did before having to troubleshoot is one and the same, i.e. we are far more likely to figure out what the root cause of our problem is. If no problem happens, yay! All the better :)

Please read points 2 and 3 of my previous reply. As I said, you will need to change the output directory. Also note that if you really imported a backup profile which used the site root as the output directory, that profile never worked right to begin with. It stands to reason that if you import something non-functional the imported result will also be non-functional.

Again, what I see in the log is that the root of the site is excluded. Based on the path I see for the site at the start of the log, and the path I see for the archive at the end of the log, it appears that your output directory is set to coincide with the site's root.

I can also tell you that importing is a dumb process; it transcribes the JSON file into a backup profile. It does not make any other decisions.

I can tell you, furthermore, that if you open the Configuration page and then save it with an output directory that's invalid then the output directory will change to [DEFAULT_OUTPUT] which is the backups folder inside Solo's installation folder. It will never change automatically to the site's root.

Based on this information, my only reasonable conclusion is that this is the case of a user error. Perhaps you navigate to the above-root folder but don't click on Use. Perhaps you confused the two directory boxes and ended up changing both to point to the site's root. I don't and cannot know what you did. All I can tell you is that you did something wrong, how I see that in the log file, and what you can do to fix it. Therefore, I will be closing this issue as resolved since the root cause of the problem (output coincides with site root) has been identified, and a solution has been presented to you.