BackupBuddy: Frequent Support Issues

(Difference between revisions)
Jump to: navigation, search
(Backups Time Out / Marked as Bad)
(URL needs manually updated: Teach wiki about Search-Replace-DB)
(23 intermediate revisions by 6 users not shown)
Line 38: Line 38:
 
** http://ithemes.com/forum/index.php?/topic/17385-backupbuddy-doesnt-backup-at-all-infinite-ping/
 
** http://ithemes.com/forum/index.php?/topic/17385-backupbuddy-doesnt-backup-at-all-infinite-ping/
 
** http://ithemes.com/forum/backupbuddy/endless-pinging-v2-2-14
 
** http://ithemes.com/forum/backupbuddy/endless-pinging-v2-2-14
 +
 +
=== 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==
 
==Compatibility Mode==
Line 45: Line 48:
 
* Solutions:
 
* Solutions:
 
** If you are running CentOS on a VPS or similar type of server then running the command <pre>yum install zip</pre> 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.
 
** If you are running CentOS on a VPS or similar type of server then running the command <pre>yum install zip</pre> 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: <pre>sudo apt-get install zip unzip</pre>
 
** 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 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 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`.
Line 50: Line 54:
 
** Ask your host to enable access to the Linux command line Zip command via PHP's exec() function.
 
** 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:
 
*** Example message to send to your host:
<pre>
+
<pre>Dear Sir/Madam,
Dear Sir/Madam,
+
  
 
I am attempting to use the highly popular WordPress backup software, BackupBuddy by PluginBuddy.com.
 
I am attempting to use the highly popular WordPress backup software, BackupBuddy by PluginBuddy.com.
Line 66: Line 69:
 
available to the process executing the command passed to the exec() function  
 
available to the process executing the command passed to the exec() function  
  
Thank you for your time and consideration.
+
Thank you for your time and consideration.</pre>
</pre>
+
** 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):
** Also possible that even though that zip via exec() is enable 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):
+
 
*** <pre>putenv( "PATH=" . getenv( 'PATH' ) . ":directory zip exe is" );</pre>
 
*** <pre>putenv( "PATH=" . getenv( 'PATH' ) . ":directory zip exe is" );</pre>
 
*** 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 */
 
*** 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 you only option is to move your site to an alternative server or host that provides this capability.
 
** If all of the above are either impossible or unsuccessful and you absolutely must have the native zip command capability then you 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 ###==
 
==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.
 
* 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==
 
==Warning: mysql_query() [function.mysql-query]: Unable to save result set in /www/wp-content/plugins/backupbuddy/backupbuddy.php on line 1673==
Line 126: Line 135:
 
* 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.
 
* 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.
 
* 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.
 +
** <table border="1"><tr><td>&nbsp;</td><td>exec()</td><td>proc()</td></tr><tr><td>Maximum PHP Runtime Timeout</td><td>Zip file size stops increasing.</td><td>Zip file size stops increasing</td></tr><tr><td>Memory Limit Hit</td><td>Zip creation completed but ZIP file<br>incomplete & marked as bad</td><td>Zip file size stops increasing.</td></tr></table>
  
 
==Zip File Creation Dies at 2GB==
 
==Zip File Creation Dies at 2GB==
Line 135: Line 145:
 
* On a 32bit server the limit for Zip Archive is about 4GB.
 
* On a 32bit server the limit for Zip Archive is about 4GB.
 
** Ask host to upgrade to 64bit.
 
** Ask host to upgrade to 64bit.
** Host may be able to use better configurations or software for the server to up this while staying on 32bit though I am unsure
+
** 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
  
 
==Remote Transfers Fail==
 
==Remote Transfers Fail==
Line 147: Line 157:
 
** Email: port 25 (if using external mail server)
 
** Email: port 25 (if using external mail server)
  
==Scheduled Events Fail to Trigger==
+
==Scheduled Events Fail to Trigger/Using Real Cron to Trigger==
 
* The scheduled date is wrong and has not passed.
 
* 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.
 
* 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.
Line 205: Line 215:
 
** See if any other plugin may be causing the issue. Disable other plugins and try starting the backup process again.
 
** 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.
 
** 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, post on the [http://ithemes.com/forum/backupbuddy/ forums] so that the error can be looked at.
 
** Make sure the Advanced Log file in BackupBuddy is not showing any errors. If it is, post on the [http://ithemes.com/forum/backupbuddy/ forums] so that the error can be looked at.
  
Line 233: Line 244:
 
*'''Possible reasons:'''
 
*'''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.
 
**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 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 Dropbox connection settings are wrong.
 
**Your server may not have enough memory to perform this transfer.
 
**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.
+
**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:'''
 
*'''Solutions to try:'''
 
**Make sure your Dropbox connection settings are right.
 
**Make sure your Dropbox connection settings are right.
Line 246: Line 258:
 
***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.
 
***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 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.
+
**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.  
 
*'''Related links:'''
 
*'''Related links:'''
 
**http://ithemes.com/forum/index.php?/topic/18099-dropbox-not-working/#p85173
 
**http://ithemes.com/forum/index.php?/topic/18099-dropbox-not-working/#p85173
Line 252: Line 264:
  
 
==Database SQL (MySql) file inside full backups==
 
==Database SQL (MySql) file inside full backups==
In full backups, the actual database is backed up also. To find this file, look for the following folder in your backup file after you have extracted/unzipped the backup zip file:  
+
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/'''NAMEOFBACKUP'''
+
wp-content/uploads/backupbuddy_temp/'''XXXXXXXX'''
  
The '''NAMEOFBACKUP''' part in the above link will be the exact same as the last set of characters, after the date, in your backup file name.
+
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:
 
For example, if your backup file name is:
  
'''backup-domain_com-2012_05_29-''ukitenaifg'''''
+
'''backup-domain_com-2012_05_29-''ukitenaifg''.zip'''
  
 
then the folder inside a full backup where your database file is saved is
 
then the folder inside a full backup where your database file is saved is
Line 274: Line 286:
 
**[http://ithemes.com/codex/page/Installing_BackupBuddy#Multisite Network Active BackupBuddy on Multisites]
 
**[http://ithemes.com/codex/page/Installing_BackupBuddy#Multisite Network Active BackupBuddy on Multisites]
 
**[http://ithemes.com/forum/index.php?/topic/18395-backupbuddy-installed-and-working-but-missing-from-wordpress-left-panel/ Plugin conflicts causing BackupBuddy to disappear in WordPress Admin panel]
 
**[http://ithemes.com/forum/index.php?/topic/18395-backupbuddy-installed-and-working-but-missing-from-wordpress-left-panel/ Plugin conflicts causing BackupBuddy to disappear in WordPress Admin panel]
 +
 +
==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.
 +
  
 
=Restoring/Migrating=
 
=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==
 
==Step 3 in import results in importbuddy.php file being downloaded when "Next Step" is clicked==
Line 281: Line 317:
  
 
* 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)
 
* 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 (found in the latest BackupBuddy version OR latest download link available on the BackupBuddy main Backup page.)
+
** 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.
 
** 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:
 
** Third, AFTER you encounter the problem, since the importbuddy.php file already has extracted the files:
Line 337: Line 373:
  
 
==After import: The source site is now redirecting to the destination site (or vice versa):==
 
==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 4 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 4 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 4 with the NEW database settings for the new database.  This way both sites will have their own database for their respective URLs.
+
* 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.
 
* 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`==
 
