ElsieBlogger

Got it . . . thanks!

As the latest on this issue, I think I’ve stumbled onto a solution. Under the settings there is a provision to “Reduce server load“. By default it’s disabled. I tried setting it to minimum, then ran a Files backup, but that didn’t help. Next I tried medium and the backup ran without issue. I then ran a FULL backup of everything, and it also ran without issue. The total time was a minute or so greater than I have been getting before the re-start issue, but I can live with that if I can get a full backup without issue. I’m cautiously optimistic that the problem is solved.

Again, thanks for your response.

I have created a job that only backs up the Uploads folder. This includes years from 2011 to 2024. No go, it has problems. I have experimented with excluding different years. Only when I restrict to the earlier years (where I don’t have that much content) does the backup run smoothly. When I go to only the later years (where I generally have 4 or 5 small jpeg photos uploaded each month), the backup keeps stalling and I get the 5 minute re-start happening. Sometimes one restart will see the job through, but frequently it takes two or even three re-starts. For the record, this problem has just surfaced within the past month. All backups prior to this problem were a single backup that included everything (the largest backup to date has been 243 mb).

If it’s any help, when backing using Job Task “File Backup” the compression progress (the bottom indicator) usually stalls around 70%. When backing up everything (all Job Tasks), it stalls at 63%, then again at 72%. Sometimes it will complete, sometimes it stalls around 91%. If it stalls a forth time the program will abort.

Thanks for your response.

I have tried values of 20, 25, 30 (the installed default), and 40. None had any effect in solving the problem. Since my initial post I have uninstalled BackWPup, re-started my blog, and reinstalled the latest 4.1.4 version. As it stands now (after much testing) the problem only occurs when trying to do a backup that contains the Job Task “File Backup”. Trying to narrow it down by the various selections in that job task, I find two areas that are causing the “hang-ups”: 1) Backup Uploads Folder -and- 2) Backup Plug-ins (which hangs-up only sometimes).

I’ve tried backing up as ZIP, TAR and TAR.GZ . . . none solve the problem, though the total time is a bit longer with ZIP and TAR.GZ.

The end result (trying to backup only Job Task “File Backup”) will sometime give me a very long-timed backup, but will occasionally fail with an aborted back-up due to too many failures.

Incidental information: my backup file for everything is generally in the 243 mb range (a backup of everything except the “File Backup” is under 3 mb).

I’ve installed this newer version and the avatars are back! I’ve updated my review to reflect this update and the speedy response.

Thank you!

The plugin author has updated their code as stated above. I updated and it now dismisses the advertisement as it should. I’m going to upgrade my review to 3 stars for a short time to see how it goes, and if the ads don’t “bombard” me, I’ll again return my review to 5 stars. I really do like this plugin, and hope that all is permanently well. For the record though, NO plugin should place an ad on your dashboard. If they want an ad, it should be on the plugin’s dashboard.

I’m pleased to report that the problem with the deprecation statements in the log seems to be fixed. All backups I’ve made since WordPress 6.2 was released have been “normal”. I have no idea if the problem was with WordPress or BackWPup, but I’m a happy camper again. Thanks to whoever solved the problem.

It seems that this deprecation issue goes even deeper than BackWPup. I came across this on the WordPress site explaining some of what’s going on with PHP 8.0 and 8.1. It seems that not even WordPress is fully compatible with these later PHP versions. At least they claim that these deprecation statements aren’t errors (at least not yet). Hopefully the next WordPress release of 6.2 will have all (or most) of these issues resolved. But I don’t know if that helps BackWPup with its problem with 8.1.

WordPress 5.9 and PHP 8.0-8.1

Another week has gone by, and apparently this isn’t a wide-spread issue since there has been no word. When this issue first appeared, another poster was doing a bit of research into the issue, but now all the posts he made are gone! I hope someone at BackWPup – inpsyde is monitoring this forum. Surely this has to be affecting other users.

Up to now, I had all of these deprecation statements in the log, but the final backup showed no errors. Today the backup says it has two errors, but I don’t see any errors in the log (but still the deprecation statements). The mystery deepens, and I have no confidence that I have a valid backup.

Running WP 6.1.1, and PHP 8.1

Apparently this has fallen through the cracks. The issue persists, but support is quiet about it. ??

I hope this gets addressed, as I’ve had really good experience with this plugin, and hope to continue with it.

My log looks essentially identical to the Andy H. log. Thank you Andy for figuring out a solution. Hopefully the WordPress folks will respond to this with a code fix. As a “non-coder” type, I’m reluctant to make these changes myself. Of course, I could back up the required files so if things go south on me, I could restore them to the originals. ??

• This reply was modified 1 year, 8 months ago by ElsieBlogger.

I changed to PHP 8.1 from 8 a few days ago. Today my backup showed no warnings, but had dozens of these deprecation statements in the log. I’m wondering if the backup itself is valid.

I did my backup today and there were no warnings. However there were dozens of log entries, all starting with the “Deprecated: Return type of Requests_ (a long descriptive string here)” statement. I had changed from PHP 8 to 8.1 several days ago at the recommendation of my web host. I’m wondering if that is the cause of all these log entries.

@bruberries

Thanks for letting us know what’s going on. It’s strange though that these emails sent to MailPoet are bouncing. Indeed, I’d prefer to have the option to suppress these automatic mailings. It’s unnerving to have software sending emails without your knowledge!

I’m having this same issue. MailPoet sent this test email several weeks back, and I couldn’t determine why. Now today it has sent out two more (I upgraded to version 4.3.0 a day or so ago). The only reason I know about these emails is because they were rejected by [email protected] and returned to my website sending address. The return contained this info:

The following address failed:

[email protected] SMTP error from remote server for RCPT TO command, host: mx1.dfw.automattic.com (192.0.84.151) reason: 550 5.1.1 <[email protected]>: Recipient address rejected: User unknown in local recipient table

What’s up with this?