Solid Backups Error Codes

3xxx = Database, 4xxx = Zip, 7xxx = Import, 8xxx = Deployment, 9xxx = Unclassified primary error, Any number 10,000+ = Unclassified, typically rarely seen.

4001

For a Manually initiated backup the Backup Overview tab may show:

Error #4001 Unable to successfully generate ZIP archive. Backup FAILED. See logs above for more information. Click to view error details in the Knowledge Base

or the detailed Status Log tab may show:

Error #4001: Unable to successfully generate ZIP archive. Backup FAILED. See logs above for more information.

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 Solid Backups 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 webserver process or it might be impossible because the site is out of disk space. The main thing to look for here is the Zip process exit code: ##

NOTE: The 4001 condition in BackupBuddy v5+ and the 3382 condition in BackupBuddy pre-v5 are synonymous

You can find more detailed explanations of some of the exit codes produced by the 4001 error below:

Exit Codes 10, -10, -1, and 14: This indicates a lack of disk space available on the hosting server. You may need to free up some space on your hosting and/or have your host increase the disk quota. If you have quite a few backups, you may want to try and remove any that you do not want. Possibly storing them on your personal computer and/or to an offsite storage location of your choosing.

Exit Code -4: That specific “Zip process exit code: 4” is returned by your server and it means that your problem is most likely due to the server’s zip utility being unable to allocate memory for one or more buffers during the program initialization.
http://www.info-zip.org/FAQ.html#error-codes
You may need to refer that to your host for assistance.

In the meantime, go to the settings page -> Zip Method Strategy -> set that to Force Compatibility and see if that makes a difference:
Solid Backups -> Settings -> Advanced Settings/Troubleshooting -> Zip -> Zip method strategy -> Force Compatibility
(Please be sure to click “Save Advanced Settings”. Then try again.)
Please set this back to “Best Available” if it doesn’t help.

If adjusting the “Zip Method Strategy” doesn’t help, you could always try using the Alternative Zip System with its default settings.
Solid Backups -> Settings -> Advanced Settings/Troubleshooting -> Zip
Select Alternative Zip System
Just select that and save it with the default settings. Then try again. You’ll want to try it both with the “Zip method strategy” set to “Best Available” and “Force Compatibility”. If it works with “Best Available”, that’s the one you’ll want to use.

If none of those Solid Backups settings work, you’ll need to refer that “zip process exit code of 4” to your host for assistance.

Exit Code 5 (Internal Logic Error): The “Zip process exit code” of 5 is returned directly by your server and means there is an internal logic error and that this should never happen as it indicates a programming error of some sort on the server. Basically, this indicates something is broken with the server. It’s possible that it is being caused by a more standard issue like a lack of disk space which would normally be represented by a different exit code though. So you could try deleting some stuff to free up some disk space and/or increase disk quota.

Another possibility, that once again would normally show up as a different exit code, is that the host has a fixed cap on maximum file size (of any file, not just this type of file). Like perhaps your host limits the creation size of files to 64 MB as the error appears right before it hits that mark.

The standard thing to do would be to try again and see whether you get the same behavior or different behavior that might indicate the above as being some transient server failure condition. But if it does persist you will need to refer to your host support as the issue is arising in the operation of the host provided command line zip utility.
http://www.info-zip.org/FAQ.html#error-codes

Exit Code 9 and 137: This indicates a number of different possible errors, but they all revolve around your hosting provider prematurely killing off the process. Here are a couple of different potential solutions:

1) At the settings page, uncheck zip compression and see if that makes a difference. Solid Backups -> Settings -> Advanced Settings/Troubleshooting -> Zip -> Enable zip compression -> (Please be sure to click “Save Advanced Settings”.)

2) Please try enabling the “Alternative zip system” with it set to “Multi-Burst/Single-Step”:

Solid Backups -> Settings -> Advanced Settings/Troubleshooting -> Zip
Select Alternative Zip System
Set Zip Build Strategy to “Multi-Burst/Single-Step” if not already.

Leave the rest of its options at their defaults, save settings then please try again.

Exit Code 12: The Zip process exit code 12 and the associated zip error reported by your server indicates that the host provided command line zip utility was unable to scan the site installation to build up the list of files for inclusion. This implies that the host web server process under which the host command line zip utility was running did not have sufficient access rights to be able to access the site installation directory. To be able to list the contents and do a recursive look into the sub-directories thereof.

