* 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":

+

===What are Loopbacks===

+

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

+

+

===Symptoms===

+

<ul>

+

<li>You receive a warning or error #9038 or a message indicating HTTP Loopbacks are not functioning, such as on the Backups page.</li>

+

<li>"Endless Ping" symptom</li>

+

<li><ul>"Endless ping" usually happens before the second Scheduled Cron in your backup is run. You can see the number of times "Scheduled Cron" is mentioned in the Advanced Logs shown on the backup page to see if this is the case.</li>

+

<li>

<pre>

<pre>

Backing up with BackupBuddy v2.1.8...

Backing up with BackupBuddy v2.1.8...

Line 24:

Line 29:

1307910926|ping

1307910926|ping

</pre>

</pre>

−

* Solution:

+

</ul></li>

+

</ul>

+

+

===Troubleshooting===

+

* Temporarily disable all other WordPress plugins to rule out another plugin causing problems. This is a quick way to narrow down the problem. After seeing if this helps you can re-enable all the recent plugins by clicking on "Recently Active Plugins" on the plugins page.

+

* Verify the "Loopback Domain & IP" listed on the "Server Tools" page is correct and pointing to the expected URL and IP address, especially if you recently changed DNS settings.

+

** Deactivate all other plugins and see if it works to rule out another plugin conflicting, if so then make sure you don't have a plugin that may apply a maintenance mode

+

*** This is because maintenance mode plugins rarely, if ever, take into account WordPress scheduling crons

+

* Are you password protecting all or a portion of your site by using htpasswd (eg in the htaccess)? Some plugins may enable this for additional security but it often breaks the WordPress cron. Workaround:

+

** You can exclude the specific files wp-cron.php and wp-admin/admin-ajax.php from the password protection using techniques such as outlined in these articles:

** It's not uncommon to do this. Another option is to allow unconditional access from the server IP address itself (provided this is known and fixed or at least a limited set of IPs). The blocking of access to wp-cron.php would affect WordPress task scheduling in general (not just BackupBuddys use of it) and blocking wp-admin/admin-ajax.php may affect other functionality as well so in general with WordPress if password protection is enabled it is best to "whitelist" these one way or another.

+

+

===Workaround if other solutions fail===

+

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

** Add define('ALTERNATE_WP_CRON', true); to your wp-config.php

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

*** 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. */)

*** 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. */)

*** <pre>define('ALTERNATE_WP_CRON', true);</pre>

*** <pre>define('ALTERNATE_WP_CRON', true);</pre>

−

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

+

===See Also===

