Support

Extract the backup archive and proceed with the restoration.

Rename the media folder the media.bak

Unzip the ZIP file into the media folder as you did before

Copy the files from media.bak into media.

The reason is that the media folder contains the Joomla-version-specific JavaScript, not just user-provided media files. You can't use an older or newer version's media files.

None of that will help. The backup does not run in a single page load. It splits the work in multiple page loads, each one running for a few seconds (see the documentation about the minimum and maximum execution time options in the Configuration page). Moreover, we already unset PHP's timeout, and set an ample memory size.

The configuration values for the post size, the upload max filesize and the max input time your host gave you are completely irrelevant. They have nothing to do with the backup. They just gave you a canned reply without bothering to understand the issue.

Are you taking the backup from the backend of the site? The problem would be that your device goes to sleep, your network connection is disrupted, or your browser put what it considers an inactive tab to sleep. The solution would be to disable device sleep, and have the browser tab running the backup run in the foreground.

Are you taking the backup using a CRON job? The problem would be the host's CPU usage limit (ulimit -t). They can change that; it's something that requires root privileges on the server.

So there's not much I can do and wait 1 hour if I have to?

Knowing the browser you are using makes answering this so much easier. The feature in Firefox is confusingly called "Tab Unloading", even though what it does is simply disable JavaScript timers i.e. tab sleep. I guess words have lost all meaning now. The linked article describes how you can disable tab unloading . If you disable tab unloading you don't have to wait for the backup to finish. Disabling tab unloading is a good idea, unless you make a habit of leaving dozens of tabs open in the background (a bad idea for so many reasons, including security and privacy).

Alternatively, you can set up the backup to run through a CRON job, scheduled task, or third party application/service. Since these methods do not go through the browser they are not affected by the tab unloading / tab sleep features.

I don't know if it's faster to go through a zip but it might be better to make 2 different akeeba profiles:

I would personally go with two backup profiles, not because it's faster, but because it's easier to manage. 

If you are going for sheer speed, using ZIP is always faster. ZIP is an archiver using native code, it can use as much RAM as you give it, and does not have to perform any of the checks Akeeba Backup does to decide what goes into the archive.

Do consider, though, that putting stuff in a ZIP file is just the beginning of it. You need to keep track of how they correlate with the main site backup, you need to remove older copies you no longer need, you need to upload the backups to off-site storage… Akeeba Backup handles all of that for you. If you go your own way for the media folder you'd have to reimplement all of that which is very expensive and very error-prone. But you are already paying for Akeeba Backup which solves these exact problems, so why not use it? And that's why I would personally go with two backup profiles.

I mean, the ideal solution would be having any browser set up with tab sleep disabled just for running backups. I can't recommend a specific browser (unless you want some obscure Linux-only browser you've never heard of and can't use). All mainstream browsers have tab sleep enabled by default. It's up to you to choose whichever browser you trust, and disable tab sleep.

Set a smaller part size for split archives, e.g. 500 MiB. Set up a post-processing engine to upload the files to remote storage, and make sure to check the checkbox to upload the files immediately. This means that your backup requires about 2 to 2.5 times the part size for split archives in free space.

You have installed the Core version, not the Professional version, that's why.

Kindly note that you are asking me about a version of our software which is six major versions behind and has been end of life (EOL) for nine years. There's a limit to what I can help you with, and I think we've sailed right past it at this point.

My best guess reading the code from a decade ago is that our S3 integration always used path-style access. This might or might not be accurate. I honestly don't know for sure anymore.

The part size for split archives is definitely there, and it has luckily not changed how it works ever since it was added sometime between 2007 and 2008. There's an Archive Engine row with a Configure button next to it. Press it to find this configuration option. It might have a slightly different name, but it definitely has the words "part size" in it.

The option to upload the files as soon as they're created is definitely there in that version.

K2… That's a name I haven't heard in a long time. But yes, I believe K2 had a folder in its media subdirectory where it stored cached files that you may have to remove. No idea why you had remove the images folder. Maybe because it was a really big folder and you were running out of space?

a) Now I see that I've been stuck for 30 minutes on the backup of /home/XXX/nmh-j3.4php5.3/media/k2/items/cache

Yes. You had already asked me, and I confirmed it.

b) is there a way to view the file directory tree of a jpa backup to see if anything is missing?

If you are handy with the command line, you can run Kickstart in the command line with the --dry-run option to list the files.

You can also look at the log file. It will tell you exactly what is being skipped, and what is being included.

And make a single profile excluding these 2 very large directories?

I mean, sure? You already know how to use the file exclusion filters. Why are you asking me if you should use the file exclusion filter feature you are already using anyway…?