You will need to please refer to your host support for them to advise on how their command line zip utility running under the web-server process can be enabled to allow you to access your site installation directory (you can supply them with my entire reply if need be).

In the meantime, you might try setting this option to “Force Compatibility”:
Solid Backups -> Settings -> Advanced Settings/Troubleshooting -> Zip -> Zip method strategy ->
Then save settings.

As that will force Solid Backups to use WordPress’ PCLZIP utility instead of your server’s command line zip utility.

Exit Code 18: This indicates that there is a file that the backup process found to be unreadable. This could indicate a number of things from a corrupted file to one with improper permissions or a locked file put in place by the hosting provider. The easiest way to get the backup to complete is to exclude that file Solid Backups -> Settings -> General Settings -> File & Directory Defaults -> Other. You can also work with your hosting provider to determine why that file is unreadable.

Exit Code: 24 and 152: This means that your CPU time limit (cap) was reached. You might try disabling zip compression here:

Backup Buddy -> Settings -> Advanced Settings/Troubleshooting -> Zip -> Enable zip compression

Just uncheck that and save the settings. Then see if it will make a Complete Backup.

If it doesn’t, then it means most likely that your host has set a cap on you CPU allocation and you may wish to contact them to see if there’s anything they can do for you. If need be, you can refer them to this link:
https://wiki.ncsa.illinois.edu/display/MRDPUB/Batch+Exit+Codes

Exit Code 126: The “Zip process exit code” of 126 is returned by your server and it means that the server is failing to run the server’s command line zip utility for some reason. You would need to refer this to your host’s support for them to investigate as to why the server is failing this way.

In the meantime, you could try setting this to “Force Compatibility”:
Solid Backups -> Settings -> Advanced Settings/Troubleshooting -> Zip -> Zip method strategy -> Force Compatibility -> Save Settings
That way it will use WordPress’ PCLZIP utility instead of your server’s command line zip utility.

Exit Code 153 and 159: This means that your problem is most likely due to a hosting file size creation constraint. You will need to check with your host to find out what the file size creation limitation is. Your host may be willing to increase the limit.

Exit Code: 255: This means that your server’s command line zip utility is not working correctly and the host would need to investigate why. When contacting your host, you can show them that Zip process exit code that your server is reporting.

Or you could change this from the default of “Best Available” to “Force Compatibility” to just use the WordPress PCLZIP utility instead.
Solid Backups -> Settings -> Advanced Settings/Troubleshooting -> Zip -> Zip method strategy ->

8001

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]

  • 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. If needed, you can see how to edit the wp-config.php file in this article. 
  • Verify you have the correct API key entered and that the URL in the error message is valid.

8003

Warning #8003: 404 retrieving remote log ` http://yoursite.com/XXX` . This may or may not be normal.

  • During the Deployment process Solid Backups will request the remote Standalone Importer 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.

9002

Error #9002: Solid Backups 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 Solid Backups was unable to create a storage directory (such as for backups, log files, temporary files, etc) at the location listed in the error message. Solid Backups must be able to create this directory to function properly.
  • Adjust permissions to allow write & directory creation on the parent directory as specified. ie: /www/wp-content/uploads/
  • Optionally manually create the directory and set permissions.

9003

Solid Backups 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 the integrity of any existing data.

  • This error is often caused by the importbuddy.php script being replaced by an older version during the unzip step. See 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.
    • 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.
    • Disk Quota. Please make sure that you are not hitting any disk quota. You may need to contact your host to verify that your server has plenty of space for the backup file to be extracted completely.

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.

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.
  • Please make sure you are using the latest version of importbuddy.php as the latest versions of Solid Backups are backward compatible.
  • Please make sure you did not rename the backup file. Renaming the backup file could cause importbuddy to not be able to locate the database backup files.

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.

Error: Unknown collation: utf8mb4_unicode_520_ci

  • Please check the importbuddy.txt status log for something like the following:
  • 17:46:51.95 0.02sec 2.24MB Setting charset to `utf8mb4` and collate to `utf8mb4_unicode_520_ci` based on source site.
    17:46:51.95 0.02sec 2.24MB Incoming mysql version: `5.6.34`. This server’s mysql version: `5.5.51`.
  • The server that the site (backup) was created on was using MySQL 5.6.34 and in that case WordPress will create the WordPress core database tables using that collation type (which is only available from MySQL 5.6+) and so WordPress has created a database that is incompatible with earlier versions of MySQL (which the new server is using MySQL 5.5.51). They (WordPress) did this before when they forced the use of utf8mb4 charset/collation when MySQL 5.5+ was in use and thus made the database incompatible with versions of MySQL prior to that.
  • The best solution is to have host update the hosting account to use a more up to date version of MySQL which matches what was used on the site/server where the backup came from.

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.
  • Please make sure the FTP remote destination is still set up correctly by going to Solid Backups’ -> Remote Destination page and clicking the gear wheel next to the FTP remote destination’s tab. Then click to test the settings to make sure they are still working.

