Hardware refresh of MA from one DR site to another DR site

Last post 04-29-2019, 5:57 PM by Wwong. 1 replies.
Sort Posts: Previous Next
  • Hardware refresh of MA from one DR site to another DR site
    Posted: 04-29-2019, 1:39 PM

    Hello forum,


    Looking for advice, thoughts, recommendations on how to go about doing a hardware refresh of an MA.  In our particular situation we have an existing MA (with backend disk and tape libraries) at our current DR site.  We will be standing up a completely new MA (new hardware, new disk library storage) at a different DR site.  (The tape library will be physically moved from old to new site.)  We will need to move the existing MA content (DDB, Index cache, disk library) from the current MA to the new DR-site/MA.  The old MA site will be physically decom'd at some point (network link will disappear).  I do not have any direct ability to mount the old DR-site/MA's disk library to the new MA, btu I can certainly ship data via normal CV processes.


    One thought we've had was to simply set up a new storage policy copy to effectively 'replicate' all existing b/u images from the old MA/disk-library to the new MA.  This would allow us to continue production backup auxcopy activity which would be copying primary backups (via auxcopy) to the old MA's disk library - at least until the bulk of the old MA disk library was effectively 'migrated' (or replicated) to the new MA's storage.  Then, at some point we would stop aux activity from primary to old-MA, run a final aux job to copy data from old-MA to new-MA, then effectively (logically) disable the old MA.  Storage policies and aux jobs would be modified to write from primary to new MA instead of old MA.  One problem/question is, if that scenario all works, then how to them go about cleaning up and decommissioning the old MA?  We cannot let the old MA 'hang around' forever because the network link to the site will be shutdown a short time after the planning migration (month or so).

    Thoughts anyone?

  • Re: Hardware refresh of MA from one DR site to another DR site
    Posted: 04-29-2019, 5:57 PM

    Hi kafirboy55

    Your thought process on setting up another Secondary Copy and do Aux Copy is correct. 

    So this will be how I would do it:

    • Setup new Environment with new MA, Disk Library and retaining old Tape Library 
    • Create a new Copy within the Storage Policy
    • Disable the old Secondary Copy
    • For new Secondary Copy, set the Source Copy to point to the old Secondary Copy. 
    • Trigger the Aux Copy:
      • By doing the above we will be sourcing the data from the old Secondary Copy to the New Secondary Copy, and eventually as everything catches up, you can then remove the Source Copy association, so it will be grabbing from the Primary Copy again.
    Assuming Deduplication is used for the old Secondary Copy, once everything is migrated to the new DR site, you will then need to Seal the DDB associated to the old Secondary Copy, either wait for the retention to be met and let jobs age, or you can manually delete all the jobs from the Secondary Copy (decommission one).
    Once the Jobs are deleted, you will then need to run Data Aging and allow the Data to be physically pruned from the old Disk Library.
    You will then get to a stage where the Disk Library will be disassociated to the DDB, the Sealed DDB will disappear as you have removed all the baselines, you can then remove the Disk Library, Deconfigure the MediaAgent and remove it gracefully. 
    The above will be the most effective way in removing/decomm a MA from CommVault (but at the same time ensuring all data is successfully replicated to the new site). 
    Note - you can even run Data Verification on the new Secondary Copy after Aux Copy, to ensure all data is copied successfully. 
    Hopefully that helps 
    Kind Regards
The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy