Difference between revisions of "BackupBuddy: Stash Live Troubleshooting"

From iThemes Codex
Jump to: navigation, search
(Created page with "3xxx = Database, 4xxx = Zip, 5xxx = Stash Live, 7xxx = Import, 8xxx = Deployment, 9xxx = Unclassified primary error, Any number 10,000+ = Unclassified, typically rarely seen. ...")
 
(Show Status Log)
 
(13 intermediate revisions by the same user not shown)
Line 1: Line 1:
3xxx = Database, 4xxx = Zip, 5xxx = Stash Live, 7xxx = Import, 8xxx = Deployment, 9xxx = Unclassified primary error, Any number 10,000+ = Unclassified, typically rarely seen.
+
=Basic Troubleshooting Steps=
 +
==Initial Investigation==
  
==3382==
 
'''This error code is deprecated. See error code #4001.'''
 
  
<strong>Backup FAILED. Unable to successfully generate ZIP archive. Error #3382.12:20:04: Failed function backup_zip_files. Backup terminated.</strong>
+
===Show Status Log===
 +
To get the Stash Live Status Log please navigate to "Stash Live" pages -> Scroll down to the bottom of the page and select the "Show Advanced Troubleshooting Options" button -> Select "View Status Log". Please copy/paste this into a text file and attach it to your support ticket.
  
* The 3382 error literally means that both command line zip AND pclzip were unable to create a .zip file and failed for some reason.
+
===Misc===
* Possible causes:
+
# "Settings" page -> "Recent Activity" tab. Check for Live errors.
** There are file(s)/folder(s) in your site installation directory that the server process building the backup zip archive file is unable to access and hence the backup will be halted rather than be created with the possibility of content that you have requested to be included not actually being able to be included. The Status Log of the manual backup will include log entries related to the problem files and you can investigate these identified files to determine what the problem may be with the site and resolve it so that either the files can be included or not based upon the result of your investigation. If you are seeing the error code in an email in relation to a scheduled backup then as the email suggests you should run a manual backup to check as noted above.
+
# If the current status indicates everything is "Up to date" but the stats indicate otherwise or something 'odd', "Stash Live" pages -> "Show Advanced Troubleshooting Options" button -> click "Restart Periodic Process" button.
** Command line zip is being actively killed. (Cheapest packages at Godaddy kill off exec() within about 10 seconds, throwing the user into compatibility mode which cannot handle larger sites).
+
# If the files are not progressing or stuck at zero, see the Remote Destinations page Recent Transfers list to check for file transfer issues.
** Permissions may be blocking backup file creation. Make sure permissions are set to 755 for the /wp-content/uploads/ directory recursively.
 
** Your hosting account may not have enough free space to create the backup file.
 
** There may be one or more files/folders being included in the backup which neither the native zip command nor the pclzip function are able to access, e.g., unreadable files or broken symbolic links
 
* Possible solutions:
 
** If you have BackupBuddy Version 3.1.8.3 or later then the Status Log of a manual backup will contain detailed information concerning the problem, which may be just an exit code or an exit code and information on files and may indicate problems such as the file being unreadable - you should check the file(s) noted and determine what the file(s) are so that you can determine how to proceed.
 
*** If you do not require the file then you can simply delete it
 
*** If you require the file and it should be included in the backup then you must change the ownership/permissions such that it is readable in the same way as other files on the site
 
*** If you require the file but do not want it in the backup then you must tell BackupBuddy to exclude it using the Exclusions on the Settings page
 
*** Remember that BackupBuddy is a WordPress site backup tool and not a hosting backup tool so ideally you should exclude everything from your backup that isn't required for the operation of your WordPress site and that includes any directories that your host may have created in your site installation directory, e.g., a cgi-bin directory is common but this is hosting specific and not a component of a WordPress site and should be restored by the host if required. There may be other such directories dependent on your host and it is very worthwhile becoming familiar with your site, what is there and why, so that you can more easily spot stuff that shouldn't be there. Please note that we cannot advise of the particulars of any specific site as we do not know the details of your site or your hosting but your host support should certainly be able to help you with information on whether and what files/folders they may put in the directory where you might have your site installed.
 
*** If you are having trouble interpreting the diagnostic information in the Status Log then please create a topic in the BackupBuddy Forum and we can help explain it to you - however, this doesn't mean to say that we can resolve the issue as it relates to your files and server.
 
** If you have BackupBuddy Version 2.2.29 up until  Version 3.1.8.2 then visit the Settings page and enable the Alternative Zip System option and save. Then repeat a Full backup and study the Advanced Details for indications of failure.
 
