Skip to main content
commvault.com commvault.com
Question

Validation request: MediaAgent Hardware Refresh (Same Hostname/IP) with SAN-attached Hitachi Library

  • May 21, 2026
  • 1 reply
  • 31 views
J
Explorer
Forum|alt.badge.img+7

Hello everyone,

I am planning a MediaAgent hardware refresh in an enterprise environment. The backend storage is a SAN-attached Hitachi array (Disk Library) connected via Cisco MDS. The Hitachi storage remains unchanged; only the MA server hardware is being replaced.

Environment & Requirements:

  • The new MA must retain the exact same Hostname, IP address, and Commvault Client Name.

  • DDB and Index Cache are currently on local NVMe/SSD drives and need to be migrated to local NVMe drives on the new server.

  • Operating System: Windows Server.

  • Commvault environment matches the same Feature Release (FR) and Maintenance Release (MR).

Proposed Execution Plan:

  1. Staging: Build the new MA with a temporary Hostname and IP. Install MPIO, HBA firmware, and drivers matching the Hitachi/Cisco Support Matrix.

  2. Freeze State: Suspend all jobs, disable Backup/Restore activity on the old MA, and completely stop all Commvault services to prevent DDB corruption.

  3. Local Data Copy: Robocopy the DDB and Index Cache folders from the old MA to the new MA over the network.

  4. Network Cutover: Shut down the old MA. Swap the temporary IP and Hostname on the new MA to match the old MA's original IP and Hostname. Handle Active Directory Computer Object reset to avoid Trust Relationship failures. Reboot.

  5. SAN Cutover: Update Cisco MDS zoning with the new WWPNs. In the Hitachi management interface, swap the WWPNs in the existing Host Group, strictly maintaining the original Host LUN IDs (HLUs).

  6. OS Rescan: Rescan disks on the new MA. Verify MPIO paths. Mount the LUNs using the exact same Drive Letters / Mount Points. (Strictly no initialization/formatting).

  7. Commvault Installation: Run the Commvault installer. When the existing Client Name is detected, select the Re-Install (Recover) option to generate new certificates and link the existing DB entities to the new hardware hash.

  8. Validation: Verify Library Mount Paths, ensure DDB partitions are Online, and run Test Backup/Restore (Out of Place).

Questions for the community:

  1. Are there any known bugs or undocumented behaviors with the "Re-Install" method regarding Certificate generation or DDB engine recognition in recent Feature Releases?

  2. Regarding MPIO on Windows with Hitachi SAN—are there any specific gotchas or MPIO thrashing issues when bringing these existing LUNs online on a new host before the CV services start?

  3. Is there any additional validation required for the Index Cache offline copy before resuming production jobs?

Appreciate direct, technical feedback.

1 reply

S
Vaulter
Forum|alt.badge.img+3

Hello ​@Jean-Paul 

Here are the answer to your questions: 

  1. Are there any known bugs or undocumented behaviors with the "Re-Install" method regarding Certificate generation or DDB engine recognition in recent Feature Releases?

    - Re-Install option is the supported method for replacing hardware while retaining the same Client Name, Hostname, and IP Address. During reinstallation, new certificates are generated and linked to the existing CommServe database entities.
    - As per the documentation we do not see any bugs in recent Feature Releases (FRs) regarding certificate generation or client registration when following this process.
    - If the DDB and Index Cache are copied exactly (with services stopped and no jobs running as you have mentioned above), the MediaAgent should recognize the DDB partitions and Index Cache after reinstall and service start.
    - If the DDB is not recognized, you may need to initiate a DDB reconstruction. This is rare if the directory structure and permissions are preserved.
     

  1. Regarding MPIO on Windows with Hitachi SAN—are there any specific gotchas or MPIO thrashing issues when bringing these existing LUNs online on a new host before the CV services start?

    - Before starting Commvault services, verify that all LUNs are visible, healthy, and mapped to the correct drive letters/mount points as before. 
    - No Commvault-specific issues have been documented regarding MPIO thrashing during this process. However, it is recommended to ensure that the following prerequisites are properly met:
  • Ensure only the new host is zoned to the LUNs (remove old WWPNs from the host group before bringing LUNs online).
  • Avoid simultaneous access from both old and new hosts to prevent SCSI reservation conflicts.
  • Confirm that Windows Disk Management shows all paths as "Healthy" and "Online" before starting Commvault services.
  • If you see path flapping or disk errors, resolve these at the SAN/OS level before proceeding.

  1. Is there any additional validation required for the Index Cache offline copy before resuming production jobs?

    - After copying the Index Cache and before resuming the jobs, ensure the Index Cache directory is accessible and permissions are correct for the Commvault service account.
    - In the CommCell Console, check the MediaAgent properties (Catalog tab) to confirm the Index Cache is online.
    - If the Index Cache is offline, check for path errors or permission issues.
    - If the Index Cache is intact, it should sync automatically on service start. If not, you may need to manually reconstruct the index.
    - You can run a test backup and restore (preferably out-of-place) to confirm Index Cache and DDB functionality before resuming any production jobs.

     

Readiverse Academy Certifications

description of image
Terms & ConditionsAccessibility statement