Loopbacks / zip on server / more …

/ SprUng, wordpress - more cheats / wpcli-tag / 45 minutes of reading

What are Loopbacks
WordPress’ simulated cron works by having the site connect back to itself via curl (or other available fallback connection method if curl in unavailable) to trigger actions to take place behind the scene. What are they? PHP needs to be able to use Curl to load your site via its public URL. For instance, if your site is http://myblog.com WordPress will access http://myblog.com/wp-cron.php via Curl. Basically the site connects back onto itself. If it is unable to do this then the simulated cron cannot function. A host may block these connections back to themselves intentionally or through misconfiguration. One known cause is a DNS problem on the server either due to misconfiguration or a recent DNS change not fully propagating to the site, resulting in the site attempting to connect back to its own URL but inadvertently connecting to the old site since DNS has not propagated fully yet. NOTE: This is NOT to be confused with the loopback ethernet device. Web hosts often misunderstand the HTTP loopback as meaning the loopback device. If it not related at all.

Symptoms
You receive a warning or error #9038 or a message indicating HTTP Loopbacks are not functioning, such as on the Backups page.
“Endless Ping” symptom
“Endless ping” usually happens before the second Scheduled Cron in your backup is run. You can see the number of times “Scheduled Cron” is mentioned in the Advanced Logs shown on the backup page to see if this is the case.

Loopbacks

Loopbacks

A loopback is when your own server or website tries to connect to it self.

WordPress uses his functionality to trigger scheduled posts, and other scheduled events that plugins or themes may introduce.

They are also used when making changes in the Plugin- or Theme-editor, by connecting back to the website and making sure that the changes made does not break your website.

Troubleshooting loopback issues

If you are having problems with scheduled posts or other timed events not running, or seeing Site Health warnings about loopbacks failing, you may want to troubleshoot these.

The most common cause of loopback failures is a plugin or theme conflict, you should start by following the normal troubleshooting steps:

Common troubleshooting steps

  • Deactivating all plugins (yes, all) to see if this resolves the problem. If this works, re-activate the plugins one by one until you find the problematic plugin(s). If you can’t get into your admin dashboard, try resetting the plugins folder by SFTP/FTP or PhpMyAdmin (read “How to deactivate all plugins when you can’t log in to wp-admin” if you need help). Sometimes, an apparently inactive plugin can still cause problems. Also remember to deactivate any plugins in the mu-plugins folder. The easiest way is to rename that folder to mu-plugins-old
  • Switching to the Twenty Nineteen theme to rule out any theme-specific problems. If you can’t log in to change themes, you can remove the theme folders via SFTP/FTP so the only one is twentytwenty. That will force your site to use it.
  • If you can install plugins, install “Health Check”: wordpress.org/plugins/health-check. On the troubleshooting tab, you can click the button to disable all plugins and change the theme for you, while you’re still logged in, without affecting normal visitors to your site.
  • If your server does not support command line Zip then BackupBuddy will fall back into a compatibility mode to help aid you in creating a backup. This mode is significantly slower and less reliable. It is not intended for persistent use and is provided to aid you in backing up in poor hosting environments, for instance to move to another host.
  • Directory exclusion is not available in this mode. Even existing backups will be backed up, resulting in rapidly growing backup file sizes.
  • If you are running on a Windows server (or developing locally, ie on Xampp) you will need to install the Windows zip.exe executable (we do not provide support for setting this up, though the readme.txt in the file does help).
  • Solutions:
    • If you are running CentOS on a VPS or similar type of server then running the command 
      yum install zip

      as root will install the zip package and any dependencies. This may also apply to other environments using rpm packages and the yum package manager front-end. The yum manager can also be used to query installed packages and update packages, etc. If you have any issues with this then please consult your host support for additional assistance.

    • for Debian-based Linux (including Ubuntu) run the following at the command line: 
      sudo apt-get install zip unzip
    • If you are operating a Media Temple DV server then please make sure you have the Developer Tools installed as this contains the package necessary to provide zip capability.
    • If your server is configured to disable access to the PHP exec() function and if you have access to configure your server then remove any blocking of the PHP exec() function in php.ini and configure permissions to allow running the Linux command line function `zip`.
    • If your server is operating in safe_mode then either turn safe_mode off (if you can) or make sure that the safe_mode_exec_dir configuration parameter includes the directory which contains the `zip` command (please consult your host support for this information)
    • Ask your host to enable access to the Linux command line Zip command via PHP’s exec() function.
      • Example message to send to your host:

Frequently-Seen Support Issues

Backing Up

HTTP Loopback Connections Disabled

What are Loopbacks

WordPress’ simulated cron works by having the site connect back to itself via curl (or other available fallback connection method if curl in unavailable) to trigger actions to take place behind the scene. What are they? PHP needs to be able to use Curl to load your site via its public URL. For instance, if your site is http://myblog.com WordPress will access http://myblog.com/wp-cron.php via Curl. Basically the site connects back onto itself. If it is unable to do this then the simulated cron cannot function. A host may block these connections back to themselves intentionally or through misconfiguration. One known cause is a DNS problem on the server either due to misconfiguration or a recent DNS change not fully propagating to the site, resulting in the site attempting to connect back to its own URL but inadvertently connecting to the old site since DNS has not propagated fully yet. NOTE: This is NOT to be confused with the loopback ethernet device. Web hosts often misunderstand the HTTP loopback as meaning the loopback device. If it not related at all.

Symptoms

  • You receive a warning or error #9038 or a message indicating HTTP Loopbacks are not functioning, such as on the Backups page.
  • “Endless Ping” symptom
      “Endless ping” usually happens before the second Scheduled Cron in your backup is run. You can see the number of times “Scheduled Cron” is mentioned in the Advanced Logs shown on the backup page to see if this is the case.

    • Backing up with BackupBuddy v2.1.8...
