Support

Hello,

do you have any other backup plugin? Do you have more than one backup profile? Looking at the data you reported, it seems that you're backing up older backups.

Let me connect to your site so I can review your settings.

I have made this ticket private so that only you and me can see the information posted here.

Please provide me with the following information:

1. The URL to your site's administrator login page
2. Administrator username and password (Network Administrator for WordPress Multisite installations)
3. FTP connection information

Please allow up to one business day (GMT+2 timezone) for me to log in to your site and debug this issue. When I'm done I will post back. Once the issue is fixed, you can revoke my access e.g. by changing the Super Administrator and FTP passwords.

IMPORTANT INFORMATION
In order for me to help you fast and accurately, please provide the information by copying the form below, paste it into your reply and fill in the information:

----- Access Information Form -- START -----
WordPress Administrator access

• URL to site's administrator page (e.g. http://www.example.com/wp-admin?foobar):
• Administrator username:
• Administrator password:

FTP connection information

• FTP methods supported (e.g. FTP, FTPS, SFTP):
• FTP Hostname:
• FTP Username:
• FTP Password:
• FTP Port (if other than 21 for FTP and 22 for SFTP, ask your host):

----- Access Information Form -- END -----

Please make sure that you have tested the Administrator connection using a different browser or machine than the one you are using daily. Double check that logging in is possible and that the user has Administrator privileges or, if it's a WordPress multisite installation, Network Administrator privileges. Make sure that your site does not block whole countries or IP ranges which would make it impossible for me to log in / connect by FTP. Finally, please do make sure that the FTP connection works and that logging in to it I have access to your site's files.

Kindly note that your site connection information and your site content is handled in strict confidence. Not only we are a reputable development company, we are also bound by law (EU GDPR) to do so. After you file your reply, the connection information to your site will be stored in an encrypted, hidden storage area on our site and will be automatically deleted when this ticket is closed. Finally keep in mind that the people providing support to you are the same developers who wrote the software you're using on your site.

Awesome!

Thank you for the access details.

Looking at your configuration, it seems that the the folder "practicalislam" is the one that holds a lot of data. It has been correctly excluded in the Default Profile, but it's not excluded in the profile "website files".

Please remember that exclusions are stored on a profile basis, so if you want to exclude a folder/file from the backup, you have to exclude it from all the profiles.

Get inside the profile list page, there you can delete the backup profile.

Can you please attach the log of the failed backup? So I can double check what's going on.

How are you triggering it? From the interface or it's an automated backup?

You're backup log is completely empty, you have to increase the log level.

Please get inside your profile configuration and set the log level to "All info + debug", then start it again and attach it here.

Thank you very much for the log file. Looking at it, it seems that the process gets slowed down while backing up the database: it takes so long that the host is killing your backup process after 10 minutes.

Looking at your profile, it was set to dump only 10 rows per step, which is a very low value. I just raised it to the default value of 1000, can you please try again and let me know how it goes?

Ok, you get an error but that's a different error. We get past the database step, the backup gets stopped when we're packing files.

Since it always happen at different intervals, I suspect that the problem is the process consuming too much resources and the host is killing it. Can you please get in touch with them and ask them if they see anything in the logs?

As last resort, you can trigger backups from an external source, using the frontend backups feature.

Ok, let me know how it goes. As previously suggested, if they can't raise the resource limit, you can always switch to frontend backup, triggering them from an external source like WebCRON or even a low power computer like a Raspberry Pi.

You're welcome!

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.

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 120 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 180. 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. 

Changing those values will not fix your issues. As written above, the option that you have to are the following:

This means that you have set up a CPU usage limit either with ulimit or the /etc/security/limits.conf file on your server.

Changing the maximum execution time or something like that is not going to fix your issue.

Ok no problem. Please note that you can still automatically take a backup, you have to use the frontend backup feature and use an external server to trigger the backup.