Skip to main content
Code42 Support

Recover your enterprise server to a previous state

Applies to:
  • CrashPlan PROe

Overview

You can use the enterprise server's Import Database functionality to effectively recover your enterprise server to a previous state. This process is used in several scenarios, such as:

  • Recovering your enterprise server after a hardware failure
  • Moving your enterprise server to new hardware

This process is intended for use with your master server. In most circumstances, we recommend using a simpler process to recover a storage server.

Considerations

Many situations that require recovering an enterprise server can result in data loss. Contact our Customer Champions for CrashPlan PROe support or CrashPlan PRO support if you have any questions or encounter any errors in this process.

Definitions

database dump

A copy of the Code42 environment's internal database. Each enterprise server "dumps" a copy of its internal database to the filesystem on that enterprise server as part of scheduled daily services.

recovery log
A log that records enterprise server activity in order to supplement your enterprise server database with information about activity that occurred since the most recent database dump. It logs events such as user and organization creation or configuration changes. The recovery log cannot act as a replacement for your enterprise server database.
old server
Your existing enterprise server; the source of the recovery or move operation.
new server
Your new enterprise server; the destination of the recovery or move operation. In some situations, your new server may use the same physical hardware or virtual environment as your old server.

Step 1: Prepare your Enterprise servers

The preparation steps differ depending on whether you are:

Preparing to recover an Enterprise server

To recover a malfunctioning enterprise server to a previous state using the same hardware, you must choose one of the following options:

Option A: Recover to previous state with subsequent changes

In most situations, we recommend recovering your enterprise server using a database dump and a supplementary recovery log. To recover to a previous state and apply subsequent changes, you must create a specific "trigger" file to instruct your enterprise server to apply any changes made after the database dump occurred.

On your new server's file system, perform the following steps:

  1. Open a command-line interface:
  2. Version 4.2.x and earlier: Combine all the recovery log files into a single file.
    1. Navigate to the enterprise server's main application directory:
      • Linux: /opt/proserver
        Applies to enterprise servers installed as root on Ubuntu
      • Windows: C:\Program Files\CrashPlan PROe Server
      • OS X: /Applications/PROServer.app/
    2. For each recovery log, copy the contents of the individual recovery logs (such as recovery.log.0, recovery.log.1, and so on) into a single file.
      You must paste the contents in chronological order, from oldest to newest events.
    3. Save the file in the main application directory with this name: recovery.log
  3. Place the recovery log trigger file on your new server:
    The presence of a file with the correct name instructs the enterprise server to use the recovery log.
    • Version 4.2.x and earlier:
      1. Navigate to the enterprise server's main application directory:
        • Linux: /opt/proserver
          Applies to enterprise servers installed as root on Ubuntu
        • Windows: C:\Program Files\CrashPlan PROe Server
        • OS X: /Applications/PROServer.app/
      2. In the enterprise server's main application directory, create an empty file with this name: RECOVERY_LOG_TRIGGER
    • Version 4.3.x and later:
      1. Navigate to the enterprise server's log directory:
        • Linux: /var/log/proserver
          Applies to enterprise servers installed as root on Ubuntu
        • Windows: C:\Program Files\CrashPlan PROe Server\logs
        • OS X: /Library/Logs/PROServer
      2. In the enterprise server's log directory, create an empty file with this name: RECOVERY_LOG_TRIGGER

After preparing your server to use the recovery log, continue to Step 2: Import A Database Dump.

How your Enterprise server recovers subsequent changes
In this scenario, your enterprise server performs a two-step process:
  1. Use a database dump to recover to a previous state.
  2. Use the recovery log to re-apply all changes that took place on your enterprise server after the database dump occurred.

Option B: Recover to previous state without subsequent changes

This method is recommended only when you need to revert changes that you do not want and cannot otherwise reverse. Any changes that were made to your enterprise server after the most recent database dump will be lost.

Potential data loss
Note that this method can cause unexpected behavior or data loss. For example, any users who have been created since the database dump would not exist on your enterprise server after the import. Their devices would stop backing up, and their existing archives would not be maintained by the enterprise server.

If you do not want to include changes made to your enterprise server after the database dump occurred, continue to Step 2: Import A Database Dump without taking any additional action.

Preparing to move an Enterprise server

Follow these steps to move your existing, functional enterprise server to new hardware.