20:35:15: Setting greedy script limits.
20:35:15: Set memory limit to 256M. Previous value < 256M.
20:35:15: Finished greedy script limits.
20:35:15: Full backup mode.
20:35:15: Performing pre-backup procedures.
20:35:15: Backup serial: pyisomo736
20:35:15: Creating import data file.
20:35:15: Finished creating import data file.
20:35:15: Finished pre-backup procedures.
20:35:15: Scheduling Cron for pyisomo736.
1307910918|ping
1307910922|ping
1307910926|ping

Troubleshooting

  • Temporarily disable all other WordPress plugins to rule out another plugin causing problems. This is a quick way to narrow down the problem. After seeing if this helps you can re-enable all the recent plugins by clicking on “Recently Active Plugins” on the plugins page.
  • Verify the “Loopback Domain & IP” listed on the “Server Tools” page is correct and pointing to the expected URL and IP address, especially if you recently changed DNS settings.
    • Deactivate all other plugins and see if it works to rule out another plugin conflicting, if so then make sure you don’t have a plugin that may apply a maintenance mode
      • This is because maintenance mode plugins rarely, if ever, take into account WordPress scheduling crons
  • Are you password protecting all or a portion of your site by using htpasswd (eg in the htaccess)? Some plugins may enable this for additional security but it often breaks the WordPress cron. Workaround:
  • Make sure you have not set either or both of the defines in your wp-config.php file: 
    define('DISABLE_WP_CRON', true);

    and/or:

    define('WP_CRON_LOCK_TIMEOUT', 120);

    https://codex.wordpress.org/Editing_wp-config.php

Workaround if other solutions fail

If you cannot resolve this situation (such as the host being unwilling to unblock these) you a workaround is to enable the WordPress Alternate Cron setting in your wp-config.php file as a workaround.

    • Add define(‘ALTERNATE_WP_CRON’, true); to your wp-config.php
      • Open your wp-config.php in a text editor. This file is located in the root of your site.
      • Add the line somewhere between the first ( <?php ) and last line of the file (but before the line that says /* That’s all, stop editing! Happy blogging. */)
      • define('ALTERNATE_WP_CRON', true);

See Also

On Linux Systems

On Linux systems, be sure you have your /etc/hosts file correctly setup as problems here can cause loopback not to work.

Compatibility Mode

  • If your server does not support command line Zip then BackupBuddy will fall back into a compatibility mode to help aid you in creating a backup. This mode is significantly slower and less reliable. It is not intended for persistent use and is provided to aid you in backing up in poor hosting environments, for instance to move to another host.
  • Directory exclusion is not available in this mode. Even existing backups will be backed up, resulting in rapidly growing backup file sizes.
  • If you are running on a Windows server (or developing locally, ie on Xampp) you will need to install the Windows zip.exe executable (we do not provide support for setting this up, though the readme.txt in the file does help).
  • Solutions:
    • If you are running CentOS on a VPS or similar type of server then running the command 
      yum install zip

      as root will install the zip package and any dependencies. This may also apply to other environments using rpm packages and the yum package manager front-end. The yum manager can also be used to query installed packages and update packages, etc. If you have any issues with this then please consult your host support for additional assistance.

    • for Debian-based Linux (including Ubuntu) run the following at the command line: 
      sudo apt-get install zip unzip
    • If you are operating a Media Temple DV server then please make sure you have the Developer Tools installed as this contains the package necessary to provide zip capability.
    • If your server is configured to disable access to the PHP exec() function and if you have access to configure your server then remove any blocking of the PHP exec() function in php.ini and configure permissions to allow running the Linux command line function `zip`.
    • If your server is operating in safe_mode then either turn safe_mode off (if you can) or make sure that the safe_mode_exec_dir configuration parameter includes the directory which contains the `zip` command (please consult your host support for this information)
    • Ask your host to enable access to the Linux command line Zip command via PHP’s exec() function.
      • Example message to send to your host:
Dear Sir/Madam,

I am attempting to use the highly popular WordPress backup software, BackupBuddy by PluginBuddy.com.
BackupBuddy requires the ability to use the Linux command line Zip command via PHP's exec() function.
BackupBuddy is reporting that it is unable to access this functionality on my server hosting environment.
Please enable this functionality for me so that I may use this backup solution in combination with your hosting.
These are commonly available features of many popular hosting providers such as HostGator, Godaddy, Site5, etc so it is
not unreasonable to request it nor is it a security risk IF it is properly configured.

Please verify access to the following features:
1) PHP's exec() function.
2) Permission to run Linux's `zip` command.
3) The directory containing the `zip` command is included in the PATH environment variable
available to the process executing the command passed to the exec() function 

Thank you for your time and consideration.
    • Also possible that even though that zip via exec() is enabled it still may not work if host does not have zip’s path location currently as a part of PATH (or the path is not one of the “well known” locations that more recent versions of BackupBuddy with search). The below code is an example of how to add the directory of the zip executable to PATH after you ask your host where it is being kept and whether this is the correct way to do it on their servers or if not what is the preferred way (please note the colon that precedes the path being added): 
      • putenv( "PATH=" . getenv( 'PATH' ) . ":directory zip exe is" );
      • The line has to be added anywhere in the wp-config.php file after the first line ( <?php ) but at least before the line that says /* That’s all, stop editing! Happy Blogging */
    • If all of the above are either impossible or unsuccessful and you absolutely must have the native zip command capability then your only option is to move your site to an alternative server or host that provides this capability.

Unable to create directory /public_html/yourdomain/wp-content/uploads/2012/03. Is its parent directory writable by the server?

Happens when trying to activate/install BackupBuddy.

  • Check in WordPress admin Settings->Media under the Uploading Files heading and see if there is anything there. Generally if you are using the default location for wp-content they would be left blank.
  • Also make sure there are not any references to another site in the wp-config.php file, some 1-click WordPress installers add definitions in there other servers don’t like

Warning: exec() has been disabled for security reasons in /www/wp-content/plugins/backupbuddy/lib/zip/zip.php on line ###

  • exec() is disabled somewhere in PHP configuration. Ask the host to correct this or use cPanel to edit PHP settings to enable it if possible. See ‘Fallback to Compatibility Mode’ above.

