Skip to main content
Code42 Support

Recovering Or Moving Your Enterprise Server

Applies to:
  • CrashPlan PROe
If your enterprise server is damaged, critically malfunctions, or is otherwise nonfunctional, or if you wish to move to newer hardware, you need to migrate your enterprise server to a new server. This article describes how to recover or move your enterprise server. The process for reverting a enterprise server to an earlier state is not the same as the process shown in this article. Refer to Rolling Your Server Back To A Previous State for information on that process.

Before you begin

You must have the following in order to recover or move an enterprise server:

If possible, you should also have your backup archives or a copy of backup archives from another destination. If you do not, you can still recover or move your enterprise server, but your devices will need to restart their backups.

Definitions

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

Video walkthrough

Steps

Step 1: Install the Enterprise Server software on the new server

  1. Download the installation files for the version of the enterprise server software that was installed on the old server.
  2. Install the enterprise server software on the new server

The new server should match the old server in two ways:

  • You must use the same version of the enterprise server software that produced the database dump you will import.
  • The new server must be accessible on the same network address as the old server. Otherwise, devices will be unable to connect to the enterprise server.

Step 2: Import a database dump from your Enterprise Server

There are two ways to import the database dump:

  • 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.
  • 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.

Importing with the restore_database script

  1. Open a command line interface with administrative privileges on your new server:
    • Windows: Command or PowerShell
    • OS X: Terminal
    • Linux: Terminal or equivalent for your distribution
  2. Navigate to the directory for the CrashPlan PROe command line tools:
  3. Run the restore_database command on the location of the database dump you want to import. For example, on Linux:

    sudo ./restore_database.sh /backups/CrashPlanArchive_m66019504823x001/dbDumps/proserver-db_1332824401321_2012-06-26_121011.sql.gz

For more information, refer to the Command Line Tools reference.

Import database dump using the Administration console

  1. Sign in to the administration console
  2. Go to Settings > Server Action menu > Import Database
  3. Import the database from desired location. Database dumps are ordered by date.
  4. Click Submit. Two notifications appear:
    1. "Database import submitted. Server will shut down."
    2. "Server connection has been lost."
  5. The server imports the selected database.
  6. Select Reconnect to reload the administration console sign-in page.
  7. Sign in again to the administration console to verify your changes.

Step 3: Match filesystem and 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. You have two options:

  • change the filesystem to match the store points
    OR
  • edit the store points to match the filesystem.
Only perform one option
You only need to perform one of these options--not both.

Change the filesystem directories

For each store point:

  1. Sign in to your administration console on the new server
  2. Go to Destinations > Store Points > Store Point Detail
  3. Note the Path and Directory listed in Store Point Info
  4. Create a directory on the filesystem of your new server for that Path. The store point directory must:
    • Exist immediately within the Path directory
    • Have the name of the archive as shown in the Directory under Store Point Info
  5. If applicable, attach the volume containing your archives at the Path directory
  6. Verify that permissions are set appropriately on the Path directory.

Change the Store points

For each store point:

  1. Sign in to your administration console on the new server
  2. Go to Destinations > Store Points > Store Point Detail > Action menu > Edit
  3. Change the Path field to match the location of the store point directory on your filesystem

Step 4: Place archives into Store point directories

The backup archives from the old server must be in the correct store point directory on the new server's filesystem in order for devices to resume backing up.

  1. Locate the archives from your old server. Depending on your situation, the archives may be on an external drive, a DVD, or on your old enterprise server.
    Default locations for store points on a enterprise server can be found here:
  2. Locate the equivalent store point directory on the filesystem of your new server
  3. Copy all archives to the store point directory on the new server.
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.

Best practices for moving your archives

Two-stage copying process

To reduce server downtime, use a two-stage copy process:

  1. Copy the archives from the old server to the new server
  2. Allow the copy process to complete
  3. Stop the enterprise server service on the old server
  4. Copy the archives again to retrieve changes since the first copy completed
  5. Start the enterprise server service on the old server to resume normal operation

The first stage copies a mostly correct version of the data, but because the server is still online, users will still be backing up data. Stopping the enterprise server service for the second stage temporarily stops backup traffic. This allows you to to copy only the changes since the first pass, creating an up-to-date set of your backup archives.

Note that this will temporarily interrupt backup traffic to your enterprise server.

Recommended rsync options

rsync -ah --progress --delete --compress-level=0 --inplace <source> <destination>

Recommended Robocopy options

robocopy <source> <destination> /COPYALL /PURGE /MIR

Step 5: Verify backup archives are accessible

To verify that the backup archives are working normally, use the administration console to restore data from one or more archives.

Case studies

Case study 1

An electrical short damages an old Windows server, so the administrator decides to migrate to a new Linux enterprise server. Fortunately, the hard drive from the old server is still in working order—for now.

  1. Connect the old hard drive to the new Linux server
  2. Mount the volumes containing the archives and confirm they are accessible
  3. Install the enterprise server software on the Linux server
  4. Use the restore_database script to import the database dump stored on the old hard drive:
    sudo ./restore_database.sh /Volumes/WinHD/dbDumps/proserver-db_1332824401321_2012-06-26_121011.sql.gz
  5. Create a new directory, /var/opt/proserver/customArchiveDir and set appropriate permissions
  6. Sign in to the administration console on the Linux server
  7. Edit the store point paths to point to /var/opt/proserver/customArchiveDir
  8. Copy the archives from /Volumes/WinHD/backups/ to the new store point directory:
    rsync -ah --progress --delete --compress-level=0 --inplace /Volumes/WinHD/backups /var/opt/proserver/customArchiveDir
  9. Restore any file from one of the archives using the administration console to confirm that the archives are working properly

Case study 2

An administrator needs to move archives from a store point on an external hard drive to a store point on an internal drive of a Linux enterprise server. This example details how an administrator might copy the archives to the new server.

Archive name: CrashPlanArchive_m424765x001
Old store point directory: /Volumes/USB1/backups/
New store point directory: /backups

  1. Move the archive from the old store point directory on the file system to the new store point
    rsync -ah --progress --delete --compress-level=0 --inplace /Volumes/USB1/backups/CrashPlanArchive_m424765x001 /backups/CrashPlanArchive_m424765x001
  2. Sign in to the administration console on the new server
  3. Go to Destinations > Store Points > Store Point Details > Action menu > Edit
  4. Edit the Path to use the new store point directory, /backups

Troubleshooting

Store point shows a directory error

If a store point is showing an error relating to the path or volume folder, confirm that all folders are in the correct place.

  • Is the new store point Path valid?
  • If you are attaching archives from an external location, is the external media attached and mounted to the operating system?
  • Is the archive folder placed in the correct store point directory?

If you have questions about this process, contact our Customer Champions for assistance.

Store point not accessible

If the administration console shows a notification, "Store point not accessible," the most common cause is incorrect permissions on the store point directory on your filesystem.

Confirm that the store point directory grants read/write/execute access to the user account used by the enterprise server service.

Network issues

If the network addresses of the new server does not match either the primary or secondary network address of the old server, functions of the enterprise server, especially the administration console, will not work properly.

  1. Stop the enterprise server
  2. Set the network interface of the new server to either the primary or secondary network address of your old server (as configured in the database dump you are importing)
  3. Start the enterprise server