Support

Your backups fail because your host is imposing a maximum CPU usage time limit. Please note that CPU usage is different than wall clock time, hence the small variability of a few seconds you may observe in different backups' log files from the start of the backup until the point it abruptly stops.

You will need to contact your host and let them know they have to make a configuration change in their server to let you run your backups. You may use the following text, replacing XYZ with the time it takes to run a backup from the backend plus about 10%. You can find out the time it takes to run a backup in the backend of your site, Akeeba Backup, Manage Backups. If you have multiple backup profiles use the time from the longest-running profile.

Here is the text to use:

I am using CRON jobs to take a backup of my site. I have observed that my CRON job stops executing at around 200 seconds. This is not enough time to complete a backup of my site. This means that you have set up a CPU usage limit either with ulimit or the /etc/security/limits.conf file on your server.

Please make the current CPU limit for my user into a soft lift and set up my CRON jobs so they have a CPU limit of XYZ. This would allow my backups to run without affecting the sensible time limits you have set up for PHP script running over the web.

If your host refuses to make changes you can still automate your backups, either using a third party over-the-web CRON job service which respects redirections (e.g. WebCRON.org) or a third party service which is compatible with Akeeba Backup such as myJoomla.com, BackupMonkey.io or Watchful.li. The latter kind of services also offer additional features such as security auditing, site monitoring, management of core Joomla and extension updates across multiple sites, even backup testing automation in some cases.

The downside of third party services is that they cost money. You can alternatively have an always on-line computer (even a cheap Raspberry Pi would do!) run backups remotely using CRON jobs, either using the Legacy Frontend Backup URL or the modern Akeeba Backup JSON API. In the latter case you'd need to set up Akeeba Remote CLI on the always on-line computer. The always on-line computer can run any of the three major Operating Systems: Windows, macOS or Linux. 

You have an old backup in your site's root (look for files whose name starts with site-tamarillo.co-20240324-184734utc-Nw6ySgY51BJDmQ44 and have extensions of .jpa, .j01, and so on). Remove them to make some space. You should be able to then run a backup from the backend of your site. Just remember that you must not let your device go to sleep, or switch away from (or, worse, close) the tab the backup is running on.

In general, no.

The problem here is not just the existence of an old backup, but where it was, and why it was there. If the backup was in the backup output folder configured in the backup profile we wouldn't be having this discussion; the contents of that folder are not backed up as there's no point backing up the backups.

The root cause of your problem is that you restored your site with a backup from March 24th, but you didn't click on the Clean Up button at the end. Therefore, the backup you restored remained on your site's root. All files and folders on your site's root are backed up, unless you explicitly specify otherwise.

TL;DR: After restoring a backup, click on Clean Up and make sure the backup archive is no longer in your site's root. Everything else is handled automatically, don't worry.

Yup!

Have a great day!