BackupBuddy: Frequent Support Issues

(Difference between revisions)
Jump to: navigation, search
(Added - BackupBuddy Tab Missing in WordPress: sub-section)
(Added the point of saving permalinks on the OLD site - Importbuddy.php shows ACTUAL file contents instead of the next step)
Line 464: Line 464:
 
**Simply deleting the .htaccess file, REDOING the backup, and then restoring/migrating should work.
 
**Simply deleting the .htaccess file, REDOING the backup, and then restoring/migrating should work.
 
**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, DELETE it, and then switch back to the importbuddy.php window to continue onto the next step.
 
**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, DELETE it, 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.
 
**Thanks to our customer Chris Malone for finding the issue and finding a solution right away too.
  

Revision as of 20:03, September 26, 2011

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

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).
  • Solutions:
    • 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.
    • Move to a new host that does or will provide this capability
    • 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. The below code will add the directory of the zip executable to PATH after you ask your host where it is being kept:
      • 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 */

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 long to finish & server kills it. 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.

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

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

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:

wp-content/uploads/backupbuddy_temp/NAMEOFBACKUP

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.

For example, if your backup file name is:

backup-domain_com-2012_05_29-ukitenaifg

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.

Restoring/Migrating

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 (found in the latest BackupBuddy version OR latest 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.

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 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.
  • 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 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 your .htaccess file is not causing the issue.
  • Related customer thread with easy solution:

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 beta version here" - 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:
    • Image of where the latest BETA importbuddy.php download link is

Links (permalinks) return 404 errors

  • 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'.
  • 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 stop after Step 2 (file extraction)
      • 2) After step 2 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 click to "Save Changes"

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

Restoring database times out

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

URLs redirecting to old site

  • Verify that you properly entered the old and new URLs of your site during the importbuddy.php Import Process.
  • Solution:
    • Re-run importbuddy.php entering the correct URLs.
    • Also make sure import is finishing correctly, may be timing out without realizing it.

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

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.

  • Solutions
    • Simply deleting the .htaccess file, REDOING the backup, and then restoring/migrating should work.
    • 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, DELETE it, 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.

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