Who is this article for?
Code42 for Enterprise, yes.
CrashPlan for Small Business, no.
This article presents several tips for troubleshooting failures during web restore (restores performed through the console). These troubleshooting tips apply to single server and multi-server environments. Please follow these troubleshooting suggestions in the order presented.
- From the client browser initiating the web restore to the master server on TCP 4280 (HTTP) OR
- From the client browser initiating the web restore to the master server on TCP 4285 (HTTPS)
Multi-server private cloud environments:
In addition to the requirements for a single server, performing a web restore from an archive that resides on a storage server requires the following:
- The master server and the storage server must be configured with the same SSL access requirement (under Settings > Security)
- The web browser for the client initiating the web restore must be able to connect to the master server and the storage server. Web restore fails if a connection cannot be made to the master server or to the storage server that holds the archive.
Though not required, installing a CA-signed SSL certificate on all servers minimizes web restore browser-related issues.
CrashPlan PROe hybrid environments:
Performing web restore from an archive stored on the CrashPlan PROe Cloud requires SSL for all connections. The master server browser connection must be established on TCP 4285, so that the subsequent connections to the CrashPlan PROe Cloud are SSL-grade.
CrashPlan PROe cloud environments:
When performing web restore from an archive that resides at the CrashPlan PROe Cloud, the client browser performing the web restore must be able to connect to the CrashPlan PROe Cloud on TCP 4285.
The request is initiated by the client browser. However, if the client-side firewall blocks client-initiated communication on TCP 4285, the web restore pane does not display. Generally, this occurs only in the most restrictive firewall situations, as most firewalls allow client-initiated requests.
1. Validate the configuration
Verify that the website protocol, host and port settings are configured correctly for all enterprise servers in your environment, including all storage servers.
In standard configuration, the website port is TCP 4280 (HTTP) or TCP 4285 (HTTPS).
If the master server is configured to use a private IP or a local hostname and a web restore is initiated from an endpoint with an external address, the restore will fail due to the client's inability to connect to the master server. The same requirement applies to any storage servers in the destination used by the endpoint. In a multi-server scenario, the master server and the storage servers require unique connections from the browser that is initiating the web restore.
Note for servers configured to use a private IP or hostname: The web restore will fail if you attempt to initiate a web restore from an external address.
When attempting to restore an archive located on a storage server, test the connection from your location by pointing your browser directly at the storage server.
2. Test connectivity
Several ports must be configured correctly for CrashPlan PROe web restore to operate.
Often, software firewalls on the client-side are the root cause of connection failures. For example, a push restore to a CrashPlan app device requires in-bound access on port 4282. A standard Windows workstation with Windows Firewall enabled does not permit this operation and push restore fails. A telnet or browser connection test will confirm this.
You can use the command line utility telnet to confirm that each entity (master server, storage server, client browser) can connect to each other as required.
Test the connection from the client system by pointing a web browser directly at the server's website, host and port address. A successful browser connection displays a sign-in screen.
3. Test connection to the storage server
Code42 environments with a dedicated on-premises storage server only.
Attempting to connect directly to the storage server can help determine if there is a problem with the SSL certificate on the storage server. To connect to the storage server:
- Sign in to the Code42 console.
- Select Devices > Active (version 6.5 and later). Before version 6.5, select Devices.
- Select the device containing the archive you want to restore.
The device details appear.
- Near the top of the screen, note the name of the Store Point.
- From the main menu on the left, select Storage > Store Points.
The list of all store points appears.
- For the store point containing the archive, click the name in the Server column.
The server details appear.
- In the General section, note the Website protocol, host and port of the storage server.
- In a new browser window, navigate to the storage server's Website protocol, host and port.
- If the browser indicates a certificate warning, accept the warning and add the storage server address to the list of the web browser's trusted sites.
If web restore works after these steps, there is a problem with the SSL certificate on the storage server. See our guide for installing SSL certificates for more information.
4. HTTPS/SSL with Firefox
If you do not use a CA-signed SSL certificate for your server(s) and you are using Firefox to perform the web restore (via HTTPS), end users must add an exception for the site in their browser configuration before attempting a web restore. Most browsers prompt the user for proper handling of a self-signed SSL certificate; however, Firefox does not.
5. Try another browser
Web browsers handle issues with web restore differently, especially when multi-server connections are required. If web restore fails in one browser, it may work in another. At a minimum, try Google Chrome and the latest version of the native OS-based browser: IE (Windows) or Safari (Mac).
6. Stay current
Verify that you are running the latest version of enterprise server on your master server and all storage server.
If you're still having trouble with web restore, please contact support. Support may require your browser's “Developer Tools” console output, and / or the PROe logs from your client and server(s).