Warning: mysql_query() [function.mysql-query]: Unable to save result set in /www/wp-content/plugins/backupbuddy/backupbuddy.php on line 1673

.htaaccess 404 / Addhandler Warning

  • Some hosts use a line at the top of the .htaccess file in the root of the site to configure some server settings such as enabling PHP support for that site. When used on a host that does not need this it can break PHP or other functionality. When migrating to a new site this can break the migration process. This often causes URLs to give 404 Not Found errors after migrating/restoring.
  • Solution:
    • Remove the Addhandler line from the .htaccess file before backup or open the backup ZIP archive and remove the line within the file within the ZIP.

Backup marked as bad

  • Backups are verified by verifying the following criteria:
    • The ZIP file is not corrupt and is openable.
    • The database (.sql) file exists.
    • The wp-config.php file.
    • The backupbuddy_dat.php file.
  • Potential causes:
    • The backup timed out and did not complete within the PHP maximum runtime (usually 30 seconds)
      • Solution: Reduce the backup size by deleting files or excluding one or more directories. You may use the `Server Information` page’s Directory Size browser to find large directories/files.
    • Your hosting account does not have enough free space available.
    • You may have the backupbuddy_temp directory excluded.

Database backup succeeds, full fails

  • This is almost exclusively due to any single step of the backup process not completing within the maximum PHP runtime (usually 30 seconds).
  • If you are in compatibility mode then backups are significantly slower and less likely to complete in time.
  • Solution:
    • Ask your host to enable command line ZIP via exec() if you are in compatibility mode.
    • Reduce the size of your backups by deleting files or excluding large directories.

Directories not being excluded

  • Directories are not excluded if BackupBuddy is being forced to fall into compatibility mode. This is expected behavior. This happens if command line Zip is unavailable via the PHP exec() function.
  • Solutions:
    • Contact your host and ask them if they can enable command line ZIP via exec() if using Linux. For Windows servers a zip.exe file is available by downloading it from the `Getting Started` page of BackupBuddy when running on a Windows host.
    • Continue using compatibility mode. If you do this you will not be able to exclude directories, including the backups directory. Because of this even backups will be backed up. We recommend not storing any backups locally in this case as your backup file sizes will increase exponentially.

Tempory files in directories/root

  • BackupBuddy creates several temporary files within the directory `/wp-content/uploads/backupbuddy_temp/` while generating a backup. Some of these may remain temporarily after backups complete though most are cleaned up immediately. BackupBuddy will automatically clean up any remaining temporary files within 12 hours. This is an automated process.
  • While in compatibility mode large sites can create temporary .gz files in the site root. Sometimes these may be left behind and require manual cleanup at this time. This is uncommon and is a result of not having command line ZIP via exec() available. Ask your host to enable this.
  • Solution:
    • Wait ~12 hours or delete the file(s) manually.

Backups Time Out / Marked as Bad

  • Backup file size is too large so it takes too many resources or too much time to finish so the process is killed.
  • The maximum PHP runtime is typically 30 seconds so backups must finish within this time period.
  • Try reducing backup size, excluding directories, disabling compression to speed up zip file generation, or getting host to enable native zip compression if not already enabled.
  • Backup completed but backup ZIP is incomplete / bad: exec() shares the maximum allowed memory usage with PHP. If this memory limit is met the exec() / proc() will be killed and return to PHP. The symptoms of this are a bad / incomplete ZIP file despite the backup fully completing successfully. Try increasing `memory_limit` to a larger size.
    •   exec() proc()
      Maximum PHP Runtime Timeout Zip file size stops increasing. Zip file size stops increasing
      Memory Limit Hit Zip creation completed but ZIP file
      incomplete & marked as bad      		 Zip file size stops increasing.

Zip File Creation Dies at 2GB

  • The limit of some file systems on a 32bit server can create a file is 2GB.
    • Ask host to user a better file system that allows for the creation and handling of files bigger than 2GB.
      • Large File Systems (LFS) don’t technically have limits on how big they can support, they are designed to expand.
    • Alternatively, you could exclude directories in BackupBuddy’s Settings page to get the backup less than 2 GB.
      BackupBuddy -> Server Tools -> Site Size Maps -> Display Directory Size Listing
      That button shows where space is being used on the site and total site size to help with finding exclusion places and if any spot is using more space than expected (shows usage with and without backup exclusions taken into account).
      • Then you can exclude them here:
        BackupBuddy -> Settings -> General Settings -> File & Directory Defaults ->
        Things you might be able to exclude are any directories in the root of your install like a /stats/, /logs/, /errors/, or any directory that your host may have placed there or anything else that is not part of a standard WordPress install. Also any /cache/ directories that might be in your /wp-content/ directory as they are not usually needed in a backup because they will be rebuilt on a restore/migration. Also, if you’ve ever used any other backup plugin, please make sure that you are not making backups of other backups as that is somewhat redundant and the size of the backup will get incrementally larger with each backup attempt.
    • Or, if you have Stash space available, you can use Stash Live. As our Stash servers do not have this limitation.

Zip File Creation Dies at ~4GB

  • On a 32bit server the limit for Zip Archive is about 4GB.
    • Ask the host to upgrade to 64bit.
    • The host may be able to use better configurations or software for the server to up this while staying on 32bit though I am unsure on the details.
    • Alternatively, you could exclude directories in BackupBuddy’s Settings page to get the backup less than 4 GB.
      BackupBuddy -> Server Tools -> Site Size Maps -> Display Directory Size Listing
      That button shows where space is being used on the site and total site size to help with finding exclusion places and if any spot is using more space than expected (shows usage with and without backup exclusions taken into account).
      • Then you can exclude them here:
        BackupBuddy -> Settings -> General Settings -> File & Directory Defaults ->
        Things you might be able to exclude are any directories in the root of your install like a /stats/, /logs/, /errors/, or any directory that your host may have placed there or anything else that is not part of a standard WordPress install. Also any /cache/ directories that might be in your /wp-content/ directory as they are not usually needed in a backup because they will be rebuilt on a restore/migration. Also, if you’ve ever used any other backup plugin, please make sure that you are not making backups of other backups as that is somewhat redundant and the size of the backup will get incrementally larger with each backup attempt.
    • Or, if you have Stash space available, you can use Stash Live. As our Stash servers do not have this limitation.

