- Posts
Two issues actually:
1. ZipArchive failed because the backup was too large. Excluding uploaded files to reduce the size allows it to work
2. The bigger issue is that the failure of the zip resulted in a failed backup and it did not send any notification. I get notifications of successful backups so I know the process and the email address is good but there were no failed notifications.Hi Alan,
Thanks for coming over from the BoldGrid Team Orange page with your Total Upkeep questions!
Zip Archive failure
The first issue that you mentioned was your ZipArchive backup compressor failing becuase the backup was too large. Normally, when this fails without error it’s due to the size of the backup exceeding a limitation of your hosting account and it may not be possible to workaround without increasing your server resources. I think that fact that “Excluding uploaded files to reduce the size allows it to work” is a big indicator that this is the issue.
Changing the backup compressor type
If you experience this issue again, you can first try changing the backup compressor type to SystemZip and see if that allows the backup to complete. Navigate to Total Upkeep > Settings > Backup Process. If System Zip is available, choose that option. System Zip is significantly faster than the PclZip or ZipArchive libraries, and may use fewer resources. Attempt to create another backup using the Default compression level.
If the backup still fails, try reducing the Compression Level. As an example, a setting of 0 will not compress the backup at all, using the lowest amount of CPU and memory. This does mean that the Disk Input/Output is increased due to the larger file size, however.
Filelist Analysis
Similar to excluding uploaded files to reduce resources you can perform a complete filelist Analysis. If your backups are still failing after switching the Backup Compressor and Compression Level, set the Compression Level back to Default, and check the box to enable the Filelist Analysis. Attempt to create another backup.
Navigate to Total Upkeep > Tools > Logs, and look for the most recent log that ends in
filelist.log. Examine the filelist and look for any very large files or directories. You can then delete those files if you don’t need them, or exclude them from your backups to conserve resources.Backup failed w/o notice
In most cases you should be notified right away in your Total Upkeep dashboard if the backup times out or doesn’t complete for some reason. In that case you will receive an email correspondence, but there are rare times when the backup will complete with errors. In this case you may not be notified but you can confirm if the backup completed properly in your backup logs. Navigate to Total Upkeep > Tools > Logs and look for your most recent log with a name like
archive-XXXXXXXX.log. If you can copy that and paste it here, we’ll be able to get some more information about what went wrong.Perhaps if we can determine exactly what caused the file to become corrupted we can add a feature request to have an email triggered when it’s detected.
We look forward to hearing from you and assisting you further with this Alan.
Sorry, I just got back to this. Nothing personal, but in all of this verbiage, the response provided nothing useful.
1. I do not have an option for choosing System Zip nor do I see any option in the admin page for changing the compression level. I can only select from PclZip or ZipArchive
2. I did already remove files that were backup copies of items that InmotionSupport generated along the way and left in the folder structure.
3. “being too large” is a terrible cop-out by backup software used for DR/BC. Your software should spawn multiple zips or utilize other strategies to ensure complete and successful backups and restores regardless the size of the source.
4. It should know when it is running out of resources, either memory, php limits, disc space, etc and clearly communicate both in the UI and emails that it failed and why. Even better is to detect before running and wasting time processing but a lot of times that approach is a lot of upfront work that may not be practical.
5. There should never be a time when it fails without notifying. Thats a rediculous accepted behavior for backup software which is a critical software component in any BC plan.
6. It would also be nice of the Backups tab has a link to the backup logs from when the backup was generated. you should not send your user having so search files to find one matching the right time. If either the user or the developer is going to be lazy, the user has to win out and the developer has to do the work.
7. I’ll also add when initially using TotalUpKeep to migrate my site while it created the zip ok, both the online and uploaded file approaches failed to restore the site because of the all in a single file approach which caused the process to exceed PHP memory limits. It would just fail. I had to work with support to id that just to get my site migrated. it was a poor first-time exposure to this plugin experience.
5.
Hey Alan,
No worries, I don’t take this personal at all. In fact, I think you makee a lot of good points.
– First I want to say that if you do not see an option for choosing System Zip it’s okay, it may not be available for everyone. We normally test before recommending it as an option but I wanted to touch as many bases as I could with you in my reply.
– I do apologize, the process of excluding files from your backup is a bit different from removing them from your website file structure. This guide explains how to exclude files from your backups to conserve resources in detail.
– When we say the file is too large that is only based on the limitations placed on your own account by your web host. IMH offers a backup solution that is not a wordpress plugin, server side backups – https://www.inmotionhosting.com/support/product-guides/backup-manager/purchase-backup-manager-using-amp-marketplace/.
– I definitely understand your concern with backup failure notifications. The thing is a backup process can be killed by the server, and when this happens we try to send a notification however, sometimes we can’t send the notification when the process is killed.
This leaves us with an area of opportunity to improve our plugin. We will work to find a way to send the email in a separate process to ensure its delivery.Having backups in 1 file has its benefits (e.g. easier to manager rather than multiple zips), but you has a valid point on having smaller and more manageable zip files. The development team has had this discussion, and it is on the roadmap but there are no promises as of now on a delivery date.
I also agree that it would be nice if the backups tab has a link to the backup logs from when the backup was generated. I actually think this is a great idea! I’ve created a ticket in GitHub for out developers to review and hopefully we can get it accepted and in the pipeline.
I apologize for any inconvenience Alan. We hope to work continue to work with you. Your suggestions will definitely contribute to making our plugin better for our end users.
Thank you, and we’re looking forward to hearing from you.
- The topic ‘WordPress backup with Total Upkeep fails due to file size’ is closed to new replies.