*** For the native zip command alternatives there will usually be an exit code followed by some general descriptive text concerning the reason for failure (such as being unable to read a file, lack of disk space, etc.).
 
*** If the failure is file based then unfortunately at present we are unable to isolate the specific file details from this command. However, the backup will fall back to the Compatibility Mode and the failure indication from that will almost certainly provide a specific indication of the file (including the absolute file path) that is causing the issue. In such a case you must correct the issue by making the file readable if that is appropriate for the file or alternatively use the Exclusions on the Settings page to exclude the folder that contains the bad file.
 
*** If you cannot make the file readable and you cannot exclude the folder (because it contains other files that you need) then you will need to consult your host support to try and resolve what is the issue with the file.
 
*** If you are having trouble interpreting the diagnostic information in the Advanced Details then please create a topic in the BackupBuddy Forum and we can help explain it to you - however, this doesn't mean to say that we can resolve the issue as it relates to your files and server.
 
** Verify permissions are set correctly for /wp-content/uploads/ and all subdirectories/files therein - the server process running the backup needs to be able to access the directories and read/write files/directories - commonly this may mean 755 permissions for directories and 644 permissions for files.
 
** Verify allowed disk usage isn't close or exceeded. (ie Your hosting account is limited to 5GB and you've used 4.95GB.)
 
** Reducing backup size often helps. (directory exclusion, etc)
 
** Turning Zip Compression on or off may help.
 
** Have at least double the amount of defined storage quota available (or the same amount of free space as your used disk space) so that the backup can be created.
 
* Related link:
 
** http://ithemes.com/forum/topic/39288-information-how-to-diagnose-your-site-3382-problem/ (good thread to check)
 
** http://ithemes.com/forum/index.php?/topic/17953-backup-failure/#p85314
 
** http://ithemes.com/forum/index.php?/topic/20145-another-solution-to-error-3382/
 
  
==4001==
+
==Deeper Investigation==
For a Manually initiated backup the Backup Overview tab may show:
+
# After looking through the current Status Log for clues, Clear the current Status Log.
 +
# Restart the Periodic Process.
 +
# Check the Status Log for new clues, refreshing as needed (until auto update is added to the log viewing).
  
<strong>Error #4001
+
=Symptom Presentations=
Unable to successfully generate ZIP archive. Backup FAILED. See logs above for more information. Click to view error details in the Knowledge Base</strong>
+
'''Database and Files status indicators both are stuck at ZERO (0) files.'''
 +