Remote Transfers Fail

  • Login credentials are wrong. Test them to be sure that they have not changed. This is exceedingly common.
  • The path entered is incorrect or the directory has not been created. BackupBuddy requires the path/bucket to already exist in some cases.
  • Some hosts block outgoing connections. Try another remote destination if possible. Most remote destinations transfer over the HTTP port 80.
    • Amazon S3: port 80
    • Dropbox: port 80
    • Rackspace Cloud: port 80
    • FTP: port 21 (unless overridden)
    • Email: port 25 (if using external mail server)

Scheduled Events Fail to Trigger/Using Real Cron to Trigger

  • The scheduled date is wrong and has not passed.
  • Not enough visitors are visiting to trigger the schedule. Someone must visit any page on the WordPress site on or after the scheduled time for the event to occur. If no one visits during the time-frame then the event may be missed or occur at an unscheduled time.
  • The backup is failing. Test manual backups.

Files not being sent remotely

  • Files may fail remote sending for two possible reasons:
    • Files are too large to be transferred during the allotted PHP maximum runtime (usually 30 seconds). This is defined by your host.
    • Your host’s firewall is blocking outgoing HTTP connections/transfers.
    • The backup itself isn’t completing – verify that they work manually.
  • Solutions:
    • Reduce backup file size by deleting files or excluding directories.
    • Contact your host to increase PHP’s maximum allowed runtime.
    • Contact your host to unblock their firewall to allow outgoing HTTP connections.

Error 3382

Check out Error 3382 Details

Backup failure running function “ in email

  • Usually due to sending remote backups/databases failed due to permissions/path if ftp.
    • If sending the files by email, then files are probably too large for email(typically up to 10mb by email allowed by most places)