Considerations

  • When moving an enterprise server to new hardware, the old server and the new server must use the same network address in order for CrashPlan app devices to transition smoothly. If a different network address is required, you must first follow the steps in Changing An Enterprise server's Network Address.
  • You must have your master license key in order to install the enterprise server software on your new server.

Step 1: Gather resources from the old server

On your old server:

  1. Sign in to your administration console.
  2. Navigate to Settings > Server.
  3. Record your old server's Current server version.
    This information will be used to prepare your new server.
  4. Perform a database dump:
    1. Navigate to Settings > Server.
    2. From the action menu, select Dump Database.
  5. Copy the database dump and all recovery logs from your old server to a separate location, such as an external drive or network storage location:
    File Example Name Default Location On Your Enterprise server
    Database dump proserver-db_1332824401321_2015-12-15_121011.sql.gz
    • Linux: /var/opt/proserver/dumps
      Applies to enterprise servers installed as root on Ubuntu
    • Windows: C:\ProgramData\PROServer\dumps
    • OS X: /Library/Application Support/CrashPlan/PROServer/dumps
    Recovery logs

    recovery.log.0

    recovery.log.1

    recovery.log.2

    Version 4.2.x and earlier:
    • Linux: /opt/proserver
      Applies to enterprise servers installed as root on Ubuntu
    • Windows: C:\Program Files\CrashPlan PROe Server
    • OS X: /Applications/PROServer.app/
    Version 4.3.x and later:
    • Linux: /var/log/proserver
      Applies to enterprise servers installed as root on Ubuntu
    • Windows: C:\Program Files\CrashPlan PROe Server\logs
    • OS X: /Library/Logs/PROServer
  6. In a plain text editor, open the recovery logs.
  7. Verify that your recovery logs date back to the time of your database dump.
    If your recovery logs do not date back to the time of your database dump, stop immediately and contact our Customer Champions for CrashPlan PROe support or CrashPlan PRO support.
  8. Version 4.2.x and earlier: Combine all the recovery log files into a single file.
    1. For each recovery log, copy the contents of the individual recovery logs (such as recovery.log.0, recovery.log.1, and so on) into a single file.
      You must paste the contents in chronological order, from oldest to newest events.
    2. Save the file with this name: recovery.log
  9. Completely power down your old server.
    • This prevents any further activity in your Code42 environment and allows you to use the old server's network address for the new server.
    • Any further activity in your Code42 environment will not be migrated to your new server.

Step 2: Prepare the new server

  1. Verify that the new server uses the same network address as the old server.
  2. Download the enterprise server installer for the same software version that was installed on the old server.
  3. Install the enterprise server software on the new server.
  4. Sign in to the administration console on your new server using your Code42 environment's master license key.

Step 3: Copy database and logs to the new server

  1. Place the database dump and recovery log files on your new server.
    File Example Name Default Location On Your Enterprise server
    Database dump proserver-db_1332824401321_2015-12-15_121011.sql.gz
    • Linux: /var/opt/proserver/dumps
      Applies to enterprise servers installed as root on Ubuntu
    • Windows: C:\ProgramData\PROServer\dumps
    • OS X: /Library/Application Support/CrashPlan/PROServer/dumps
    Recovery log

    Version 4.2.x and earlier:
    recovery.log

    Version 4.3.x and later:

    • recovery.log.0
    • recovery.log.1
    • recovery.log.2

    Version 4.2.x and earlier:

    • Linux: /opt/proserver
      Applies to enterprise servers installed as root on Ubuntu
    • Windows: C:\Program Files\CrashPlan PROe Server
    • OS X: /Applications/PROServer.app/

    Version 4.3.x and later:

    • Linux: /var/log/proserver
      Applies to enterprise servers installed as root on Ubuntu
    • Windows: C:\Program Files\CrashPlan PROe Server\logs
    • OS X: /Library/Logs/PROServer
  2. Place the recovery log trigger file on your new server:
    The presence of a file with the correct name instructs the enterprise server to use the recovery log.
    • Version 4.2.x and earlier:
      1. Navigate to the enterprise server's main application directory:
        • Linux: /opt/proserver
          Applies to enterprise servers installed as root on Ubuntu
        • Windows: C:\Program Files\CrashPlan PROe Server
        • OS X: /Applications/PROServer.app/
      2. In the enterprise server's main application directory, create an empty file with this name: RECOVERY_LOG_TRIGGER
    • Version 4.3.x and later:
      1. Navigate to the enterprise server's log directory:
        • Linux: /var/log/proserver
          Applies to enterprise servers installed as root on Ubuntu
        • Windows: C:\Program Files\CrashPlan PROe Server\logs
        • OS X: /Library/Logs/PROServer
      2. In the enterprise server's log directory, create an empty file with this name: RECOVERY_LOG_TRIGGER

