CommCell Migration - Migration Considerations
- Client computers and the Agents installed on the Client can be migrated to another CommCell. You can select the individual Agents, Backupsets, and Subclients for migration.
- Client Group definitions are migrated along with the associations and the clients associated to the Client group.
- Subclient policies, schedule policies, users and user groups, media location and alerts associated with the CommCell.
- Client configurations such as holidays, operation window, activity control, and schedules can be migrated.
- Metadata records associated with the backup data secured by backup operations from the Agents. This includes the following:
- History information.
- Information about media.
- Storage Policy and Storage Policy Copies associated with the subclients configured in the Client, including storage policies and storage policy copies used in the past, that contain valid data from the Client.
- MediaAgent details, including the library configurations can be migrated to another CommCell.
- Client configurations such as deduplication, encryption, and silo.
What Does Not Migrate
- CommCell Migration is a pure database only operation. It does not automatically move files in mount paths (chunks and volumes), job result directories, or Deduplication databases.
- Historical information associated with restore operations and administration jobs.
- Historical information associated with Data Recovery operations and administration jobs.
- Firewall related configuration information.
- Events associated with jobs generated by clients that are migrated.
- Audit trail information associated with the client
- Subclient-based Storage Policy Copy associations.
- Any associations related to the configurations: non-data bearing entities associated with a client such as schedule policies and subclient policies. They are migrated as configuration templates.
- Clients that do not have a subclient (default subclient or user defined subclient) created.
- Vault tracker information like the policies and containers.
Post Migration Considerations
CommCell Migration with 1-Touch
In CommCell Migration with one pass change as the old CommCell will probably not be there and the client may have already been unregistered we need to make the following changes manually since recovery brings the registry at the time of the backup:
- CommServe GUID in registry.
- CommServe name/ Fully Qualified Domain Name in registry.
- Certificates folder to be added as explained in Import Metadata on the Destination CommCell.
- If client hostname was changed on recovery it has to be changed in GUI also.
After CommCell Migration media refresh jobs may not run for migrated copies. It is recommended to manually re-enable media refresh on migrated tape copy and add the tape library as Data Path post migration.
When you migrate a mount path that contains deduplicated data, the Interval (Minutes) between disk space updates parameter is created with a default value in minutes. This value will ascertain the time taken by MediaManager to automatically detect and update the new mount paths for deduplicated data. This in turn will determine the time to restore the data on the new target MediaAgent.
After CommCell Migration, the Deduplication Database is sealed and operates in the read-only mode in the destination CommCell. The migrated (deduplication enabled) storage policies in the destination CommCell can be used to restore the deduplicated data migrated from the source CommCell and to perform Auxiliary Copy operation with the migrated data as the source. Migrated Storage Policies in the destination CommCell cannot be used to deduplicate new backup operations. You must create new storage policies or use existing storage policies in the destination CommCell for new backup operations.
After a client is permanently migrated to a new CommCell, the backup for each of its subclients will automatically be converted to a full backup. This is to make sure that the metadata is disassociated from the old CommCell and recreated in the new CommCell. Migrated Storage Policies in the destination CommCell cannot be used for new backup operations. You must create new storage policies or use existing storage policies in the destination CommCell for new backup operations.
Note: You are not recommended run backups to a migrated storage policy by creating a new copy and promoting the copy as the primary copy. The promotion can cause data loss of the deduplicated data.
Auxiliary Copy Operations
We recommend to perform all the required auxiliary copy operations on the source CommCell before the CommCell migration. You cannot perform auxiliary copy operation after the storage policy is migrated to the destination CommCell.
You can perform an auxiliary copy operation to a new secondary copy that is created after the migration. Note that this copy cannot use the same mount paths or deduplication baseline as data that was backed up from the clients.
You cannot promote any synchronous copy to be primary copy for a migrated storage policy.
The mount paths associated with disk and cloud libraries are migrated as read only. You can use these mount paths only for restore operations. You can not perform backup operations.
The tape libraries are also migrated as read only. However, to reuse a library, you can do one of the following:
- Select the Allow imported media to be reused on the CommCell option when you perform CommCell migration.
For more information, see Reuse Imported Media on Destination CommCell.
- You can also choose Overwrite Media - When it is from different CommCell option in the library properties.
For more information, see Library Properties (Media Usage).
After the migration, the global policies from the source CommCell environment are hidden in the CommCell Console in the destination CommCell environment. The global policies are the global deduplication storage policies and the global secondary copy policies.
Last modified: 12/30/2019 9:52:38 AM