- CrashPlan PROe
This guide uses these terms extensively. If you are unsure about any of these concepts, please contact our Customer Champions for more information before attempting to move your storage servers.
An archive contains backup data for a single CrashPlan device. Each archive is securely encrypted using an archive encryption key.
(1) General term applied to locations to which your files are backed up: your server, an external drive, or with online hosted storage.
(2) Highest level in the Code42 environment storage hierarchy. A named grouping of enterprise servers and store points on a single LAN or at a single data center.
A group of users. You can define many settings at the organization level, allowing you to configure organizations with different settings for a variety of purposes. Each user can belong to only one organization. An organization can contain child organizations, and an organization can exist without containing any users.
A type of enterprise server. A storage server is used only for storage in multi-server deployments. A storage server cannot function as a failover for a master server. A storage server depends on user authorization provided by the master server.
Moving a storage server to a new destination can result in data loss if the steps below are not followed!
- It is not possible to move a master server to a different destination (although you may rename any destination)
- Only Code42 environments with more than one destination, and at least one storage server, support moving a storage server to a different destination
- The SYSADMIN role is required to move storage servers to a new destination
Before you begin
Plan carefully before moving any storage servers:
- Understand the Code42 environment's storage hierarchy
- The destination that you move your storage servers into should be the destination with the most devices and storage already on it. Consolidating destinations is a database-intensive process, and moving fewer devices and less data results in less processing load.
- If you have a large number of archives on a storage server to be moved, and you do not want to lose the data in the archives, do one of the following:
- Migrate the archives to a different storage server that will not be moved and that is within the same destination
- Offer the new destination to the organizations of the affected users and devices.
If an archive is moved to a destination that is not offered to that archive, the archive is deleted during the migration process, and the data is not recoverable.
For further information about what happens to archives with multiple destinations, review Offer Additional Destinations.
Step 1: Block client communication (optional)
For smaller installations, blocking CrashPlan app communication is optional.
For larger installations, we recommend blocking CrashPlan app communication in order to reduce the load on the internal database while the storage server moves to a new destination.
The method used to block CrashPlan app communication varies by OS platform, network configuration, and networking equipment (e.g. routers and hardware firewalls). For assistance with blocking client communication, contact your network administrator first, then contact our Customer Championss if you have more questions.
Linux example using iptables
This example shows one way to block client communication: rejecting traffic to the enterprise server on TCP ports 4282 and 443.
The commands below are for example purposes only, and must be adapted for your particular network and Code42 environment. The command is run on the server running the enterprise server service.
iptables -I INPUT -i eth0 -p tcp --dport 4282 -j REJECT iptables -I INPUT -i eth0 -p tcp --dport 443 -j REJECT
Step 2: Move Storage server
You may now move the storage server to the new destination:
- Sign into your administration console
- Go to Destinations > Servers
- Select a storage server to move
- Click the Action menu > Change Destination
- Follow the instructions on the Change Destination screen, one row per affected archive.
Moving with multiple destinations offered
When you select Change Destination, the administration console prompts you to reconcile duplicated archives. This process is necessary in order to reconcile duplicated archives after the move of the storage server, or to approve the delete of an archive.
Duplicated archives need to be reconciled when:
- A storage server is moved from one destination to another
- Users with archives on the storage server are in an organization that is offered two or more destinations
In this diagram, Archive 1 and Archive 1' both belong to the same user.
In this case, when the storage server is moved to Destination A, only one of the two archives, Archive 1 or Archive 1', can be kept. You must choose which of these two archives you wish to keep. The screen below will provide you with a row for each archive to be reconciled:
Simply choose which of the two archives you wish to keep. The archives are identified by size, date, and current location.
- Choose an archive to keep in each row. There is one row per archive to reconcile.
- After reconciling all archives, choose:
- Move to move the archives to the new destination
- Cancel to abort the move of the storage server to the new destination
Moving with only one destination offered
When only one destination is offered to an archive, that archive must be deleted when it is moved to a new destination.
In order to move the archive to a new destination, you must agree to delete the archive, because:
- The user is in an org that is offered only its current destination
- A destination can only store archives belonging to users that are offered the destination
In this diagram, the Archive belongs to a user. Because the organization Org A is not offered the destination Destination A, the Archive will be deleted when it is moved. All data in Archive will be deleted, and its backup will start over.
In this case, the move will not occur unless the admin agrees to delete the archive by choosing the radio button in the screen below:
- Choose Destination not offered
- Move to move the archive and restart its backup
- Cancel to abort the move of the storage server to the new destination
Step 3: Watch logs (optional)
You can view the progress of the move operation in the logs. Search for the term FCUSWAP in the main log file (com_backup42_app.log.0 ) using your favorite search tool (such as grep for Unix/Linux).
Here are sample results:
03.13.14 15:54:31.003 INFO W11637197_com.code42 de42.computer.FriendComputerUsageSwapCmd] FCUSWAP:: START; sourceGuid=620201442023571713, previousTargetGuid=627317939145539841, newTargetGuid=627316835758375169, newMountPointId=2 [03.13.14 15:54:31.768 INFO W11637197_com.code42 de42.computer.FriendComputerUsageSwapCmd] FCUSWAP:: archive record for org. num=1; sourceGuid=620201442023571713, previousTargetGuid=627317939145539841, newTargetGuid=627316835758375169, newMountPointId=2 [03.13.14 15:54:31.769 INFO W11637197_com.code42 de42.computer.FriendComputerUsageSwapCmd] FCUSWAP:: Deleting previous FCU. FriendComputerUsage [friendComputerUsageId=6, friendComputerId=2, version=627460502447980801, sourceComputerGuid=620201442023571713, targetComputerGuid=627317939145539841, mountPointId=2, mountVersion=1, archiveHoldExpireDate=Fri Mar 13 15:54:31 CDT 2015, lastMaintenanceDate=Wed Mar 12 16:28:59 CDT 2014, userMaintenanceDate=null, maintenanceDuration=null, lastCompactDate=null, numBlocks=null, numBlocksToCompact=null, numBlocksCompacted=null, numBlocksFailedChecksum=null, compactBytesRemoved=null, compactTotalBytes=null, backupSetVersion=1, backupSetCount=1, backupSetData=1,1394744751975,1394743851976,1394743851976,f,362,30925675,0,0,0,f,0,0,-1, creationDate=Thu Mar 13 15:40:03 CDT 2014, modificationDate=Thu Mar 13 15:54:31 CDT 2014, alertInfo=AlertInfo[ alertState:0]]; sourceGuid=620201442023571713, previousTargetGuid=627317939145539841, newTargetGuid=627316835758375169, newMountPointId=2 [03.13.14 15:54:31.776 INFO W11637197_com.code42 de42.computer.FriendComputerUsageSwapCmd] FCUSWAP:: DONE; sourceGuid=620201442023571713, previousTargetGuid=627317939145539841, newTargetGuid=627316835758375169, newMountPointId=2
After a storage server has successfully moved to a new destination, you will see the following lines in your master server's log:
[03.13.14 15:56:08.487 INFO BWQ-NodeSyncService: ver.sync.SyncHandleFcuStatsUpdateBaseCmd] SYNCHRONIZE:: FCU Stats Updated from Node: 627316763784118529 [03.13.14 15:56:08.491 INFO BWQ-NodeSyncService: com.code42.queue.BackgroundWorkQueue ] BWQ-NodeSyncService:: Completed work - duration(ms)=7, BWQ-NodeSyncService::-0; work(0)=18437594[ workName = SYNCHRONIZE:: ASyncWork::NodeSyncFcuStatsRequestCmd, enqueueTimestamp = 1394744168484, priority = 0][ delayedTime(ms) = 0]
Step 4: Stop offering empty destination to organizations (optional)
Once you have moved the storage server to its new destination and verified the move in the logs, you may stop offering the old destination to organizations:
- Sign in to the administration console
- Go to Organizations
- Select an organization to modify
- Select the Action menu > Edit > Destinations
- Deselect the old destination
A confirmation screen appears
- Type I agree
- Click OK, to signify that you understand that any archives associated with the org that are still stored in the destination will be deleted
- Click Save
Step 5: Delete unwanted empty destination (optional)
You may remove the old destination if it is no longer needed:
Step 6: Unblock client communications (optional)
If you previously blocked network communication with your CrashPlan apps, reverse the blocking procedure in order to unblock communication between your CrashPlan apps and the master server.
Linux example with iptables
This example shows one way to restore client communication: accepting traffic to the enterprise server on TCP ports 4282 and 443. This example corresponds to the iptables rejecting command shown above.
The commands below are for example purposes only, and must be adapted for your particular network and Code42 environment. The command is run on the server running the enterprise server service:
iptables -D INPUT -i eth0 -p tcp --dport 4282 -j REJECT iptables -D INPUT -i eth0 -p tcp --dport 443 -j REJECT
Step 7: Enable balancing (optional)
You can enable data balancing on store points to ensure that your destinations are using about the same amount of storage space.
- Choose Store points on the administration console navigation menu
- Select a store point to modify
- Click Action menu > Enable Balancing