Support

Akeeba Backup for Joomla!

#26160 Problems with Backup Logs

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by on Thursday, 03 November 2016 18:20 CDT

artisanwebandprint
EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Description of my issue:

Reference Ticket #25484

We are experiencing continued problems with dozens of websites using all of their disk space due to space issues caused by akeeba log buildups and backups that don't complete properly.

I'd like to address one issue at a time since it seems to be a complex blend of multiple parameters.

To summarize what we've done to date:
  1. Changed our bucket name at Amazon S3 to all lowercase, no special characters.
    Changed the part size to 1535.74 with chunk sizes at 1 and big file threshold at 1.
    Elected to Resume backup after an AJAX error has occurred
    Restricted the number of obsolete records to keep to 5 and the number of days to 5.
    Ensured that we have at least 60% of the disk space free (ie: site if 400mb, customer has 1000mb of space).


Despite these changes, after about 10 days, we receive notification that the sites are now over disk quote and the backups are disabled via Watchful. The only files that are building up on the site are the backup files and the logs.

For example, with New Rambler Review, we configured everything to your suggested specs and today we received the notification that the site was over their allotted disk size and that backups were disabled. This site, without any backups or logs uses 257 of 1000mb which should be plenty of space to execute a proper backup. Here's what I found in the backup folder:



The total log files is about 168mb and the two unfinished backups total 350mb. Between the logs and the backups, the site ran out of diskspace to run additional backups or even add new content.

To begin, how do we restrict the number of log files? I keep a close watch on the sites, so I only need up to 5 log files.

Secondly, what else could be the issue?

I've attached the log files from the last five days.

Best,

Dawn

artisanwebandprint
Hello,

In order to move this forward, I did a test today - 10 backups in a row. The Cpanel backup folder simply added the logs and the customer now has lost over 70mb of space. So after a period of time, they will inevitably run out of space.



I have it set to delete more than 5, perhaps my setting is incorrect?



We have to have a way to auto delete these large log files otherwise the sites will continue to encounter errors due to disk quota overage.

Thank you,

Dawn

nicholas
Akeeba Staff
Manager
First, the backup archives. You don't need to keep them on the site once you've moved them to Amazon S3. You can check the "Delete archive after processing" option in the Configuration page to make that happen.

Detailed log files only make sense when you are troubleshooting an issue. Under normal operation you can always set the Log Level to "Errors Only" or even "None" in the Configuration page. This will still create a log file (since the log file is created before the profile configuration is read from the database) but it will be zero bytes, taking up no space. Please note that if you do that and you need to request support at some point you will have to set the log level back to "All information and debug", run another backup and then send us the log file.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

artisanwebandprint
Hello Nicholas,

We do have "Delete archive after processing" checked for our sites. We have also changed the Log Level to "Errors and Warnings" to minimize the log file sizes which is helping tremendously. We no longer have issues with the log files taking up all the disk space. But one of our sites is still having issues with the .jpa file being stuck in the backups folder. This is one of our larger sites (about 2.14gb). We have 5.86gb of space allocated to this site which seems like plenty of space. The site is not growing in any way (since the log files aren't piling up). Here is a screenshot of our settings: http://screencast.com/t/J0cKPz2d . Attached is the log file.

Why are the .jpa files still not being deleted from the backups folder?

Thanks

nicholas
Akeeba Staff
Manager
The answer to that question is in the log:
WARNING |161001 07:58:15|Upload cannot proceed. Amazon S3 returned an error message: 0 :: Akeeba\Engine\Postproc\Connector\S3v4\Connector::uploadMultipart(): [55] SSL write: error -5961 \n \n Debug info: \n

There is an SSL error at some point trying to upload the backup archive. This is something on your server, for example PHP, the PHP cURL extension or libcurl itself compiled against an old OpenSSL version which is no longer compatible with the (updated) Amazon S3 servers. You can always disable SSL for S3 uploads in Akeeba Backup's options.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

System Task
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!