9012

FTP/FTPs file upload failed. Check file permissions & disk quota. Details: [additional details here]

  • Solid Backups 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.
  • Try changing the “Transfer mode” from Passive (default) to Active (or vice versa if that is the case). Solid Backups -> Destinations -> My FTP -> Advanced Options -> Transfer mode -> (please make sure to save the settings)
  • Does the IP Address have a specific domain associated with it? With some hosts, it seems to work better if the domain name is used instead of the IP Address.
  • Is it possible for you to create a directory on your FTP server and call it “backups” (without the quotes), then for the “Remote path (optional)”, click the “Browse & Select FTP Path”, locate it that way and set it as the remote path? If that doesn’t help, will it work better if you just leave the path empty and allow it to send the backup file there right in the root?
  • If the FTP connection is valid, check the FTP server logs for errors (these logs will be on the FTP remote server, not the server where the site is located). Because if there is a valid connection and sends are not completing, there should be errors in the FTP server log: https://en.wikipedia.org/wiki/List_of_FTP_server_return_codes
  • Is the server where you are running Solid Backups and sending the backup file from have its PHP error logging enabled? If so, please check that error log for any mentions of Solid Backups and/or for any sort of timeout.

9013

Sorry! PHP version x.x or newer is required for Solid Backups to properly run. You are running PHP version x.x.x.

  • Solid Backups currently requires PHP 5.x. See the Sales page or Solid Backups 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.

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.

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.
  • As you need a typical read/write file permission/ownership of the files/directories.
    644 for files
    and
    755 for directories
    https://codex.wordpress.org/Changing_File_Permissions
  • Use SUPHP so PHP will run as your user. This insures it will have proper file/directory permissions.
  • It’s also possible that you’re hitting some sort of disk quota. You may need to free up some space on your hosting or have your host increase the disk quota. If you have quite a few backups, you may want to try and remove any that you do not want. Possibly storing them on your personal computer and/or to an offsite storage location of your choosing.

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.
  • If your hosting utilizes server side caching like Varnish, please try disabling the server side caching.

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 Solid Backups was unable to create a storage directory at the location listed in the error message. Solid Backups 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 Solid Backups to export a site from it. You can then import that individually exported site into another Multisite Network using Solid Backups’ 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 the 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.
  • First, please see what you have set here:
    • wp-admin (dashboard) -> Solid Backups -> Settings -> General Settings -> Local Archive Storage Limits -> Size limit of all local backups combined ->
    • By default it’s set to “0” (without the quotes).
  • For example, if the backup is 500 MB, but you have a size limit set in those settings to 300 MB, then the newly made backups will exceed the set size limit and will be removed right after getting created. So you would want to increase the size limit so that it’s no longer an issue. (By default it’s set to “0” zero without the quotes.)
  • If that looks to be correct, then you’ll also want to see what you have set here:
    • wp-admin (dashboard) -> Solid Backups -> Settings -> Advanced Settings/Troubleshooting -> Basic Operation -> Maximum local storage usage ->
    • By default it’s set to 50000. If you adjust that, you’ll want to please make sure that it will account for all of your backups and is higher than any other local archive size limits. This second option is meant to be a safe guard. As a lot of users do not adjust the local archive limits and leave them at their defaults of “0” zero.

9029

Error #9029: Table `TABLE_NAME` does not contain a primary key; Solid Backups 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 please 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. Solid Backups 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 Solid Backups can continue.
  • This basically means that when Solid Backups 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 Solid Backups folders and the wp-content/uploads folder to allow proper writing permissions. https://codex.wordpress.org/Changing_File_Permissions
    • 2 : Make sure you have plenty of free disk space. You may need to contact your host to make sure you’re not hitting any disk quota.
    • 3 : Upgrade to the latest version of Solid Backups to make sure you are not encountering any old bugs or we have improved workarounds for your server issue.
    • 4 : There could be a plugin/theme conflict. To check for a plugin conflict you can temporarily deactivate all other plugins, and then see if it works better. If so, then you now know that one or more of the plugins were conflicting and you can reactivate the plugins one at a time to find which one(s) causes the conflict. To check for a theme conflict, please temporarily activate a default theme like TwentySeventeen.