After installing the enterprise server on your new server and placing the database and log files on it, continue to Step 2: Import A Database Dump.

Step 2: Import a database dump

Import a database dump to reset the configuration of your new server to match the configuration of your old server at the time of the database dump.

Choose one of these two methods for importing the database dump:

Option A: Import using the restore_database script

Use the restore_database script to import a database dump. You must use the command line to access the restore_database script, but you do not need your master license key.

  1. On your new server, open a command-line interface:
  2. Navigate to the directory for the enterprise server command-line tools:
    • Linux: /opt/proserver/bin
      Applies to enterprise servers installed as root on Ubuntu
    • Windows: C:\Program Files\CrashPlan PROe Server\bin
    • OS X: /Applications/PROServer.app/Contents/Resources/Java/bin/
  3. Run the restore_database script on the full path of the database dump you want to import.
    Example on a Linux enterprise server:
    sudo ./restore_database.sh /var/opt/proserver/dumps/proserver-db_1332824401321_2015-12-15_121011.sql.gz
    

The enterprise server automatically imports the database dump. Then, if you enabled use of the recovery log, the enterprise server applies the changes contained in the recovery log. This process may take several minutes, depending on the size of your database and your recovery log.

Option B: Import using the Administration console

Use the administration console to import a database dump. You must have your master license key to access the administration console for the first time.

  1. Sign in to your administration console.
  2. Go to Settings > Server > Action menu > Import Database
  3. Select the database you want to import from the chronological list of database dumps.
  4. Click Submit.
    The enterprise server restarts to import the selected database dump. This process may take several minutes.
  5. Sign in to your administration console to verify your changes.

The enterprise server automatically imports the database dump. Then, if you enabled use of the recovery log, the enterprise server applies the changes contained in the recovery log. This process may take several minutes, depending on the size of your database and your recovery log.

Step 3: Verify Store points and archives

If you moved an enterprise server that contains device archives, you must verify your store points and device archives. Otherwise, this step is optional, but recommended.

Verifying Store points

When you have imported your database, the enterprise server expects to find the store points on your new server in the exact location they were on your old server.

  1. Sign in to your administration console on your new server.
  2. Go to Destinations > Store points.
  3. For each store point:
    1. Select the store point to view its details.
    2. Note the Path and Directory listed in Store Point Info.
  4. On your new server's file system, confirm that each store point:
    • Exists at the Path directory
    • Uses the name shown in Directory
    • Grants read, write, and execute permissions to the user account that runs the enterprise server service
Editing Store point settings in the Administration console
If a store point exists on the file system at a different directory, you can edit the settings in the administration console instead of moving the store point on the file system.
  1. Select the store point to view its' details.
  2. Click Action menu > Edit.
  3. Change Path and Directory to match the location of the store point directory on your file system.
  4. Click Save.

Verifying archives

In order for devices to resume backing up, each device's archive from the old server must be in its' corresponding store point directory on the new server's file system.

Action recommended to avoid data loss
Placing devices' current archives in the appropriate store point directory is optional, but strongly recommended. If you do not place existing device archives in the store point directory, each device will restart its backup. As a result, previous versions of files and deleted files will not be included in the devices' backups.

For each store point:

  1. Open a command-line interface:
  2. Use a robust file transfer utility, such as rsync (Linux, OS X) or robocopy (Windows), to copy the store point's device archives to the correct store point directory on the new server.
    Example commands for these recommended file transfer utilities are shown below.
  3. Test one or more device's archives to verify that the copy was successful:
    1. Restore a small set of sample data from a device.
    2. Open the CrashPlan app on a device.

example file transfer commands

Copying data
We recommend using a command line tool like rsync (OS X, Linux) or robocopy (Windows) to copy data. These tools are designed to handle large transfers without failing.
  • Recommended command for Linux or OS X:
    rsync -ah --progress --delete --compress-level=0 --inplace <source> <destination>
    
  • Recommended command for Windows:
    robocopy <source> <destination> /COPYALL /PURGE /MIR