Who is this article for?
Incydr Professional and Enterprise, no.
Incydr Basic and Advanced, no.
CrashPlan Cloud, no.
Other product plans, yes.
CrashPlan for Small Business, yes.
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. Try TCP 4280
If you are connecting to your master server over the SSL-based port TCP 4285 and web restore fails, try it with port 4280. Some browsers handle SSL issues more severely than others, so remove SSL from the equation. Perform this test if the master server hosts the storage in the destination (that is, a private cloud deployment). If a storage server is involved, see the next section.
Note: If your security settings require SSL to access the console, first clear the SSL checkbox.
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).