Move mount path failed -- is it safe to cleanup the destination?

Last post 08-15-2018, 5:04 PM by Wwong. 5 replies.
Sort Posts: Previous Next
  • Move mount path failed -- is it safe to cleanup the destination?
    Posted: 08-10-2018, 9:52 AM

    HI, all!

    I started a move mount path operation to transition from a 10 TB mount path to 20 TB mounth path.  The move ran for eight or nine days then failed.  It looks like 99-100% of the data was copied to the new drive, but since the operation failed, the old mount path is still setup in the library.  My question is two parts:  (1) will the copied data be removed from the destination automatically?  I'm guessing not since it's been two days and it's still there; (2) is it safe to manually clean up the destination and try the move again?  I think it is since the original mount path is still configured on the library but I just want some reassurance.  I'm working with data that's retained for ten years so it's not like a goof here will be rolled over in 30 days :)

    When I attempt the move again, is there any best practice to follow?  Would it be wise to disable the mount path for new data during the move?

     

    Thanks!

  • Re: Move mount path failed -- is it safe to cleanup the destination?
    Posted: 08-11-2018, 5:54 PM

    Hi kcorrie

    In regards to your questions (answers in-line):

    (1) will the copied data be removed from the destination automatically?  I'm guessing not since it's been two days and it's still there;

    • Answer - Move Mount Path is an operation which is more of a "copy" operation (at first). In a scenario where Move Mount Path does complete successfully, the Source Mount Path will be cleaned up within 24 hours. However for a failed attempt the Destination will not clean up automatically.

    (2) is it safe to manually clean up the destination and try the move again

    • Answer - as the Move Mount Path did not complete successfully, the CommServe will still be referencing the old Mount Path. So it will be safe to remove the contents of the new Mount Path and re-ran the Move Operation.
    • Note - it is only in the final phase of Move Mount Path, where the Mount Path (Source) and Destination is verified, before the CommServe DB is updated to point to the new location.
    As the original Move Mount Path failed, I would recommend to investigate the cause as well, because it wont feasible to re-run the operation and wait for 8-9 days and it fails again. 
     
    Hopefully the above details helped
    Thank you
    Winston
  • Re: Move mount path failed -- is it safe to cleanup the destination?
    Posted: 08-13-2018, 7:06 AM

    Hello kcorrie,

    Please explain exactly what do you want to do. Another way to move the data is to create a new disk library with the new mountpath, add a secondary synch auxcopy to the storage policies pointing to the new disk library and promote this copy to primary after running the auxcopy jobs.

    Regards, Thomas

  • Re: Move mount path failed -- is it safe to cleanup the destination?
    Posted: 08-15-2018, 2:03 PM

    Is there any way to tell why it failed, or do I need to open a case and submit logs to support?  The job details only say "failure in physical move of the mount path"

  • Re: Move mount path failed -- is it safe to cleanup the destination?
    Posted: 08-15-2018, 2:12 PM

    tgabold:

    Hello kcorrie,

    Please explain exactly what do you want to do. Another way to move the data is to create a new disk library with the new mountpath, add a secondary synch auxcopy to the storage policies pointing to the new disk library and promote this copy to primary after running the auxcopy jobs.

    Regards, Thomas

     

    We had to borrow space from another SAN temporarilly.  Now that we have more space dedicated to backups, we need to move data from the temp location to the new location.  I don't want to create a new library.

  • Re: Move mount path failed -- is it safe to cleanup the destination?
    Posted: 08-15-2018, 5:04 PM

    Hi kcorrie

    Thanks for the update 

    In regards to identifying the cause of the issue, in-depth log review will be required.

    In situation like this, opening a Support Ticket would be recommended, as Support will be able to assist further. 

    At the meantime, if you are still concerned about the "copied" date, when engaging CommVault Support, then can review and vet the environment to confirm that everything is alright before executing any steps, as the data is crucial. 

    Thank you 

    Winston

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.
Close
Copyright © 2018 Commvault | All Rights Reserved. | Legal | Privacy Policy