Endless Ping on second Scheduling Cron

  • Database may be too large, a lot of times this would be the wp_posts table.
    • See if you can lower the size of the database. The database size may be too big for your site/host/server to handle properly.
    • Use Server Info inside BackupBuddy ( BackupBuddy –> Server Info. ) to check where the most disk space is being used.
    • Increase available runtime. Your server may be timing out too quickly or having other issues related to not being allowed enough time to run scripts or specific commands.
    • What revision retention policy do you operate on the posts? It may be that you have a lot of revisions stored in the database that you could safely remove. The WordPress Codex gives some information on controlling revisions ( http://codex.wordpress.org/Editing_wp-config.php#Post_Revisions ) but I don’t think this acts retrospectively so you might need to find a method to prune any revisions you currently have.
    • Many plugins tend to leave a lot of data behind even after they have been de-activated and deleted in WordPress. This can result in very large BackupBuddy backups.
      • Example: A famous example of this is Statpress, which has been publicly known to leave massive amounts of data behind in the WordPress database tables even after the plugin was deactivated and deleted.
      • Solutions:
        • Use Server Info inside BackupBuddy ( BackupBuddy –> Server Info. ) to check where the most disk space is being used in different WordPress database tables.
        • Another way to see if such plugins may be affecting and causing your Backup to fail is to look through the database and see where the most db space is being used. If any table with a lot of data exists and is related to a plugin you no longer use, you can drop or empty that table with something like phpMyAdmin.
        • Also, if you have a “maintenance mode” plugin active, this can cause endless pinging as well. Deactivating this plugin solved the problem for some users.
      • Make full Database backup with BackupBuddy before making any Database changes. 😀
  • Related links:

Fatal Error: Call to undefined function home_url()

  • Full error will be Fatal Error: Call to undefined function home_url() in /wp-content/plugins/backupbuddy/classes/backup.php on line x
    • BackupBuddy requires at least WordPress version 3.0, make sure you don’t have an older version of WordPress.

Parse Error, unexpected T_VARIABLE in …/backupbuddy.php on line xxx

  • Usually will come up during activation of BackupBuddy
    • Make sure you are using PHP5 and not PHP4.
    • If you are installing by downloading BackupBuddy, unzipping, and then using FTP the directory in the site plugins directory sometimes the configuration of the FTP transfer mode can cause issues. You can try deleting the existing plugin files with the plugin admin and then install through WordPress admin by going through Plugins -> Add New -> Upload -> and use the backupbuddy.zip file. Be sure to do this with a copy of backupbuddy.zip that has not been unzipped.
  • This error is shown when you click on the generated backed up files. There is no error shown on the Backup page or in the logs, yet clicking the backup links show a 404 error or result in you not being able to download them because the files don’t exist. This could be caused by several things. Mainly, this has been known to be caused by the following:
    • There is an Archive limit set on the BackupBuddy –> Settings page. If this is being exceeded, the extra archives will be deleted. Try setting this to something higher.
    • Set the total size limit ( max file size ) to a higher setting.
    • See if any other plugin may be causing the issue. Disable other plugins and try starting the backup process again.
    • Make sure you have the necessary permissions to the downloads folder where the file is being saved.
    • Check with host to make sure they don’t have an over-zealous security system or error in it
    • Make sure the Advanced Log file in BackupBuddy is not showing any errors. If it is, please file a ticket with our support team so that the error can be looked at.

Change backups folder/file permissions or verify it is writable

BackupBuddy needs the backups folder in your wp-content/uploads directory on your site to be writable so that BackupBuddy can easily create and modify backup and related files in that directory. If those permissions are not set up properly, either automatically or manually, you’ll run into the ” Unable to create backup storage directory ” or similar errors.

  • To verify and change any file or folder permissions:
    • Easily and quickly learn what permissions are and how to change them in the official WordPress File Permissions page
    • Ask your host to verify or do it for you.
    • Make sure your backups folder directory in wp-content/uploads is set to 755 (permission).
    • Make sure your wp-content/uploads folder and everything under/in it is set to 755 also (called recursive permissions OR changing permissions recursively).

Big backup files with both “Force Compatibility Mode” and PHP exec() function enabled

  • If PHP exec() function is enabled on your server AND you have “Force Compatibility Mode” setting enabled, you may run into backup file size issues. The compatibility mode does NOT support folder exclusions, and thus your backups may be very big.
  • Solution:
    • If your server has PHP exec() enabled, go into BackupBuddy –> Settings and disable “Force Compatibility Mode” option.

Dropbox Backups Not Arriving

Sometimes, backups sent to Dropbox never arrive (meaning they never show up) in Dropbox.

  • Possible reasons:
    • Due to the Dropbox API limits, each backup file has to be loaded into your server’s memory and then sent to Dropbox. Dropbox requires PHP oAuth. Because of that, your server may run out of the required memory to do other things at the same time. When your server does not have enough memory to do multiple things at once, it may take longer than usual to complete each task, and the Dropbox process may take longer than the allowed time in PHP maximum_execution_time. This will simply result in the Dropbox process to time out and cancel. Since the limitation is because Dropbox requires PHP oAuth, there is no current workaround other than more memory.
    • BackupBuddy can only transfer full backup files that can easily or be fully loaded into your server’s memory. So if your backup file size is 200mb BUT your server memory size is only 128mb, your server will not be able to handle such a backup transfer to Dropbox, even if Dropbox allows such a transfer. If a Dropbox transfer exceeds your server memory limits, the backup will definitely not be transferred properly or at all. This is a server limitation, usually on less powerful servers, that we’re trying to find a fix for.
    • Your server or site has file transfer or PHP script processing limits which is resulting in the transfer not finishing.
    • Your Dropbox connection settings are wrong.
    • Your server may not have enough memory to perform this transfer.
    • Your backup is around or larger than 300mb. Dropbox has a 300mb file size limitation when uploading files online via a file. Dropbox has a limitation of 300mb per file size upload limit when done via anything other than the Desktop dropbox client. This limitation is thus imposed on BackupBuddy also by Dropbox.
  • Solutions to try:
    • Make sure your Dropbox connection settings are right.
    • Delete your current Dropbox connection and then re-create the Dropbox connection. See if that works.
    • Most important and basic thing to try: wait 10 to 15 minutes for the backup to arrive before giving up. Dropbox uploads can be slow due to Dropbox itself. Dropbox has been known to show files even 30 minutes after a backup file was sent.
    • Ask your host to increase the PHP maximum_execution_time. This is usually 30 seconds. Try increasing it to something much higher temporarily to see if that makes any difference.
    • Ask your host if your server can get more allotted memory.
    • Ask your host to enable PHP error logging to a file that you can access.
      • What this does is create an entry, in a txt file on your server that your host can tell you the location of, every time there is a PHP related error or warning. When DropBox times out, this file can most probably give you an exact error message that you can tell your host to address or fix.
    • Try sending a smaller backup file OR simply a database backup file to Dropbox. You can also use the Exclude option to exclude folders and files you do not need or to test things. See if such smaller files arrive. If they do, your issue is definitely with the larger file sizes.
    • Try excluding certain folders from the backups via BackupBuddy –> Settings and then see if the smaller-than-before backup files get to Dropbox. Dropbox has a limit of 300mb per file size upload when uploading any file through any channel other than the desktop client. Therefore, this 300mb max size per each file limit is imposed by Dropbox on BackupBuddy also. Excluding unwanted folders can help reduce your backup file sizes.

Database SQL (MySql) file inside full backups

In full backups, the actual database is backed up also. To find this sql file, look for the following folder in your backup file after you have extracted/unzipped the backup zip file:

wp-content/uploads/backupbuddy_temp/ XXXXXXXX

The XXXXXXXX part in the above link will be a serial code that matches the one in the backup name. That is it will be the exact same as the last set of characters, after the date, in your backup file name.

For example, if your backup file name is:

backup-domain_com-2012_05_29- ukitenaifg .zip

then the folder inside a full backup where your database file is saved is

wp-content/uploads/backupbuddy_temp/ ukitenaifg

BackupBuddy Tab Missing in WordPress

  • If the BackupBuddy Tab is missing in your WordPress Admin area, there could be a few reasons for it:
    • MULTISITES: If you are activating BackupBuddy on a single site inside a Multisite instead of using the NETWORK ACTIVATE option, BackupBuddy options will be hidden on purpose for security reasons. You must use Network NETWORK ACTIVATE instead.
    • Make sure you have the line added into your wp-config.php file to have the multisite part enabled in BackupBuddy.
    • Try disabling other plugins which may be causing a conflict OR not allowing BackupBuddy tab to show up in WordPress admin area, even if direct links to such areas work.

Warning:xxxxxx: open_basedir restriction in effect. File(xxxxxxx) is not within allowed the path(s)….

  • Your server is configured to only allow scripts access to files in a certain directory. Your own files are not in this directory. This is a server configuration error (you should be able to access your own files) and your host should be able to fix it.
  • http://www.php.net/manual/en/ini.core.php#ini.open-basedir

Warning:xxxxx:Unable to Access …/wp-content/uploads/backupbuddy_backups/temp_test_xxxxxxx.zip in /wp-content/… on line X

  • Usually immediately followed by a Warning: Cannot modify header information – headers already sent
  • Happens most often when installing/activating BackupBuddy or after a migration.
  • Solution:
    • Make sure that the backupbuddy_backups folder does exist at /wp-content/uploads/, if it doesn’t then create it.
    • Also make sure permissions are set to 755 recursively for the /wp-content/uploads directory.
    • Logging into the WordPress admin and navigating around a few BackupBuddy pages can trigger it to create the folder also.
      • Setting permissions to 777 temporarily can let give it a chance to create it if it was having trouble doing so for some reason.

wp-cli support

  • To see currently available commands, use the wp-cli command:

wp help backupbuddy

  • At this time there is only one command, backup. For help on that including examples:

wp help backupbuddy backup

Restoring/Migrating

Importbuddy asking for an authentication password when it didn’t used to

Importbuddy did not used to have a mandatory password to be ran or downloaded. However, it does now as of version 2.2.33 of BackupBuddy.

If using an older file that you never set a password for that is now asking for a password then:

  • Set a password for importbuddy in BackupBuddy’s Settings page. Then download and use this new importbuddy.

No Next Step Button In Step 1

If the server info section of step 1 is keeping the page from finishing loading (aka: no “Next Step” button) then can go to this URL as a workaround:

  • ……./importbuddy.php?skip_serverinfo=true

Step 3 in import results in importbuddy.php file being downloaded when “Next Step” is clicked

This problem happens because the .htaccess file being imported conflicts with the way your new host/server/site, where you are importing to, runs and processes php files.

  • To fix it, try any of the following (keep going through the steps till you solve the problem – the Second step below should solve the problem completely)
    • First, make sure you have the latest version of BackupBuddy’s importbuddy.php (gotten from the download link available on the BackupBuddy main Backup page.)
    • Second, read this exact issue explained in detail on PluginBuddy http://pluginbuddy.com/site-migration-heaven-one/ That has detailed steps on how to solve this.
    • Third, AFTER you encounter the problem, since the importbuddy.php file already has extracted the files:
      • Rename the .htaccess file in the newly extracted folder/area to anything like .htaccess_backup
      • Restart the import process again.
      • This time, in the Advanced Tab, select the option to “Skip File Unzip”, since the files have already been extracted.
      • After the site has been restored, go into your Settings –> Permalinks area to simply save that page, without making any changes. That will recreate the necessary .htaccess file again for the newly imported file.
    • Make sure all file, folder and any other permissions are set properly before and after the backup and restore.
  • This is probably the SAME as the other issue of Importbuddy showing actual file contents instead of the next step

You should now be able to pass Step 3 without any issues.

Parse error : syntax error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ‘}’ in /…/importbuddy.php on line 7974 (or any line)

