W3 Total Cache and Backup Buddy

How do I “whitelist” wp-cron.php file or any setting that would block/interfere with HTTP Loopback Connections?

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.

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.

Okay so I’m going to run a scheduled backup with Page Cache disabled.

Will let you know if it works.

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.

what version of backup buddy?

We are using BackupBuddy version 3.0.40.

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.

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.

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. https://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 https://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:
 * https://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

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.

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.

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 www.ads-software.com 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.