**[http://ithemes.com/codex/page/BackupBuddy:_Frequent_Support_Issues#Endless_Ping_on_second_Scheduling_Cron Endless Ping on Second Scheduling Cron in BackupBuddy Codex]

**[http://ithemes.com/codex/page/BackupBuddy:_Frequent_Support_Issues#Endless_Ping_on_second_Scheduling_Cron Endless Ping on Second Scheduling Cron in BackupBuddy Codex]

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

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

* Directory exclusion is not available in this mode. Even existing backups will be backed up, resulting in rapidly growing backup file sizes.

−

* If you are running on a Windows server (or developing locally, ie on Xampp) you will need to install the [http://pluginbuddy.com/wp-content/uploads/2010/05/backupbuddy_windows_unzip.zip Windows zip.exe executable] (we do not provide support for setting this up, though the readme.txt in the file does help).

+

* If you are running on a Windows server (or developing locally, ie on Xampp) you will need to install the [http://ithemes.com/wp-content/uploads/2010/05/backupbuddy_windows_unzip.zip Windows zip.exe executable] (we do not provide support for setting this up, though the readme.txt in the file does help).

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

Line 60:

Line 80:

BackupBuddy is reporting that it is unable to access this functionality on my server hosting environment.

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.

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

+

These are commonly available features of many popular hosting providers such as HostGator, Godaddy, Site5, etc so it is

not unreasonable to request it nor is it a security risk IF it is properly configured.

not unreasonable to request it nor is it a security risk IF it is properly configured.

Line 87:

Line 107:

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

* 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==

==.htaccess 404 / Addhandler Warning==

Line 300:

Line 314:

** Logging into the WordPress admin and navigating around a few BackupBuddy pages can trigger it to create the folder also.

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

*** Setting permissions to 777 temporarily can let give it a chance to create it if it was having trouble doing so for some reason.

+

+

==wp-cli support==

+

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

+

wp help backupbuddy

+

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

+

wp help backupbuddy backup

Line 544:

Line 564:

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.

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 [http://ithemes.com/hostgator HostGator] ) which is not old or not updated regularly.

+

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

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

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

Backing Up

HTTP Loopback Connections Disabled

What are Loopbacks

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

Symptoms

You receive a warning or error #9038 or a message indicating HTTP Loopbacks are not functioning, such as on the Backups page.

"Endless Ping" symptom

"Endless ping" usually happens before the second Scheduled Cron in your backup is run. You can see the number of times "Scheduled Cron" is mentioned in the Advanced Logs shown on the backup page to see if this is the case.

Troubleshooting

Temporarily disable all other WordPress plugins to rule out another plugin causing problems. This is a quick way to narrow down the problem. After seeing if this helps you can re-enable all the recent plugins by clicking on "Recently Active Plugins" on the plugins page.

Verify the "Loopback Domain & IP" listed on the "Server Tools" page is correct and pointing to the expected URL and IP address, especially if you recently changed DNS settings.

Deactivate all other plugins and see if it works to rule out another plugin conflicting, if so then make sure you don't have a plugin that may apply a maintenance mode

This is because maintenance mode plugins rarely, if ever, take into account WordPress scheduling crons

Are you password protecting all or a portion of your site by using htpasswd (eg in the htaccess)? Some plugins may enable this for additional security but it often breaks the WordPress cron. Workaround:

You can exclude the specific files wp-cron.php and wp-admin/admin-ajax.php from the password protection using techniques such as outlined in these articles:

It's not uncommon to do this. Another option is to allow unconditional access from the server IP address itself (provided this is known and fixed or at least a limited set of IPs). The blocking of access to wp-cron.php would affect WordPress task scheduling in general (not just BackupBuddys use of it) and blocking wp-admin/admin-ajax.php may affect other functionality as well so in general with WordPress if password protection is enabled it is best to "whitelist" these one way or another.

Workaround if other solutions fail

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

Add define('ALTERNATE_WP_CRON', true); to your wp-config.php

Open your wp-config.php in a text editor. This file is located in the root of your site.

Add the line somewhere between the first ( <?php ) and last line of the file (but before the line that says /* That's all, stop editing! Happy blogging. */)

On Linux Systems

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

Compatibility Mode

If your server does not support command line Zip then BackupBuddy will fall back into a compatibility mode to help aid you in creating a backup. This mode is significantly slower and less reliable. It is not intended for persistent use and is provided to aid you in backing up in poor hosting environments, for instance to move to another host.

Directory exclusion is not available in this mode. Even existing backups will be backed up, resulting in rapidly growing backup file sizes.

If you are running on a Windows server (or developing locally, ie on Xampp) you will need to install the Windows zip.exe executable (we do not provide support for setting this up, though the readme.txt in the file does help).

Solutions:

If you are running CentOS on a VPS or similar type of server then running the command

yum install zip

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

for Debian-based Linux (including Ubuntu) run the following at the command line:

sudo apt-get install zip unzip

If you are operating a Media Temple DV server then please make sure you have the Developer Tools installed as this contains the package necessary to provide zip capability.

If your server is configured to disable access to the PHP exec() function and if you have access to configure your server then remove any blocking of the PHP exec() function in php.ini and configure permissions to allow running the Linux command line function `zip`.

If your server is operating in safe_mode then either turn safe_mode off (if you can) or make sure that the safe_mode_exec_dir configuration parameter includes the directory which contains the `zip` command (please consult your host support for this information)

Dear Sir/Madam,
I am attempting to use the highly popular WordPress backup software, BackupBuddy by PluginBuddy.com.
BackupBuddy requires the ability to use the Linux command line Zip command via PHP's exec() function.
BackupBuddy is reporting that it is unable to access this functionality on my server hosting environment.
Please enable this functionality for me so that I may use this backup solution in combination with your hosting.
These are commonly available features of many popular hosting providers such as HostGator, Godaddy, Site5, etc so it is
not unreasonable to request it nor is it a security risk IF it is properly configured.
Please verify access to the following features:
1) PHP's exec() function.
2) Permission to run Linux's `zip` command.
3) The directory containing the `zip` command is included in the PATH environment variable
available to the process executing the command passed to the exec() function
Thank you for your time and consideration.

Also possible that even though that zip via exec() is enabled it still may not work if host does not have zip's path location currently as a part of PATH (or the path is not one of the "well known" locations that more recent versions of BackupBuddy with search). The below code is an example of how to add the directory of the zip executable to PATH after you ask your host where it is being kept and whether this is the correct way to do it on their servers or if not what is the preferred way (please note the colon that precedes the path being added):

putenv( "PATH=" . getenv( 'PATH' ) . ":directory zip exe is" );

The line has to be added anywhere in the wp-config.php file after the first line ( <?php ) but at least before the line that says /* That's all, stop editing! Happy Blogging */

If all of the above are either impossible or unsuccessful and you absolutely must have the native zip command capability then 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

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

Backup completed but backup ZIP is incomplete / bad: exec() shares the maximum allowed memory usage with PHP. If this memory limit is met the exec() / proc() will be killed and return to PHP. The symptoms of this are a bad / incomplete ZIP file despite the backup fully completing successfully. Try increasing `memory_limit` to a larger size.

exec()

proc()

Maximum PHP Runtime Timeout

Zip file size stops increasing.

Zip file size stops increasing

Memory Limit Hit

Zip creation completed but ZIP fileincomplete & 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.

Can force a cron job to run in Cpanel by adding this line of code to a cron job if really need to:

Error 3382

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

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.

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.

Dropbox Backups Not Arriving

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

Possible reasons:

Due to the Dropbox API limits, each backup file has to be loaded into your server's memory and then sent to Dropbox. Dropbox requires PHP oAuth. Because of that, your server may run out of the required memory to do other things at the same time. When your server does not have enough memory to do multiple things at once, it may take longer than usual to complete each task, and the Dropbox process may take longer than the allowed time in PHP maximum_execution_time. This will simply result in the Dropbox process to time out and cancel. Since the limitation is because Dropbox requires PHP oAuth, there is no current workaround other than more memory.

BackupBuddy can only transfer full backup files that can easily or be fully loaded into your server's memory. So if your backup file size is 200mb BUT your server memory size is only 128mb, your server will not be able to handle such a backup transfer to Dropbox, even if Dropbox allows such a transfer. If a Dropbox transfer exceeds your server memory limits, the backup will definitely not be transferred properly or at all. This is a server limitation, usually on less powerful servers, that we're trying to find a fix for.

Your server or site has file transfer or PHP script processing limits which is resulting in the transfer not finishing.

Your Dropbox connection settings are wrong.

Your server may not have enough memory to perform this transfer.

Your backup is around or larger than 300mb. Dropbox has a 300mb file size limitation when uploading files online via a file. Dropbox has a limitation of 300mb per file size upload limit when done via anything other than the Desktop dropbox client. This limitation is thus imposed on BackupBuddy also by Dropbox.

Solutions to try:

Make sure your Dropbox connection settings are right.

Delete your current Dropbox connection and then re-create the Dropbox connection. See if that works.

Most important and basic thing to try: wait 10 to 15 minutes for the backup to arrive before giving up. Dropbox uploads can be slow due to Dropbox itself. Dropbox has been known to show files even 30 minutes after a backup file was sent.

Ask your host to increase the PHP maximum_execution_time. This is usually 30 seconds. Try increasing it to something much higher temporarily to see if that makes any difference.

Ask your host if your server can get more allotted memory.

Ask your host to enable PHP error logging to a file that you can access.

What this does is create an entry, in a txt file on your server that your host can tell you the location of, every time there is a PHP related error or warning. When DropBox times out, this file can most probably give you an exact error message that you can tell your host to address or fix.

Try sending a smaller backup file OR simply a database backup file to Dropbox. You can also use the Exclude option to exclude folders and files you do not need or to test things. See if such smaller files arrive. If they do, your issue is definitely with the larger file sizes.

Try excluding certain folders from the backups via BackupBuddy --> Settings and then see if the smaller-than-before backup files get to Dropbox. Dropbox has a limit of 300mb per file size upload when uploading any file through any channel other than the desktop client. Therefore, this 300mb max size per each file limit is imposed by Dropbox on BackupBuddy also. Excluding unwanted folders can help reduce your backup file sizes.

Database SQL (MySql) file inside full backups

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

wp-content/uploads/backupbuddy_temp/XXXXXXXX

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

For example, if your backup file name is:

backup-domain_com-2012_05_29-ukitenaifg.zip

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

wp-content/uploads/backupbuddy_temp/ukitenaifg

BackupBuddy Tab Missing in WordPress

If the BackupBuddy Tab is missing in your WordPress Admin area, there could be a few reasons for it:

MULTISITES: If you are activating BackupBuddy on a single site inside a Multisite instead of using the NETWORK ACTIVATE option, BackupBuddy options will be hidden on purpose for security reasons. You must use Network NETWORK ACTIVATE instead.

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.

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.

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

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`

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.

Users of XAMPP (Windows)

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

Users of WAMP (Windows)

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

Users of Ubuntu + Apache

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

500 Server Errors

.htaccess (click for details) file is invalid or contains unsupported directives. Often an "AddHandler" line exists from the source server that is not supported on the new destination server.

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

Optionally manually edit the .htaccess file in a text editor following the format on the .htaccess page.

Invalid file permissions such as being too restrictive OR too open. Some servers throw a 500 error if permissions are set to 777 to prevent accidental unauthorized access.

If permissions are currently set to 777 try changing them to 644 recursively on the site.

PHP is not functioning or enabled for the site. Check with basic phpinfo().

A 404 error is occurring but the server is not set up correctly to return a 404

Restoring database times out

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.

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

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.

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.

BackupBuddy Classic

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

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

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