This error usually means that your site/server, where you are importing to, is running PHP4. BackupBuddy and importbuddy.php require at least PHP5 to function properly.

  • It’s usually easily fixable:
    • Make sure you are using PHP5 and not PHP4.
    • Change your PHP settings yourself to run PHP5.
    • Ask your host to make sure you’re running PHP5.

Extraction of zip files (unzipping) does not work

Sometimes your host or site setup may prevent importbuddy.php from extracting (unzipping) the backup file.

You can find two methods to solve this here:

https://ithemeshelp.zendesk.com/hc/en-us/articles/360004415873-How-to-Manually-Unzip-and-Restore-a-Backup

IMPORTANT: Make sure you choose “Skip zip file extraction”, under the “Advanced Configuration Options” tab on Step 1, to tell importbuddy.php to SKIP the extraction process. The import should work fine then while skipping the extraction process.

Old importbuddy overwriting on unzip

  • Possible Symptoms:
    • importbuddy behaves differently or stops functioning properly after the extraction step.
    • Weird errors are seen after the extraction step.
    • The importbuddy version at the bottom of importbuddy changes after the extraction step.
    • Error: “Error! The unzip process reported success but the backup data file, backupbuddy_dat.php was not found in the extracted files. The unzip process either failed (most likely) or the zip file is not a proper BackupBuddy backup.”
    • Error 9003.
  • Possible Solutions:
    • Open the backup ZIP and delete the importbuddy.php file within it.
    • Replace the importbuddy.php on your server after the extraction step but before moving forward further.

After import: The source site is now redirecting to the destination site (or vice versa):

  • This occurs if the new database settings were not entered during Step 3 of importbuddy.php. Because of this, both sites are now sharing the same database so one of them (usually source) is redirecting to the other (usually destination). importbuddy.php needs to be re-run inputting the source URL on Step 3 and using the source database settings. This will reconfigure the source database to use its proper URL. Next importbuddy.php needs to be run again inputting the destination URL on Step 3 with the NEW database settings for the new database. This way both sites will have their own database for their respective URLs.
  • importbuddy no longer overwrites existing WordPress databases by default so this issue is not as common as it used to be.

After import: WordPress Error: `You do not have sufficient permissions to access this page`

One or more of your database table prefixes did not get changed during migration. A fix is available here: http://www.tech-evangelist.com/2010/02/06/wordpress-error-sufficient-permissions/

Cannot Log-in and Keep Getting Redirected Back to Log-In Page

The migration completed successfully and the site is browse-able but when you try to log in you keep getting redirected back to the log-in page and the URL looks something like this:

http://wptest.local/wp-login.php?redirect_to=http%3A%2F%2Fwptest.local%2Fwp-admin%2F&reauth=1

This is a common WordPress related issue and not a result of BackupBuddy backup or restore/import. It is easily fixable, though, and happens mainly because of some plugin or custom edit somewhere in WordPress causing WordPress to keep redirecting to a specific url for admin login.

  • Solutions (try any of these to see if they work – make a backup of everything Or keep you BackupBuddy backup in case something goes wrong or you want to undo some changes you make below):
    • Edit W3 Total Cache settings to fix this, if you are using or have used W3 Total Cache. Please check in your wp-config.php for a line such as this: 
      define('COOKIE_DOMAIN', 'www.domain.com'); // Added by W3 Total Cache

      In order to be able to log-in please either delete the line; or comment out the line; or change the string ‘www.domain.com’ to false – note that false is not enclosed by quotes, e.g.,:

      define('COOKIE_DOMAIN', false); // Added by W3 Total Cache

      You will now be able to log-in and can then attend to updating this definition as required by your new site configuration. To read more about COOKIE_DOMAIN please visit: WordPress Codex – Cooke Domain

    • Make sure your wp-config.php files do NOT have any hard-coded SITE or WordPress URI that may be causing this issue.
    • Make sure there is no duplicate .htaccess file.
    • Make sure the existing .htaccess file does not contain anything related to the Site or WordPress URL that is causing the redirect.
    • Make sure the wp_options table does not have any OLD URLs which were NOT updated prior to the move.
    • Make sure you use the latest versions of BackupBuddy and importbuddy.php (even try importbuddy.php beta to see if that makes a difference)
    • Disable conflicting/all plugins by renaming the folder names of the individual plugins to something different.