==After import: WordPress Error: `You do not have sufficient permissions to access this page`==
Line 381: Line 416:
 
*Related customer thread with easy solution:
 
*Related customer thread with easy solution:
 
**http://ithemes.com/forum/index.php?/topic/17989-update-in-progress-after-migrate/
 
**http://ithemes.com/forum/index.php?/topic/17989-update-in-progress-after-migrate/
 
==Where can I get the latest BETA of importbuddy.php?==
 
Starting with version 2.2.14, BackupBuddy now also includes a way to download the latest BETA version of importbuddy.php which will have the latest bleeding edge features. The link is in your BackupBuddy admin area.
 
* To download the latest BETA version of importbuddy.php
 
** Click the BackupBuddy tab OR the downward arrow in front of it to expand it.
 
** Click the Backup & Restore link under that tab.
 
** Look at the 3 images on that page, specifically the right most image called "Restore/Migrate."
 
** Right under it will be a link text "'''''Try the latest <ins>beta version here</ins>'''''" - that is your download link.
 
** Click that link to download the latest BETA version of importbuddy.php to your computer.
 
** Upload and use that file anywhere you want to restore/migrate your BackupBuddy backups.
 
* Here is the image of your '''BackupBuddy --> Backup & Restore''' area, where the latest BETA importbuddy.php download link is:
 
