Posted 10 months ago #
Hi
I'm running Backup Buddy by the guys over at iThemes. When I have W3 Total Cache running Backup Buddy doesn't work. It seems that there is a setting in W3 Total Cache that prevents the backup from happening. When I deactivate your plugin all works. Have you heard of this before? Any way to fix it so both work in harmony?
Let me know!
Thanks
Posted 10 months ago #
How do I "whitelist" wp-cron.php file or any setting that would block/interfere with HTTP Loopback Connections?
Posted 10 months ago #
Does BB work when Page Cache is disabled? Do you know which settings more exactly causes BB to fail? W3TC does not cache when wp cron is run if BB uses other methods this could be an issue and best discussed with iThemes.
Whitelistning of pages/files is done under Page Cache->Never cache the following pages box.
Posted 10 months ago #
Hey Fredrick,
BB does work when W3TC is deactivated. I want to be able to use both though. See my dilemma?
I have the wp-cron.php never caching and it still doesn't work.
Posted 10 months ago #
Okay so I'm going to run a scheduled backup with Page Cache disabled.
Will let you know if it works.
Posted 10 months ago #
Okay so disabling the Page Cache didn't fix the scheduled backup issue.
Are you getting any kind of error from BackupBuddy? What happens when you try to make a backup?
We are running into a similar issue over here, but we are also having issues with getting W3 Total Cache working. Is W3 Total Cache working correctly for you?
For some reason this morning everything was working fine with no errors at all. I wish we could provide a fix here, but unfortunately we don't really know what happened.
We think it might have had something to do with cron not working correctly, but we aren't sure. Good luck figuring it out.
Posted 10 months ago #
what version of backup buddy?
We are using BackupBuddy version 3.0.40.
Posted 8 months ago #
I'm using BackupBuddy together with W3 Total Cache and did not had any problems.
What you may do, is to exclude the W3TC cache folder (/wp-content/w3tc/) from backup. You can do this in BackupBuddy --> Settings --> Directory Exclusions.
If you do not use real cron and your site has low traffic during the scheduled backup times, I've experienced problems with BackupBuddy. You can see the scheduled events in the cron todo list from BackupBuddy --> Server Information --> Scheduled Tasks for WordPress (CRON).
I've spend a lot of time with these two plugins during the last two month and didn't see any interference.
Posted 4 months ago #
I've got both BackupBuddy and W3 Total Cache installed on ~ 30 WordPress sites. Until a few days ago, I never had any conflict issues. Now I have the above described problem with BackupBuddy only able to run when W3 Total Cache is deactivated on some but not all of my WordPress sites. I have the latest versions of both plug-ins. When W3 Total Cache is activated, Backup Buddy goes into an endless "Ping. Waiting for server ..." loop and never begins to build the backup archive.
I tried JochenT's suggestion of excluding the /wp-content/w3tc/ directory from backup but that didn't help.
Thanks for any suggestions.
Posted 4 months ago #
Have you changed anything with your cron configuration on this servers? If using real cron you may set in config.php
/**
* Don't use poormans cron, use a real cron
* Real cron can be implemented with a HTTP call to wp-cron.php in the
* crontab of your server. (e.g. http://www.example.com/wp-cron.php).
* In crontab you may add this line (looks every three minutes for
* scheduled cron tasks):
* */3 * * * * wget --tries=3 --timeout=90 -O ~/wpcron-out.html http://www.example.com/wp-cron.php >>~/wpcron-log 2>&1
* If no access to cronjobs is available also a request from spezialized
* websites is possible:
* http://www.dscripts.net/2010/07/27/run-cron-from-external-server-when-you-dont-have-cron-support/.
*/
define('DISABLE_WP_CRON', true);
/**
* Configure LoopBack for BackupBuddy
* I disable this setting when using a real cron. But I can not remember
* if this was due to a conflict with real cron.
* The disadvantage with real cron enabled, ALTERNATE_WP_CRON disabled and
* loopback is needed are manually backups. As the backups are executed in
* several steps each step has to wait for the next wp-cron.php request
* (in the case of this example this is 3 minutes). During this time you
* get the message "Ping. Waiting for server ...".
* Also BackupBuddy puts out a warning message about waiting to long at
* one of the final backup steps. You may ignore this warning.
*/
// define('ALTERNATE_WP_CRON', true); // needed if loopback is not enabled
Posted 4 months ago #
JochenT, thanks, unfortunately not, no cron configuration changes ever.
My hosting company doesn't allow cron tasks so I've always relied on WordPress' pseudo cron. It's always worked fine until now.
I tried increasing my memory limit to 64M to see if this was memory related but that didn't help.
Posted 4 months ago #
I notice on sites not yet upgraded to W3TC version 0.9.2.5 that I can run BackupBuddy without issue (in this case using W3TC version 0.9.2.4).
I also have an issue with Gravity Forms in version 0.9.2.5 that does not occur in version 0.9.2.4. I posted info on this separately.
Posted 4 months ago #
Same here: After the most recent update of W3 Total Cache to Version 0.9.2.5, BackupBuddy now runs into an infinite loop (Ping-Error) when performing a backup.
Time Elapsed Memory Message
16:51:29 2.58sec 67.12MB BackupBuddy v3.1.8 using WordPress v3.5 on Linux.
16:51:29 2.58sec 67.12MB Führe Backup-Vorbereitung aus.
16:51:29 2.58sec 67.12MB Modus: Vollständiges Backup.
16:51:29 2.58sec 67.12MB Backup serial generated: <code>nc7tjpdzmt</code>.
16:51:29 2.58sec 67.12MB Resetting statistics for last backup time and number of edits since last backup.
16:51:29 2.58sec 67.12MB mysqlbuddy: Calculating tables to backup. Next three lines:
16:51:29 2.58sec 67.12MB Base dump mode (before inclusions/exclusions): <code>all</code>.
16:51:29 2.59sec 67.12MB mysqlbuddy: Base tables (38 tables): <code>wp_blc_filters,wp_blc_instances,wp_blc_links,wp_blc_synch,wp_commentmeta,wp_comments,wp_hl_twitter_replies,wp_hl_twitter_tweets,wp_hl_twitter_users,wp_links,wp_lockdowns,wp_login_fails,wp_options,wp_popularpostsdata,wp_popularpostsdatacache,wp_postmeta,wp_posts,wp_rg_form,wp_rg_form_meta,wp_rg_form_view,wp_rg_lead,wp_rg_lead_detail,wp_rg_lead_detail_long,wp_rg_lead_meta,wp_rg_lead_notes,wp_sjsm,wp_term_relationships,wp_term_taxonomy,wp_terms,wp_tpcmem_checkpoints,wp_tpcmem_log,wp_tracking_clicks,wp_tracking_links,wp_usermeta,wp_users,wp_vslider,wp_yarpp_keyword_cache,wp_yarpp_related_cache</code>
16:51:29 2.59sec 67.12MB mysqlbuddy: After addition (38 tables): <code>wp_blc_filters,wp_blc_instances,wp_blc_links,wp_blc_synch,wp_commentmeta,wp_comments,wp_hl_twitter_replies,wp_hl_twitter_tweets,wp_hl_twitter_users,wp_links,wp_lockdowns,wp_login_fails,wp_options,wp_popularpostsdata,wp_popularpostsdatacache,wp_postmeta,wp_posts,wp_rg_form,wp_rg_form_meta,wp_rg_form_view,wp_rg_lead,wp_rg_lead_detail,wp_rg_lead_detail_long,wp_rg_lead_meta,wp_rg_lead_notes,wp_sjsm,wp_term_relationships,wp_term_taxonomy,wp_terms,wp_tpcmem_checkpoints,wp_tpcmem_log,wp_tracking_clicks,wp_tracking_links,wp_usermeta,wp_users,wp_vslider,wp_yarpp_keyword_cache,wp_yarpp_related_cache</code>
16:51:29 2.59sec 67.12MB mysqlbuddy: After exclusion (38 tables): <code>wp_blc_filters,wp_blc_instances,wp_blc_links,wp_blc_synch,wp_commentmeta,wp_comments,wp_hl_twitter_replies,wp_hl_twitter_tweets,wp_hl_twitter_users,wp_links,wp_lockdowns,wp_login_fails,wp_options,wp_popularpostsdata,wp_popularpostsdatacache,wp_postmeta,wp_posts,wp_rg_form,wp_rg_form_meta,wp_rg_form_view,wp_rg_lead,wp_rg_lead_detail,wp_rg_lead_detail_long,wp_rg_lead_meta,wp_rg_lead_notes,wp_sjsm,wp_term_relationships,wp_term_taxonomy,wp_terms,wp_tpcmem_checkpoints,wp_tpcmem_log,wp_tracking_clicks,wp_tracking_links,wp_usermeta,wp_users,wp_vslider,wp_yarpp_keyword_cache,wp_yarpp_related_cache</code>
16:51:29 2.59sec 67.12MB Breaking out tables DISABLED based on settings.
16:51:29 2.59sec 67.45MB Erstelle DAT ( Daten) Datei mit dem Abbild der Seite & den Backup-Informationen
16:51:29 2.59sec 67.45MB wp-config.php found in normal location.
16:51:29 2.59sec 67.45MB Erstellung einer DAT(Daten)-Datei abgeschlossen.
16:51:29 2.59sec 67.45MB Generating ImportBuddy tool to include in backup archive: <code>/var/www/virtual/henning/e-vance.net/wp-content/uploads/backupbuddy_temp/nc7tjpdzmt/importbuddy.php</code>.
16:51:29 2.59sec 67.45MB Attempted to increase maximum PHP runtime. Original: 30; New: 7200.
16:51:29 2.59sec 67.45MB Original PHP memory limit: 256; New: 256M.
16:51:29 2.60sec 67.45MB Error #9032: You have not set a password to generate the ImportBuddy script yet on the BackupBuddy Settings page. If you are creating a backup, the importbuddy.php restore script will not be included in the backup. You can download it from the Restore page. If you were trying to download ImportBuddy then you may have a plugin confict preventing the page from prompting you to enter a password.
16:51:29 2.60sec 67.45MB ImportBuddy generation complete.
16:51:29 2.60sec 67.79MB Backup-Vorbereitung abgeschlossen.
16:51:29 2.61sec 67.79MB Running in modern backup mode based on settings. Mode value: <code>2</code>. Trigger: <code>manual</code>.
16:51:29 2.61sec 67.79MB Scheduling Cron for <code>nc7tjpdzmt</code>.
16:51:29 2.61sec 67.79MB Loading DB kicker in case database has gone away.
16:51:29 2.61sec 67.79MB Datenbankserver Verbindungsstatus überprüft.
16:51:29 2.61sec 67.79MB Database seems to still be connected.
16:51:29 2.61sec 67.79MB Scheduling next step to run at <code>1357833089</code> with cron tag <code>pb_backupbuddy_process_backup</code> and serial arguments <code>nc7tjpdzmt</code>. If the backup stalls at this point check the Server Information page cron section to see if a step with these values is listed to determine if the problem is with scheduling the next step or the next step is scheduled but not running.
16:51:29 2.97sec 67.79MB Next step scheduled in cron.
16:51:32 0sec 0mb Ping. Waiting for server . . .
16:51:35 0sec 0mb Ping. Waiting for server . . .
16:51:39 0sec 0mb Ping. Waiting for server . . .
16:51:42 0sec 0mb Ping. Waiting for server . . .When I disable the W3 Total Cache plugin, things are back to normal again and everything is running smoothly. In the changelog on the Plugin-Page over at wordpress.org it says the update touches database caching to disk – I manually disabled my databse caching within W3 Total Cache, but this didn't help.
Another quote from a BackupBuddy User:
I hadn't experienced this issue until the latest update to W3 Total Cache was made due to an identified vulnerability.
Maybe this can be – more or less – be easily fixed, since one can compare the files from 0.9.2.4 and 0.9.2.5 and target the source of the error that way. I can upload a comparison if needed.
Please advise.
Thanks.
Posted 4 months ago #
I just now saw this. Different plugin, but same problem I am having:
https://wordpress.org/support/topic/scheduled-database-backups-no-longer-working?replies=18
Posted 4 months ago #
I would love to downgrade to version 0.9.2.4 which backed up fine and didn't have this infinite loop issue. Three questions:
1) Can version 0.9.2.4 be downloaded somewhere?
2) Are there any special downgrade instructions?
3) Are there any database or other compatibility issues in moving back?
Thanks.
Posted 4 months ago #
Let me tell you guys that I even have W3 Total Cache installed on my wordpress site & after adding this define('ALTERNATE_WP_CRON', true); in the wp-config file it gave me a backup in no time & stopped pinging excessively. However, I still kept getting the error at the back of my url like this:
http://shiftopinions.com/?doing_wp_cron=1358447319.5469269752502441406250
I am using GoDaddy. Godaddy has a cron job manager. Excellent. Awesome. Superb. However, I was extremely dis-appointed when I called GoDaddy support to enable loopbacks for the shared linux hosting server to which they replied in the negative. Bad. My bad.
However...
After reading what JochenT wrote here & then implementing exactly what he asked us to do, I'm absolutely delighted, astonished & ecstatic as I have successfully been able to resolve the issue. YES, the problem has been solved as far as the ?doing_wp_cron=1358447319.5469269752502441406250 problem is concerned.
I added:
*/3 * * * * wget --tries=3 --timeout=90 -O ~/wpcron-out.html http://www.shiftopinions.com/wp-cron.php >>~/wpcron-log 2>&1
* to the command field needed in the create cron job area.I chose every 5 minutes twice every hour which says: 5 minutes & then 35 minutes.
I added the following code below to wp-config.php file of my site which has backupbuddy plugin installed:
define('DISABLE_WP_CRON', true);
// define('ALTERNATE_WP_CRON', true); // needed if loopback is not enabledI'll just check whether backupbuddy is functioning well as far as the automation of backups is concerned.
My only concern now is to send backup files of over 10 MB to the email address I wish to which I think is something that needs a lookover into. If someone can help with this it will great.
Resources:
http://www.computerhope.com/unix/ucrontab.htm
http://www.activecampaign.com/help/setting-up-a-cron-job/
An Update:
The above task given to do by TJochen has resulted in my wordpress plugins getting upgraded slower than how they were. So for sure the speed has been slowed down by the real cron job it seems & the editing of the wp-config file by adding the "disable wp cron" as true & "enable alternate cron" as true. Not sure if that is the reason why the wordpress site's speed has slowed down while upgrading plugins.
"JochenT" is an absolutely special wordpress user, guy, person, human being & a generous giver. Absolutely. Awesome. Thanks a ton. Love.
Would appreciate if you would give a little more hand to helping us make our wordpress sites & blogs work better for all of us. Sincerely. Seriously I'd love you to add some more tips to make wordpress work efficiently for us.
Thanks.
Sincerely,
Ronak.
I had this all working, then I upgraded to the new cache plugin, nthen it broke, not I downgraded to the old cache plugin and it is still broken.
wpriley did you ever get it working after the downgrade? I actually did downgrade but it's still not working again for a schedualed or a manual backup. Something from the other w3Ttotal Cache install is left behind or something.
The minute I removed the plugin completely things worked fine. I was running 0.9.25 so I need to go back to a backup and see what version I had that was in fact working before the upgrade mess to the latest. total crap that this wonderful plugin breaks CRON
I was running 0.9.25 stable before this started so still not sure what is still broken when it gets re-installed.
Posted 2 months ago #
I'm the author of UpdraftPlus, another backup plugin, and have had several reports in the last few days of broken-ness, each of which was traced back to W3 Total Cache.
UpdraftPlus would save a transient, then a separate run would load it 5 minutes later - but it's not there; it's gone. Disabling W3 Total Cache has fixed such problems in each case.
So can ANYBODY determine what in W3TotalCache is preventing CRON from working? Seriously, they are not speaking up and it's frustrating. Can you as another plugin author debug the settings and see if there is tickbox or tweak someplace that gets CRON working again since you also rely on it?
I am sure once we find it ALL things broken with CRON like scheduled posts and backups wil again start working.
The W3TtotalCache people need to start speaking up and helping here!
Posted 2 months ago #
In the reports I had, cron runs were running, but transients saved 5 minutes earlier (with an expiry time of 9 hours) were not being found. One user indicated that turning off object/transient cacheing fixed his problem. I have not reproduced the problem myself.
I have 100% removed it, copying to a test server and I am going to re-install and try only having basic things enabled like CDN and see what happens. STILL it needs to be fixed by Frederick and team. I say start tweeting the #EpicFail of the plugin with CRON jobs INCLUDING scheduled posts as well. It's not just backups that fail now.
I have verified on a duplicate server that with NO W3TC plugin both backup and schedulaed posts run fine with the standard wp-cron setup.
Next is to re-install the plugin and see if I can figure out what the heck breaks it. Any other insights would be great but right now everything 100% WORKS before the install of the caching plugin.
Okay this is CRAP for real. I did the MOST BASIC of tests.
1) Installed the W3Total Cache Plugin
2) Network Enabled it
3) Made sure ALL settings were in fact disabled
Testing backups and schedualed posts = FAILED!
Disabled plugin (Kept it installed) - re-ran and all things PASSED
SO WTF? Just enabling this plugin alone with NO settings craps out the CRON jobs? That's completely fouled up!
Also did the same test disabling wp-cron and calling from a real CRON job with the same results. BUG!
You must log in to post.