Blank OR strange homepage/frontpage BUT admin area works perfectly

This usually happens when there is an existing and unwanted index.html, default.html or some other server default file already in the root of WordPress directory of your new restore/migrated site.

  • Solution:
    • Make sure your .htaccess file is not causing the issue.
    • Make sure you delete any extra index.html, default.html or any other server default file that is already in the root of the WordPress directory of your newly restored/migrated site.
    • Make sure your WordPress’s index.php file is correct. If not, you can always download the latest version from WordPress.org and use the index.php file from that download (with any changes you may have made to the existing index.php file) to replace the index.php already present in your site.
    • Make sure your theme’s index.php and other theme files contents and permissions are correct.
    • Make sure your theme settings in the WordPress admin section are correct.
    • Make sure the home URL got updated in the database.
      • It can also use RepairBuddy to verify home URL.

Most Common

  • The .htaccess file was not configured properly or was not writable so importbuddy didn’t update it.
    • Solution: Log in to the admin dashboard and navigate to: Settings -> Permalinks and click ‘Save Changes’. This regenerates your .htaccess entries correcting most problems.
  • To manually fix, edit the .htaccess file in a text editor following the format on the .htaccess page.
  • If getting this after a migration in which it redirected you to home page during the migration’s step 5
    • Cause: .htaccess file is causing redirections.
    • Solution:
      • 1) Redo import and pause after Step 2 (file extraction).
      • 2) After step 2 (but before continuing to step 3) delete the .htaccess file in the root of the site.
      • 3) Continue the import to completion
      • 4) Regenerate the .htaccess file in WordPress by going to Settings -> Permalinks -> and clicking to “Save Changes”
  • If using custom permalinks, try default ones to see if the issue is tied to the custom permalinks.
  • See WordPress’ official page on Fixing Permalinks for more solutions.

Users of XAMPP (Windows)

Some versions of XAMPP do not enable mod_rewrite by default (though it is compiled in Apache). To enable it — and thus enable WordPress to write the .htaccess file needed to create pretty permalinks — you must open apache/conf/httpd.conf and uncomment the line LoadModule rewrite_module modules/mod_rewrite.so (i.e., delete the hash/pound sign at the front of the line).

Users of WAMP (Windows)

Some versions of WAMP (all versions?) do not enable mod_rewrite or permit following SymLinks by default. To enable the required functionality navigate to the apache/conf/httpd.conf file, open with a text editor and uncomment the line LoadModule rewrite_module modules/mod_rewrite.so (i.e., delete the hash/pound sign at the front of the line). Then further down in the same file there is a section that starts with the line “Options FollowSymlinks”. Change the second line in that section from “AllowOverride none” to AllowOverride all. Save edited httpd.conf and restart all WAMP modules. Your permalinks should now work.

Users of Ubuntu + Apache

The packaged version of Apache that came down with apt-get lamp-server^ doesn’t enable mod_rewrite by default. This link is a step in the right direction , although you also might have to set the AllowOverride rules to “all” in /etc/apache2/sites-enabled/000-default. Also, after making those changes make sure to restart Apache. — In summary, the steps that helped me fix this problem were: 1) Enable mod_rewrite on Apache, 2) Restart Apache, 3) Rename .htaccess to .htaccess.bak (move it out of the way), 4) Regenerate the .htaccess file (as above) –> login to your admin dashboard and go to Settings -> Permalinks -> and click the “Save Changes” button.

500 Server Errors

  • .htaccess (click for details) file is invalid or contains unsupported directives. Often an “AddHandler” line exists from the source server that is not supported on the new destination server.
    • Regenerating the .htaccess file can solve. To do this login to your admin dashboard and go to Settings -> Permalinks -> and click the “Save Changes” button.
      • Note: You don’t have to actually make any changes on the page to regenerate the .htaccess in this manner by clicking to “Save Changes”.
    • Optionally manually edit the .htaccess file in a text editor following the format on the .htaccess page.
  • Invalid file permissions such as being too restrictive OR too open. Some servers throw a 500 error if permissions are set to 777 to prevent accidental unauthorized access.
    • If permissions are currently set to 777 try changing them to 644 recursively on the site.
  • PHP is not functioning or enabled for the site. Check with basic phpinfo() .
  • A 404 error is occurring but the server is not set up correctly to return a 404

.htaccess being overwritten on unzip

  • Symptoms:
    • PHP stops properly functions in importbuddy.php after the extraction step.
    • Weird errors are seen after the extraction step.
  • Solution:
    • Open the backup ZIP and delete the .htaccess file within it, can be done before migrating.
      • Can also delete the .htaccess file in directory after step 2

The backup zip file is not found

  • The zip file has been renamed to a non-BackupBuddy format.
  • The zip file permissions are wrong. Ex: Not readable.
  • The zip file is not in the same directory as importbuddy.php.
  • The zip file has not finished uploading or was interrupted in transit. If BackupBuddy was used to send it try manually uploading.