**[[File:Backupbuddy-importbuddy-beta.jpg|Image of where the latest BETA importbuddy.php download link is]]
 
  
 
==Links (permalinks) return 404 errors==
 
==Links (permalinks) return 404 errors==
 +
====Most Common====
 
* The [[.htaccess]] file was not configured properly or was not writable so importbuddy didn't update it.
 
* The [[.htaccess]] file was not configured properly or was not writable so importbuddy didn't update it.
* To fix log in to the admin dashboard and navigate to: Settings -> Permalinks and click 'Save Changes'.
+
** 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.
 
* 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
 
* 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
+
** Cause: .htaccess file is causing redirections.
 
** Solution:
 
** Solution:
*** 1) Redo import and stop after Step 2 (file extraction)
+
*** 1) Redo import and pause after Step 2 (file extraction).
*** 2) After step 2 delete the .htaccess file in the root of the site
+
*** 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
 
*** 3) Continue the import to completion
*** 4) Regenerate the .htaccess file in WordPress by going to Settings -> Permalinks -> and click to "Save Changes"
+
*** 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.
 +
* [http://codex.wordpress.org/Using_Permalinks#Fixing_Permalink_Problems 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.  [http://serverfault.com/questions/139791/how-can-i-enable-mod-rewrite-in-apache-on-ubuntu 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:====
+
====500 Server Errors====
 
* [[.htaccess]] (click for details) file is causing URLs to be redirected improperly or is malformed. Sometimes the front end simply won't load.
 
* [[.htaccess]] (click for details) file is causing URLs to be redirected improperly or is malformed. Sometimes the front end simply won't load.
 
** Regnerating the .htaccess file can solve. To do this login to your admin dashboard and go to Settings -> Permalinks -> and click the "Save Changes" button.
 
** Regnerating the .htaccess file can solve. To do this login to your admin dashboard and go to Settings -> Permalinks -> and click the "Save Changes" button.
Line 469: Line 502:
 
** 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
 
** 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
  
==URLs redirecting to old site==
+
==URLs redirecting to old site after migration==
* Verify that you properly entered the old and new URLs of your site during the importbuddy.php Import Process.
+
* Symptoms: Home page is up and looks fine but links in the site all keep going to the old/source site.
 
* Solution:
 
* Solution:
** Re-run importbuddy.php entering the correct URLs.
+
** 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.
 
** 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.
 +
*** If site URL is hardcoded in theme HTML files can wrap them in home_url( '/directory/' ) to fix.
  
 
==URL needs manually updated==
 
==URL needs manually updated==
Line 480: Line 516:
 
<pre class="brush:html">update wp_posts set post_content = replace(post_content, 'http://OLD_URL', 'http://NEW_URL');</pre>
 
<pre class="brush:html">update wp_posts set post_content = replace(post_content, 'http://OLD_URL', 'http://NEW_URL');</pre>
 
* Command line zip test to check if exec is enabled and zip can create a file. Download: [[Media:Zip_test.zip]]
 
* 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. [https://github.com/interconnectit/Search-Replace-DB 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...==
 
==The unzip process reported success but the backup data file...==

Revision as of 07:53, November 25, 2012

Contents

Backing Up

HTTP Loopback Connections Disabled

  • Also known as Endless Ping.
  • This 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.
  • If your Server Information page reports that HTTP Loopback Connections are disabled or the following occurs (see below), you need to either enable HTTP Loopback Connections or enter the WordPress Alternate Cron setting in your wp-config.php file. This is caused if your host is blocking loopback connections within their firewall. You will need to request that your host change this (this is very standard to have this available), enable the alternate cron method in your wp-config.php (as Solution below - often the only solution for those in a shared environment), or move to a new host.
    • If your backup progress (as detailed in the Advanced Details area) consistently never progresses beyond this point except for the continuous "pings":
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
  • Solution:
    • 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);
    • Deactivate all other plugins and see if it works then, 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
  • 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 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.com 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 you 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

Godaddy Related

  • The bottom tier of Godaddy hosting services are known for not being able to complete backups within the maximum PHP runtime configured on their servers (usually 30 seconds), causing backups to fail.
  • Solutions:
    • Choose another quality hosting provider such as Hostgator.com (recommended)
    • Upgrade to a higher tier of Godaddy hosting (not recommended as even better Godaddy servers are poor performers)

.htaccess 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 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 behaviour. 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 immeditately. 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 TimeoutZip file size stops increasing.Zip file size stops increasing
      Memory Limit HitZip 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.

Zip File Creation Dies at ~4GB

  • On a 32bit server the limit for Zip Archive is about 4GB.
    • Ask host to upgrade to 64bit.
    • 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

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 alotted 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, lot of times this would be the wp_posts table.
    • See if can lower size of 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. :D
  • 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.


Backed up files link shows 404 error

  • 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, post on the forums 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 setup properly, either automatically or manually, you'll run into the "Unable to create backup storage directory" or similar errors.

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.
  • Related links with solution:

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.
  • Related links:

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.
    • 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.


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.

Extraction of zip files (unzipping) does not work

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

Here are 2 manual solutions, one via FTP and one via cPanel, on unzipping the files manually and then continuing the importbuddy.php process. Try either of the following:

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 does 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 url's 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.
      • Can also use RepairBuddy to verify home URL.
  • Related customer thread with easy solution:

Links (permalinks) return 404 errors

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 causing URLs to be redirected improperly or is malformed. Sometimes the front end simply won't load.
    • Regnerating 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".
  • 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. Do sanity check with .htm file.
  • Manually edit the .htaccess file in a text editor following the format on the .htaccess page.
  • Delete or manually remove your OLD .htaccess file from the extracted folders after it passes the step of extracting files, from the backup file (and then zip it again) OR before you do a backup.
  • Edit your OLD .htaccess file to be basic without any extra comments that may be interfering on the new server.
  • Make sure your new OR old .htaccess does NOT have any directive that is resulting in any website file, including the index, to be blocked.
  • See `.htaccess being overwritten on unzip` below if it happens on Step 2 of import.
  • Ask your host to look at the .htaccess file and to fix any errors with it, OR to delete the EXISTING AND/OR GENERATED .htaccess file OR to generate a new .htaccess file for you.

.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.

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 I don't think this acts 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.

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

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.
      • If site URL is hardcoded in theme HTML files can wrap them in home_url( '/directory/' ) to fix.

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:
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 ( we recommend HostGator ) which is not old or not updated regularly.

BackupBuddy Classic can be found in your Member's area and is labeled "BackupBuddy Classic."

Additional Resources

  1. Purchase BackupBuddy
  2. PluginBuddy Tutorials
  3. PluginBuddy.com
  4. Support Forums
Personal tools
Namespaces
Variants
Actions
iThemes Codex
Codex Navigation
Toolbox