* This is a strong indicator that files cannot be sent to Stash Live. See [[BackupBuddy:_Stash_Live_Troubleshooting#File Transfer Problems|File Transfer Problems]] below.
  
or the detailed Status Log tab may show:
+
'''Files status indicator has not progressed in a while.'''
 +
* Could be caused by one or more remote file transfers is failing. See [[BackupBuddy:_Stash_Live_Troubleshooting#File Transfer Problems|File Transfer Problems]] below.
 +
* Could be caused by another issue. See the Status Log for details on the most recent messages, including recent errors, warnings, and which step keeps repeating (if any).
  
<strong>Error #4001: Unable to successfully generate ZIP archive. Backup FAILED. See logs above for more information.</strong>
+
'''Files status indicator stuck at 99%.'''
 +
* This is a strong indicator that a file or two is unable to send. It may be a very large file or having some other problem. See [[BackupBuddy:_Stash_Live_Troubleshooting#File Transfer Problems|File Transfer Problems]] below.
 +
* Could be caused by another issue. See the Status Log for details on the most recent messages, including recent errors, warnings, and which step keeps repeating (if any).
  
The Status Log entries just prior to the final indication of the 4001 condition will provide further detail of the site/server/hosting problem that has caused BackupBuddy to halt the backup because it is either unsafe or impossible to continue. For example, it might be unsafe because a file or files requested to be in the backup cannot be accessed by the web server process or it might be impossible because the site is out of disk space.
 
  
The most up to date information on how to interpret the logs and specific (common) examples of the various site/server/hosting conditions that can cause such problems for your backup please refer to the Support Forum topic below:
+
==File Transfer Problems==
* Related link:
+
[[File:File-send-error.jpg|thumb]]
** https://ithemes.com/forum/topic/39288-information-how-to-diagnose-your-site-33824001-problem/
+
Stash Live needs to be able to send files to the Stash servers for storage. Any problems with file transfers can cause various processes to get 'stuck' or error.
 +
* Navigate to Remote Destinations -> View recently sent files to see if errors are noted.  You may also be able to hover and view error logs if they still exist.
 +
** Click the image to the right for a larger view of this.
 +
* If the problem is a single file or directory of problematic files you may consider excluding.
 +
* Stash Live will typically restart its process after some type has passed (within 12 hours), including resending failed files.
 +
* After resolving any file transfer issues make sure to Pause the Files process and use the Advanced Option to 'Reset Send Attempts'.
  
'''NOTE''': The 4001 condition in BackupBuddy v5+ and the 3382 condition in BackupBuddy pre-v5 are synonymous
 
  
 +
===Error #389383: Unable to initiate multipart upload. Details: `[curl] 60: SSL certificate problem: unable to get local issuer certificate===
 +
* See [[BackupBuddy:_Error_Codes#.5Bcurl.5D_60:_SSL_certificate_problem:_unable_to_get_local_issuer_certificate|60: SSL certificate problem]]
  
==5001==
 
Various errors including: '''Unknown username or password.  Please use your iThemes username (not email) and password to log in.'''
 
* Verify you are logging in with an active iThemes.com Member username and password.
 
  
 +
===Reset File Transfers===
 +
[[File:File-send-error.jpg|thumb]]
 +
# On the Stash Live page PAUSE the Files section.
 +
# Wait until the Files process finishes if it was in the process of sending files (up to approximately 30 seconds usually) for the file transfer number to stop increasing.
 +
# Scroll down to the bottom, expand "Advanced Troubleshooting Options".
 +
# Select "Reset Send Attempts".
 +
# RESUME the Files section of Stash Live.
 +
# If transfer failures are expected, navigate to BackupBuddy -> Remote Destinations -> Select the "View recently sent files" and look for any errors listed or in the log. See the thumbnail to the right.
  
==8001==
+
=Advanced Troubleshooting Buttons=
'''Errors were encountered: Error #8001: Unable to decode json response. Verify remote site API URL `http://yoursite.com`, API key, and that the remote site has the API enabled in its wp-config.php by adding define( 'BACKUPBUDDY_API_ENABLE', true ); somewhere ABOVE the line "That's all, stop editing!". Return data: [Server response here] '''
+
At the very bottom of the Stash Live page there are several troubleshooting buttons you may find useful. Note that it is best to PAUSE the periodic activity (Hit "Pause" in the Files section) and wait for activity in the current background PHP page load to complete so that any changes you make via the buttons below don't get overwritten by the currently running process.
* Commonly this is caused by the line added to the remote site's wp-config.php being in the wrong place.  Make sure ''define( 'BACKUPBUDDY_API_ENABLE', true );'' is added ABOVE the comment line "That's all, stop editing!".  If this is added to the very bottom of the wp-config.php WordPress will not see it.
 
* Verify you have the correct API key entered and that the URL in the error message is valid.
 
  
==8002==
 
'''Error #8002: Error validating API call authenticity. Verify you are using the correct active API key.'''
 
* Usually this is caused if the API key is no longer valid, for instance if the destination site's API key was regenerated which invalidated the previous API key.
 
  
==8003==
+
==Reset File Audit Times==
'''Warning #8003: 404 retrieving remote log `http://yoursite.com/XXX`. This may or may not be normal.'''
+
* The file audit will not run too often. To bypass this safety mechanism (due to performance) do the following. You may then force this step or restart the periodic process to run it.
* During the Deployment process BackupBuddy will request the remote ImportBuddy log from either the remote site's server (pushing) or the local server (pulling). If this log does not exist yet OR has already been deleted then a 404 will result.  Usually this is normal and only temporary.
 
  
==9001==
 
'''Unable to read database table wp_redirection_logs. Your backup will not include data from this table (you may ignore this warning if you do not need this specific data). This is due to the following error: MySQL client ran out of memory in /www/wp-content/plugins/backupbuddy/backupbuddy.php  on line 1757'''
 
  
* '''MySQL client ran out of memory'''
+
==Reset Send Attempts==
** This is typically caused by your PHP memory limit being low, resulting in part of the data returned being clipped.  If you do not need the data from this specific table of the database to be backed up then you may safely ignore this.  Some tables, such as wp_redirection_logs, contain logs that you most likely do not need.
+
* Are there too many remote file transfers failed, causing file sends to halt for the day? Reset this to allow the File Send step to be able to run.
** BackupBuddy attempts to increase the PHP memory limit on runtime but many hosts block this.
 
** Add/modify this line in your php.ini with a higher number than the default, such as: php_value memory_limit 128M
 
** PHP memory is separate from mysql memory. Your host has to up the mysql memory as it is not possible for you the client to do so at all.
 
* '''Unable to save result set'''
 
** This is typically caused by a corrupt database/table. [http://textpattern.com/faq/36/warning-unable-to-save-result-set/ Citation of problem.]
 
** Repair the database/table using a tool such as phpMyAdmin or the free plugin [http://wordpress.org/extend/plugins/wp-dbmanager/ WP-dbManager]
 
** Add this line to wp-config.php to allow WordPress to repair tables: define('WP_ALLOW_REPAIR', true)
 
* '''MySQL server has gone away'''
 
** MySQL server is dying, this is mostly a host issue. Probably need to contact host to get them to fix the issue.
 
* WordPress Revisions may also be clogging up the system
 
** Disabling WordPress' automatic revisions, or at least limiting how many to keep, can help with this error
 
** http://codex.wordpress.org/Editing_wp-config.php#Post_Revisions
 
  
==9002==
 
'''Error #9002: BackupBuddy unable to create directory `/directory/path/here`. Please verify write permissions for the parent directory `/directory/path` or manually create the specified directory & set permissions.'''
 
  
*This error means that BackupBuddy was unable to create a storage directory (such as for backups, log files, temporary files, etc) at the location listed in the error message.  BackupBuddy must be able to create this directory to function properly.
+
==Reset First Completion Time==
* Adjust permissions to allow write & directory creation on the parent directory as specified. ie: /www/wp-content/uploads/
+
* Make Live to think this is the very first backup.
* Optionally manually create the directory and set permissions.
 
  
==9003==
 
  
'''BackupBuddy data file (backupbuddy_dat.php) missing or unreadable. There may be a problem with the backup file, the files could not be extracted (you may manually extract the zip file in this directory to manually do this portion of restore), or the files were deleted before this portion of the restore was reached. Start the import process over or try manually extracting (unzipping) the files then starting over. Restore will not continue to protect integrity of any existing data.'''
+
==Reset Last Snapshot Time==
 +
* Make Live think it's been a long time since the last Snapshot.
  
* This error is often caused by the importbuddy.php script being replaced by an older version during the unzip step. See [http://ithemes.com/codex/page/BackupBuddy:_Frequent_Support_Issues#Old_importbuddy_overwriting_on_unzip importbuddy overwriting on unzip]
 
* This error is often caused by the server timing out before zip file extraction could complete.
 
** Manually extract files using either cPanel or extracting (unzipping) the files locally then uploading them & selecting the importbuddy.php advanced option to skip file extraction.
 
** Ask your server host to extend the maximum script execution time.
 
** Create a custom php.ini file if your host allows for this.
 
*** Tutorial: Create custom php.ini & enable in cPanel: http://pluginbuddy.com/tutorials/custom_php_ini/
 
*** Dreamhost users may use this tool if they do not want to use the above method: http://sxi.sabrextreme.com/dh-phpini
 
*** Increase php.ini max_execution_time
 
** Change hosts & let your current host know why you changed.
 
* Additional potential causes (very rare):
 
** File permissions not allowing reading of the backupbuddy_dat.php file.
 
** Incomplete backup. Verify the backup is marked as Good on the source site.
 
  
==9004==
+
==Unpause Periodic Without Running==
 +
* Unpause the files/periodic process without triggering it to run right now.
  
'''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)
 
  
* Manually extract backup ZIP. This usually resolves this issue.
+
==Resume periodic process==
* Force compatibility mode to see if it able to unzip to completion.
+
* Resume the periodic (files) process wherever it left off.
* Contact the host to see if they can verify that the Linux command line ZIP is set up properly.
+
* This is similar to clicking the Files "Resume" button.
 
 
==9005==
 
 
 
'''File extraction process did not complete successfully. Unable to continue to next step. Manually extract the backup ZIP file and choose to "Skip File Extraction" from the advanced options on Step 1.''' (importbuddy.php)
 
* This ZIP file was unable to be extracted for some reason.
 
** Unzipping may have taken too long and the PHP process halted.
 
** Server memory usage may have been exceeded.
 
** Server configuration may be blocking extracting of ZIP files.
 
 
 
* Attempt manual extraction & disable File Extraction from the advanced debugging options of Step 1.
 
 
 
==9006==
 
'''ERROR: Unable to connect to database server and/or log in. Verify the database server name, username, and password.''' (importbuddy.php)
 
* Verify the server address, your username, and your password. One of these settings is wrong.
 
* cPanel sometimes prefixes your username with a prefix. Check if this exists.
 
 
 
==9007==
 
'''Unable to select your specified database. Verify the database name and that you have set up proper permissions for your specified username to access it.''' (importbuddy.php)
 
* Verify the database name exists.
 
* Verify the mysql username has been granted ALL permissions to this database.
 
 
 
==9008==
 
'''ERROR: A database prefix is required for importing.''' (importbuddy.php)
 
* You must specify a WordPress database table prefix. Default is "wp_" without quotes.
 
 
 
==9009==
 
'''ERROR: Unable to find any database backup data in the selected backup.''' (importbuddy.php)
 
* Database file is missing from the backup.
 
 
 
==9010==
 
'''ERROR: Unable to import SQL query:''' (importbuddy.php)
 
* Something went wrong attempting to import this row into the database.
 
* If it says duplicate table or row then the user is importing/migrating into a database that has an existing WordPress installation with the same prefix. This could cause problems if it's a different install or a lot has changed.
 
 
 
==9011==
 
'''ERROR #9011.  FTP/FTPs login failed on scheduled FTP. Credentials: username:password@server.com.'''
 
* Unable to log in to FTP or FTPs server due to a problem with the login credentials. Verify your username and password.
 
 
 
==9012==
 
'''FTP/FTPs file upload failed. Check file permissions & disk quota. Details: [additional details here]'''
 
* BackupBuddy was able to connect to the FTP server but was not able to upload the file.
 
* Verify file permissions allow writing and that enough disk space is available.
 
 
 
==9013==
 
'''Sorry! PHP version x.x or newer is required for BackupBuddy to properly run. You are running PHP version x.x.x.'''
 
* BackupBuddy currently requires PHP 5.x.  See the Sales page or [[BackupBuddy]] codex page for the latest version requirements.
 
* Most hosts allow you to change the PHP version from their control panel.
 
 
 
==9014==
 
'''Fatal error. The database already contains a WordPress installation with this prefix (27 tables). Restore has been stopped to prevent overwriting existing data. Please go back and enter a new database name and/or prefix OR clear our your database prior to restoring again.'''
 
* WordPress already exists in the database/prefix combo entered.
 
* Choose a new prefix, database, or delete the existing WordPress tables from the database.
 
 
 
==9015==
 
'''Temp data directory is not writable. Check your permissions. (#directory#)'''
 
* Verify user permissions for this directory. Make sure the user can create & write files.
 
* Use SUPHP so PHP will run as your user.  This insures it will have proper file/directory permissions.
 
 
 
==9016==
 
'''Archive file is not writable. is not writable. Check your permissions. (#directory#)'''
 
* Verify user permissions for this directory. Make sure the user can create & write files.
 
* Use SUPHP so PHP will run as your user.  This insures it will have proper file/directory permissions.
 
 
 
==9017==
 
'''Temp data file is not creatable/writable. Check your permissions. (#directory#)'''
 
* Verify user permissions for this directory. Make sure the user can create & write files.
 
* Use SUPHP so PHP will run as your user.  This insures it will have proper file/directory permissions.
 
 
 
==9018==
 
'''Database file is not creatable/writable. Check your permissions. (#directory#)'''
 
* Verify user permissions for this directory. Make sure the user can create & write files.
 
* Use SUPHP so PHP will run as your user.  This insures it will have proper file/directory permissions.
 
 
 
==9019==
 
'''Invalid or corrupt AJAX data. (#DATA#)'''
 
* The backup data sent by the browser was invalid. Refresh and try again.
 
* Make sure you are using a modern browser on a stable internet connection.
 
 
 
==9020==
 
'''Unable to write to file [.htaccess/wp-config.php]. Permissions are preventing this file from being modified.'''
 
* Verify write permissions are properly configured for this file. Suggestion: 755.
 
* For .htaccess: Another option is to delete the .htaccess file & in the WordPress admin navigate to Settings: Permalinks & click the Save button to regenerate the file.
 
 
 
==9021==
 
'''PHP Timeout or Fatal Error Occurred'''
 
* "The page did not finish loading as expected. The most common cause for this is the PHP process taking more time than it has been allowed by your host (php.ini setting max_execution_time). If a PHP error is displayed above this can also cause this error. "
 
* Increase the maximum allowed PHP runtime by contacting your host or creating a php.ini file to override host settings (if allowed).
 
* If on the unzip step, manually extract the ZIP file on your local PC then upload or use another server-based software such as cpanel.
 
 
 
==9022==
 
'''Error: Unable to create backup storage directory `/www/wp-content/uploads/backupbuddy_backups/`. Please verify that proper write permissions are enabled to create this directory. You may also manually create this directory. If you do so make sure to give permissions to allow writing backups into this directory.'''
 
 
 
*This error means that BackupBuddy was unable to create a storage directory at the location listed in the error message.  BackupBuddy must create this directory to place backup files into.
 
* Adjust permissions to allow write & directory creation access to your uploads folder. ie: /www/wp-content/uploads/
 
 
 
==9023==
 
'''The backup is of a full Multisite Network. You cannot import a Network into a Network. You may only import standalone sites and sites exported from a Multisite.'''
 
* If you want to import a site from a Multisite Network you must first use BackupBuddy to export a site from it.  You can then import that individually exported site into another Multisite Network using BackupBuddy's Multisite Import or even as a standalone site with importbuddy.php.
 
 
 
==9024==
 
'''ERROR #9024: Connected to Amazon S3 but unable to put file. There is a problem with one of the following S3 settings: bucket, directory, or S3 permissions. Details: ...'''
 
* In the destination settings page click the button to test the connection to verify the settings.
 
* Try manually sending a backup.
 
* See the Details portion of this error at the end for advanced troubleshooting information. This may be helpful for support or the developers.
 
 
 
==9025==
 
'''ERROR #9025: Connected to Rackspace but unable to put file. Verify Rackspace settings included Rackspace permissions, etc.'''
 
 
 
==9026==
 
'''ERROR #9026: The mySQL server went away unexpectedly during database dump. This is almost always caused by mySQL running out of memory. The backup integrity can no longer be guaranteed so the backup has been halted. 'Last table dumped before database server went away: `wp_#####`.'''
 
* Ask host to increase mysql memory.
 
* Reduce database [table(s)] size.
 
 
 
==9027==
 
'''ERROR #9027: The mySQL server went away and was unavailable for scheduling the next cron step. This is almost always caused by mySQL running out of memory. The backup integrity can no longer be guaranteed so the backup has been halted.'''
 
* This is the same issue as 9026 except that it may have happened after a different step than the database dump.
 
* See 9026.
 
 
 
==9028==
 
'''ERROR #9028: Based on your backup archive limits (size limit) the backup that was just created would be deleted. Skipped deleting this backup. Please update your archive limits.'''
 
* Your archive size limit is less than the backup file size. This would result in all backup files being deleted, including the latest, which would result in zero backups. The last backup has been kept for safety.
 
* Adjust the backup size limit to a larger value or reduce the size of your backups by deleting files or excluding directories.
 
 
 
==9029==
 
'''Error #9029: Table `TABLE_NAME` does not contain a primary key; BackupBuddy cannot safely modify the contents of this table. Skipping migration of this table. ([serialized()|bruteforce_table()])'''
 
* This table is not set up properly. All tables should have a PRIMARY key and/or a UNIQUE key. Mysql automatically returns the first fully unique key if available if a primary key does not exist.
 
* If a plugin created the reported table contact the author to have this corrected.
 
 
 
==9030==
 
'''mysqlbuddy: Error #9030. Command did not exit normally. Falling back to database dump compatibility modes.'''
 
* Occurs when command line mysql is reported to be available but still failed. BackupBuddy cannot always capture command line mysql error messages.
 
* Common causes:
 
** One or more tables that was attempted to be imported already existed.
 
 
 
==9031==
 
"Error #9031. Invalid backup serial (xxxxxxxxxx). Please check directory permissions and your PHP error_log as an early backup function (such as pre_backup) may have failed. Fatal error."
 
* This is a fatal error which will halt the backup process. You must fix whatever is causing it before BackupBuddy can continue.
 
* This basically means that when BackupBuddy tried to load backup information for the unique backup your browser requested information on, no information was found. Please try the following fixes:
 
**1 : Fix the file and folder permissions on all your BackupBuddy folders and the wp-content/uploads folder to allow proper writing permissions.
 
**2 : Make sure you have plenty of free disk space.
 
**3 : Upgrade to the latest version of BackupBuddy to make sure you are not encountering any old bugs or we have improved workarounds for your server issue.
 
 
 
*Related forum threads
 
**[http://ithemes.com/forum/index.php?/topic/13796-error-5445589-invalid-backup-serial/ File permissions causing 5445589 error]
 
**[http://ithemes.com/forum/index.php?/topic/14834-error-5445589-invalid-backup-serial-0i64w23keq-fatal-error/ Increase the available disk space]
 
 
 
 
 
 
 
==9032==
 
''BackupBuddy Error #9032: You have not set a password to download this script yet. Please do so on the Settings page. You should have been prompted for a password when you clicked to download this script. If you are seeing this then most likely another plugin is loading its javascript on our plugin page causing it to break. Try disabling all other plugins to see if that fixes it. If so then turn them back on one by one until you find the offending plugin. You may also view your browser javascript error console to check for any script errors to help diagnose the issue.''
 
 
 
 
 
==9033==
 
"Error #9033: The pre-backup initialization did not fully complete. Check for any errors above or in logs. Verify permissions & that there is enough server memory. See the BackupBuddy "Server Information" page to help assess your server."
 
* One known cause: Server ran out of memory at some point during the pre_backup() initialization procedure, possibly during importbuddy generation.  Check PHP error log for memory errors.  Increase server memory for probably fix.
 
 
 
==9034==
 
* Check file permissions on the reported file and its directory.  If still experiencing problems verify ownership and/or that suphp is installed and properly configured on the server. Contact host for details.
 
 
 
==9035==
 
''Error #9035. Unable to move restored file `/var/folders/hq/vmq2b8xs4dgd3f4dzrv21gqw0000gn/T/31q9bfispb/myfolder/` to `/Users/dustin/Sites/backupbuddy.com/www/myfolder/`. Verify permissions on destination location & that the destination directory/file does not already exist.''
 
* If restoring a directory verify that the destination directory does not already exist. BackupBuddy will not replace a non-empty directory to avoid deleting any files within the existing directory inadvertently.
 
* If restoring a file verify file permissions allow overwriting.
 
 
 
==9036==
 
'''Error #9036. The destination directory being restored already exists and is NOT empty. The directory will not be restored to prevent inadvertantly losing files within the existing directory. Delete existing directory first if you wish to proceed or restore individual files. Existing directory: `/Users/dustin/Sites/backupbuddy.com/www/myfolder/`.'''
 
* The directory you are restoring already exists on the site.  At this time directories cannot be merged so the existing directory would need to be deleted prior to restore. As this could result in inadvertently losing files in the directory we require that you manually delete the directory if you wish to proceed.
 
 
 
==9037==
 
'''Error #9037: Unable to connect to remote server or unexpected response. Details: Operation timed out after 28000 milliseconds with 0 bytes received - URL: http://yoursite.com/.'''
 
* Verify your remote site is up and running, with BackupBuddy activated and the remote API enabled. Check your Deployment Settings (such as the API key) and verify they are all correct.
 
* Verify the other server is able to be connected to from this computer. Eg. Connected to the internet or the same LAN.
 
 
 
==9038==
 
'''(Loopback test) -- Warning #9038: Connected to server but unexpected output: `RESPONSE_HERE`. Code: `xxx`.'''
 
* See http://ithemes.com/codex/page/BackupBuddy:_Frequent_Support_Issues#HTTP_Loopback_Connections_Disabled
 
 
 
==3488439==
 
'''Error scheduling event with WordPress. Your schedule may not work properly. Please try again. Error #3488439.'''
 
* This means the built-in WordPress function wp_schedule_event() is returning false. The only thing that can cause that is another plugin or something filtering/blocking scheduling of events. So can try deactivating/disabling all other plugins and then see if it clears it up. If it does then one of them was conflicting and can reactivate the plugins one at a time to find which one causes it again.
 
** Letting the conflicting plugin's author know about the conflict is good to do as well so they can update their plugin and fix it
 
 
 
==4543664==
 
Deprecated as of v6.0.0.3. See Error #8001.
 
 
 
==5445589==
 
'''Error #5445589 – Invalid b/u serial Verify b/u directory writer permission'''
 
* SEE ERROR #9031 ABOVE.
 
 
 
==8483974==
 
Deprecated as of v6.0.0.5. See Error #8002.
 
 
 
==4543849498==
 
'''Error #4543849498. Missing old home URL.
 
Failed. Your current backup does not include a home URL. Make a new backup with the latest BackupBuddy before migrating.'''
 
* Error means that the backup file being used for the migration/restore is much older than the importbuddy version being used.
 
** Use a backup .zip file created from an up to date BackupBuddy (or at least a version not as old)
 
 
 
 
 
==8438934984==
 
'''Error #8438934984: dbimport class missing option in constructor $options variable.'''
 
* Error means that at the point of starting the database import importbuddy is missing one of the following: backup file identifier (the random 10 character string at the end of the backup file name); the database server address; the database name; the database user; the database password; the table prefix to use; or the table prefix that was previously used.
 
* Especially for the cases where migrating to a local server with root having no password
 
** For that case then the resolution is to create a database user and associated password and associate these with the specific database (as would be the case on a commercial host) and then use that user rather than "root".
 
 
 
* Related forum threads:
 
** [http://ithemes.com/forum/topic/21500-restore-error-8438934984/page__p__100824#entry100824 Restore Error 8438934984]
 
 
 
=See also=
 
*[[BackupBuddy:_Frequent_Support_Issues|Frequently-Seen Support Issues]]
 
*[[BackupBuddy_Troubleshooting:_Common_Mistakes|Common Mistakes]]
 
*[[BackupBuddy:_Error_Codes|Error Codes]]
 
 
 
<br />
 
[[:BackupBuddy|← Back to BackupBuddy Codex Home]]
 

Latest revision as of 20:41, 16 February 2016

Basic Troubleshooting Steps

Initial Investigation

Show Status Log

To get the Stash Live Status Log please navigate to "Stash Live" pages -> Scroll down to the bottom of the page and select the "Show Advanced Troubleshooting Options" button -> Select "View Status Log". Please copy/paste this into a text file and attach it to your support ticket.

Misc

  1. "Settings" page -> "Recent Activity" tab. Check for Live errors.
  2. If the current status indicates everything is "Up to date" but the stats indicate otherwise or something 'odd', "Stash Live" pages -> "Show Advanced Troubleshooting Options" button -> click "Restart Periodic Process" button.
  3. If the files are not progressing or stuck at zero, see the Remote Destinations page Recent Transfers list to check for file transfer issues.

Deeper Investigation

  1. After looking through the current Status Log for clues, Clear the current Status Log.
  2. Restart the Periodic Process.
  3. Check the Status Log for new clues, refreshing as needed (until auto update is added to the log viewing).

Symptom Presentations

Database and Files status indicators both are stuck at ZERO (0) files.

Files status indicator has not progressed in a while.

  • Could be caused by one or more remote file transfers is failing. See File Transfer Problems below.
  • Could be caused by another issue. See the Status Log for details on the most recent messages, including recent errors, warnings, and which step keeps repeating (if any).

Files status indicator stuck at 99%.

  • This is a strong indicator that a file or two is unable to send. It may be a very large file or having some other problem. See File Transfer Problems below.
  • Could be caused by another issue. See the Status Log for details on the most recent messages, including recent errors, warnings, and which step keeps repeating (if any).


File Transfer Problems

File-send-error.jpg

Stash Live needs to be able to send files to the Stash servers for storage. Any problems with file transfers can cause various processes to get 'stuck' or error.

  • Navigate to Remote Destinations -> View recently sent files to see if errors are noted. You may also be able to hover and view error logs if they still exist.
    • Click the image to the right for a larger view of this.
  • If the problem is a single file or directory of problematic files you may consider excluding.
  • Stash Live will typically restart its process after some type has passed (within 12 hours), including resending failed files.
  • After resolving any file transfer issues make sure to Pause the Files process and use the Advanced Option to 'Reset Send Attempts'.


Error #389383: Unable to initiate multipart upload. Details: `[curl] 60: SSL certificate problem: unable to get local issuer certificate


Reset File Transfers

File-send-error.jpg
  1. On the Stash Live page PAUSE the Files section.
  2. Wait until the Files process finishes if it was in the process of sending files (up to approximately 30 seconds usually) for the file transfer number to stop increasing.
  3. Scroll down to the bottom, expand "Advanced Troubleshooting Options".
  4. Select "Reset Send Attempts".
  5. RESUME the Files section of Stash Live.
  6. If transfer failures are expected, navigate to BackupBuddy -> Remote Destinations -> Select the "View recently sent files" and look for any errors listed or in the log. See the thumbnail to the right.

Advanced Troubleshooting Buttons

At the very bottom of the Stash Live page there are several troubleshooting buttons you may find useful. Note that it is best to PAUSE the periodic activity (Hit "Pause" in the Files section) and wait for activity in the current background PHP page load to complete so that any changes you make via the buttons below don't get overwritten by the currently running process.


Reset File Audit Times

  • The file audit will not run too often. To bypass this safety mechanism (due to performance) do the following. You may then force this step or restart the periodic process to run it.


Reset Send Attempts

  • Are there too many remote file transfers failed, causing file sends to halt for the day? Reset this to allow the File Send step to be able to run.


Reset First Completion Time

  • Make Live to think this is the very first backup.


Reset Last Snapshot Time

  • Make Live think it's been a long time since the last Snapshot.


Unpause Periodic Without Running

  • Unpause the files/periodic process without triggering it to run right now.


Resume periodic process

  • Resume the periodic (files) process wherever it left off.
  • This is similar to clicking the Files "Resume" button.