9032

Solid Backups 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 Solid Backups “Server Information” page to help assess your server.”

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.
  • Please make sure you have plenty of free disk space. When contacting your host, please make sure you are not hitting any disk quota.
  • There could be a plugin/theme conflict. To check for a plugin conflict you can temporarily deactivate all other plugins, and then see if it works better. If so, then you now know that one or more of the plugins were conflicting and you can reactivate the plugins one at a time to find which one(s) causes the conflict. To check for a theme conflict, please temporarily activate a default theme like TwentySeventeen.

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. Solid Backups 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 inadvertently 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 Solid Backups 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`.

9040, 9041, 9050, 9051

Error #9050 Could not connect to destination using FTP.

All four of these errors are generic errors in regards to an FTP remote destination not being able to connect to the FTP server.

9040 and 9041 are more specific in regards to FTPs. FTPs is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer (SSL).

If you see a 9040 or 9041 error, please check that the FTPs credentials are correct, make sure that site’s server can connect to the FTPs address via the FTP(s) port (21), and that your site’s server supports FTPs via PHP.

Note that FTPs is NOT the same as sFTP (FTP over SSH) and is not compatible or equal. (The PHP Library that Solid Backups uses supports Explicit Encryption and not Implicit Encryption. Which means that services like Citrix ShareFile may not work as they no longer use Explicit Encryption and only use Implicit Encryption.)

Similarily, if you see a 9050, or 9051 error, please check that the FTP credentials are correct, make sure that site’s server can connect to the FTP address via the FTP port (21), and that your site’s server supports FTP via PHP.

32893

This error number indicates an error being reported from the server. Usually either related to the max_execution_time and/or memory exhausted (site running out of memory).

If the error is similar to the one below:

  • Fatal PHP Error: PHP_ERROR Error #32893. Fatal PHP error encountered:type => 1; message => Maximum execution time of 60 seconds exceeded; file => /var/www/vhosts/example.com/httpdocs/wp-admin/includes/class-pclzip.php; line => 2007; .
  • Please see if enabling the following option helps:
  • Solid Backups -> Settings -> Advanced Settings/Troubleshooting -> Basic Operation -> Attempt to override PHP max execution time ->
    Just check that, then save settings and try again.
  • Otherwise you may need to contact your host on how to increase it. (This is better over the plugin’s option if you are able to adjust it.)
    https://ithemeshelp.zendesk.com/hc/en-us/articles/360035793754-Adjusting-the-Max-Execution-Time

If the error is similar to the one below:

  • Error #32893. Fatal PHP error encountered:type => 1; message => Allowed memory size of 134217728 bytes exhausted (tried to allocate 2726079 bytes); file => /var/www/vhosts/example.com/httpdocs/wp-admin/includes/class-pclzip.php; line => 2690; .
  • It means that your site ran out of memory and that you’ll need to please contact your host to increase the memory allocated to your site.

If the error is similar to the one below:

  • Fatal PHP Error: PHP_ERROR Error #32893. Fatal PHP error encountered:type => 1; message => Call to undefined method SplFileObject::eof();
  • That means that there is possibly an issue with the PHP installation on the site/server with regard to the Standard PHP Library (SPL) SplFileObject Class as described in the PHP manual: http://php.net/manual/en/class.splfileobject.php and that you’ll most likely need to please contact your host support to investigate the PHP installation and the provision of this SPL functionality which has been standard in PHP since PHP 5.1.0.

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

439743

Error #439743 A javascript error occurred which MAY prevent the restore from continuing. _IF_ the process lets you proceed then ignore this message. Check the Status Log or browser error console for trace details.

  • Please try a different browser. It’s possible that your browser is interfering (or possibly a browser extension/add-on) and/or something on your server is causing this.
  • Please make sure that the importbuddy.php file is not renamed something like importbuddy(1).php. In such cases where the file is renamed when downloaded because there is one in existence previously. The file cannot be renamed. Also, the same thing could happen to the actual backup file when downloaded. So please make sure that it is not renamed either.
  • If there are any server side implementations like Varnish, XCache, Google PageSpeed, CloudFlare, mod_security, Sucuri Firewall, etc., they may need to be temporarily disabled for the time being.
  • While checking for server side implementations, it would be a good idea to see if there are any server configuration files (.htaccess, php.ini, user.ini, etc.) in the web-root where you are running importbuddy.php. **Even if they were extracted from the backup.** If there are any, please temporarily rename them to something like .htaccess.bak, php.ini.bak, user.ini.bak, etc. (This is also good to check if you use the Wordfence plugin and its WAF option as that breaks site portability.)
  • You might try a different importbuddy.php file. Usually it’s best to use one from a site that’s using the most recent version of Solid Backups.

4839484

Errors were encountered: Error #4839484: The backup may have failed opening due to lack of memory, permissions issues, or other reason. Use Standalone Importer to restore or check the Advanced Log above for details. If seeking support please click to Show Advanced Details above and provide a copy of the log.

  • Please make sure that you are not hitting any disk quota. You may need to contact your host to verify that your server has plenty of space for the backup file to be extracted completely.
  • For file/directories, you need typical read/write permission/ownership of the files/directories.

5657667675

  • This error may occur when trying to delete the cron jobs on the Diagnostics -> Cron page:
    wp-admin (dashboard) -> Solid Backups -> Diagnostics -> Cron
    By either selectively deleting “Scheduled Events” or by clicking the “Delete All Cron Entries” button. If you received this error by clicking the “Delete All Cron Entries”, please try selecting one a time instead.
  • Usually this option is ran when there is an issue with the WordPress cron. And there is a very old event that seems to be stuck. If you are unable to delete the event, and backups are not completing due to the stuck event, please try disabling the the “Limit to one action per cron pass” on the “Advanced Settings/Troubleshooting” page:
    wp-admin (dashboard) -> Solid Backups -> Settings -> Advanced Settings/Troubleshooting -> Basic Operation -> Limit to one action per cron pass
    By unchecking that and saving the settings.

82389

Error #82389: A javascript error occurred which may prevent the backup from continuing. Check your browser error console for details. This is most often caused by another plugin or theme containing broken javascript. See details below for clues or try temporarily disabling all other plugins.

Error #82389 is usually caused by a plugin/theme conflict or possibly some server side caching. But if you click the “OK” button, the error message should go away and the backup should continue on.

If it doesn’t and/or if you would like to find out what is causing that error message, please see the following:

  • First, please try deactivating all plugins to check for a plugin conflict. Then please make sure that if you do any sort of caching of the site, whether it be by a plugin or server side (server side examples are XCache, Varnish, Google PageSpeed, Cloudflare, etc.), that all caching is deleted. Sometimes .htaccess rules like browser caching and/or compression, may need to be checked as well.
  • In a few instances, I have seen a conflict with a theme cause this as well. So you might try switching to a default theme like TwentyTwenty temporarily, to just see if the error goes away. I’ve actually seen themes that do not enqueue their scripts correctly and they actually load on all of the admin pages. (Basically, another plugin/theme is running on Solid Backups’ pages when it shouldn’t be.)
  • You might also try a different web browser to rule out conflicts with a browser plugin/add-on/extension. Sometimes clearing the browser cache helps as well. http://www.wikihow.com/Clear-Your-Browser’s-Cache
  • Another thing to check would be to see if there are there any errors in the javascript error console on the page breaking things. As it might list the specific culprit. Getting to the error console varies a little for each web browser but for Firefox for example it is usually Tools -> Web Developer -> Web Console -> Errors tab (or press Ctrl + Shift + J).
    https://wordpress.org/support/article/using-your-browser-to-diagnose-javascript-errors/
  • If you see some sort of “Access is denied” message, it could also mean some security implementation (like mod_security, Sucuri Firewall, CloudFlare, .htaccess) is blocking it. You might need to look at your server logs for any messages at the time you attempted this.

843948

Error #843948: Unable to write to SQL file.

  • This error appears when the server process ran into a problem trying to add additional content to the database dump file. The most likely cause would be a disk space/quota issue and deleting some stuff or having your host increase the disk quota should resolve that and allow your backup to progress further. (It might also be a file/directory permission/ownership issue, but it’s probably best to look into the disk space/quota first.)
  • You might also try setting the Solid Backups -> Settings -> Advanced Settings/Troubleshooting -> Database -> Database Method Strategy to “Commandline: Fast but does not support resuming” (if indeed your server will support that) and see if that produces any different behavior or additional information about the problem.
Have more questions? Submit a request