Before you begin
You must have the following in order to recover or move an enterprise server:
- Familiarity with the Code42 environment's storage hierarchy
- Enterprise server database dump
- The first 4 characters of your master license key
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.
Your existing enterprise server; the source of the recovery or move operation
Your new enterprise server; the destination of the recovery or move operation
Step 1: Install the Enterprise Server software on the new server
- Download the installation files for the version of the enterprise server software that was installed on the old server.
- 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
- 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
- Navigate to the directory for the CrashPlan PROe command line tools:
- 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
- Sign in to the administration console
- Go to Settings > Server Action menu > Import Database
- Import the database from desired location. Database dumps are ordered by date.
- Click Submit. Two notifications appear:
- "Database import submitted. Server will shut down."
- "Server connection has been lost."
- The server imports the selected database.
- Select Reconnect to reload the administration console sign-in page.
- 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
- edit the store points to match the filesystem.
You only need to perform one of these options--not both.
Change the filesystem directories
For each store point:
- Sign in to your administration console on the new server
- Go to Destinations > Store Points > Store Point Detail
- Note the Path and Directory listed in Store Point Info
- 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
- If applicable, attach the volume containing your archives at the Path directory
- Verify that permissions are set appropriately on the Path directory.
Change the Store points
For each store point:
- Sign in to your administration console on the new server
- Go to Destinations > Store Points > Store Point Detail > Action menu > Edit
- 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.
- 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:
- Locate the equivalent store point directory on the filesystem of your new server
- Copy all archives to the store point directory on the new server.
Best practices for moving your archives
Two-stage copying process
To reduce server downtime, use a two-stage copy process:
- Copy the archives from the old server to the new server
- Allow the copy process to complete
- Stop the enterprise server service on the old server
- Copy the archives again to retrieve changes since the first copy completed
- 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 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.
- Connect the old hard drive to the new Linux server
- Mount the volumes containing the archives and confirm they are accessible
- Install the enterprise server software on the Linux server
- Use the
restore_databasescript 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
- Create a new directory,
/var/opt/proserver/customArchiveDirand set appropriate permissions
- Sign in to the administration console on the Linux server
- Edit the store point paths to point to
- 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
- 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.
Old store point directory:
New store point directory:
- 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/
- Sign in to the administration console on the new server
- Go to Destinations > Store Points > Store Point Details > Action menu > Edit
- Edit the Path to use the new store point directory,
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.
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.