backupbuddy_dat.php OR db_1.sql was not found after extraction

  • You may be using an older version of importbuddy.php not compatible with your backup version. Try upgrading your importbuddy.php to the version in the latest BackupBuddy.
  • You may have renamed your backup ZIP file. BackupBuddy depends on the naming format to determine where some data in the backup ZIP is stored. Rename your backup back to its original name.
  • Your backup may be corrupt. Try manually unzipping to verify it extracts properly.
  • If using the Safari browser to download the backup file, by default Safari automatically unzips downloaded zip files (it’s not specific to BackupBuddy, it does it for any zip file and also has automatic treatments for other files types such as PDF files). If you right-click on a zip file download link you will get a context menu, select the “Download Linked File” item and Safari will download the file without applying any automatic treatment.
  • Please confirm that the DAT file is there. The expected location of the backupbuddy_dat.php file is inside an actual full backup at /wp-content/uploads/backupbuddy_temp/xxxxxx/backupbuddy_dat.php. Where the xxxxxx will be a folder with the serial code name that matches the one in the name of the backup. You may have to extract the zipped backup file to check. 
  • If you’re using WinSCP (FTP client) to transfer files to the server, try setting the Transfer Mode to Binary mode instead of Text (ASCII) mode if not already.
    https://winscp.net/eng/docs/transfer_mode

SQL error near WH

  • It is because the table does not have a mysql primary key or unique index
    • If you have Gravity Forms and the problem is in _rg_form_meta then upgrade Gravity Forms to version 1.6+

Restoring database times out

  • You can try reducing the size of that database.
    • Checking for extra large tables you don’t need (such as deleted plugins leaving data behind).
    • What revision retention policy do you operate on the posts? It may be that you have a lot of revisions stored in the database that you could safely remove. The WordPress Codex gives some information on controlling revisions ( http://codex.wordpress.org/Editing_wp-config.php#Post_Revisions ) but this may not act retrospectively so you might need to find a method to prune any revisions you currently have.
  • Seeing if host will increase memory limit and runtime can help as well.
  • In ImportBuddy’s Step 3 Advanced Options you can try lowering the max execution time (yes lower) to see if that helps to force chunking more frequently (the option is “Maximum time per chunk when interacting with database”). You can also exclude any tables you think are being problematic.
  • In Step 3 Advanced Options there is the option for “Database Method Strategy”. Try setting that to “Commandline” instead of “PHP-based”. If your host allows accessing the command line option via a PHP script.

Extracting ZIP times out / hangs

  • Unzipping was not able to complete due to the unzipping process taking longer than the maximum PHP allowed runtime (usually 30 seconds).
  • Solutions:
    • Manual Unzip Process:
      • Manually extract the ZIP file on your computer then upload the files to the server.
      • Restart the importbuddy.php Import process, selecting `Skip Zip Extraction` from the advanced options slide-down.
    • Or ask your host to increase the maximum PHP runtime beyond its current limit.

Defined URL in wp-config.php

  • Symptoms:
    • URL does not appear to update after migration.
    • Links 404 after migration and you verified that you entered the correct URL to migrate to.
    • Links can also redirect to old site at the defined URL, though usually they 404
    • Cannot update URL’s in the admin area. Such fields are usually disabled, as WordPress disallows their editing if the home URL is in the wp-config.php file
    • https://codex.wordpress.org/Changing_The_Site_URL#Changing_the_Site_URL

URLs redirecting to old site after migration

  • Symptoms: Home page is up and looks fine but links in the site all keep going to the old/source site.
  • Solution:
    • Re-run importbuddy.php entering the correct URLs and watching for any errors.
    • Also make sure import is finishing correctly, may be timing out without realizing it.
      • Can check the importbuddy.txt log to see if it caught something, will be located in same place you uploaded the importbuddy file.
    • Check for any hardcoded/defined URLs in the site’s wp-config.php and HTML files.

URL needs manually updated

  • Note that this does not update serialized data. In short, some plugins, such as PluginBuddy plugins may not have internal URLs updated. This is more of a last-choice solution.
  • SQL to update URL in posts manually:

? 1. update wp_posts set post_content = replace(post_content, 'http://OLD_URL', 'http://NEW_URL');

  • Command line zip test to check if exec is enabled and zip can create a file. Download: Media:Zip_test.zip
  • Safest way to mass search/replace URLs is to use a tool that is prepared to handle serialized data. Search-Replace-DB is a well known open source tool to take care of this.

The unzip process reported success but the backup data file…

“Error! The unzip process reported success but the backup data file, backupbuddy_dat.php was not found in the extracted files. The unzip process either failed (most likely) or the zip file is not a proper BackupBuddy backup.”

  • Most common cause: See [1]
  • The backup did not finish extracting (timed out).
  • Verify the backup is not damaged.

Importbuddy.php shows ACTUAL file contents instead of the next step

There is one report that on Step 4, importbuddy.php started showing the actual importbuddy.php file contents. The reason for this was that the EXTRACTED .htaccess file from the OLD server/site was causing the issue.

This is VERY similar OR the same as Step 3 downloading importbuddy.php file issue which also contains possible reasons and solutions.

  • Solutions
    • Check your .htaccess file on the OLD server/site and fix any issues with it. THEN do the backup.
    • After Step 3 has finished, and BEFORE proceeding to Step 4 (or any such step where this problem happens), open a new window OR your FTP program, go and find the EXTRACTED .htaccess file, EDIT it to remove any UNWANTED directives, and then switch back to the importbuddy.php window to continue onto the next step.
    • On the OLD site, ALSO try saving your Permalinks again in WordPress –> Permalinks. Simply click “Save” on that page and then do a backup and retry the import/restore/migration.
    • Thanks to our customer Chris Malone for finding the issue and finding a solution right away too.
    • As mentioned above, this is VERY similar OR the same as Step 3 downloading importbuddy.php file issue which also contains possible reasons and solutions.

BackupBuddy Classic

BackupBuddy Classic is available to download in case you have an older system OR older system specs like older PHP, MySql, and other things. BackupBuddy Classic does not have any of the new features of BackupBuddy.

If your system or host forces you to use BackupBuddy Classic, you should start considering switching to another host or server which is not old or not updated regularly.

BackupBuddy Classic can be found in your Member’s area and is labeled ” BackupBuddy Classic .”

Scroll to Top