Problems with our Magnetic Library

Last post 12-21-2010, 9:25 AM by David Overton. 7 replies.
Sort Posts: Previous Next
  • Problems with our Magnetic Library
    Posted: 12-04-2010, 10:26 AM

    Hello

    today when i run our auxiliary copy i get following error

    Description: Failed to read chunk [1345977] in media [V_1602265] for storage policy [MagLib_16TB] copy [Bandkopie]: Backup job [ 76918 ]. The file or directory is corrupted and non-readable. .

    The MaLib is splitet in two Mount Pathes

    One of the mount Pathes goes offline:

    [Mount path volume is dirty. Please run chkdsk on this volume. ]

    Knows anyone that i can run the chkdsk without trouble?

    And can i run when the Backups runs on the second Mount Path or must i suspend all?

     

    Best Regards

     

  • Re: Problems with our Magnetic Library
    Posted: 12-05-2010, 11:52 PM

    It would be a good idea to suspend all jobs and run chkdsk.

     

    JW

  • Re: Problems with our Magnetic Library
    Posted: 12-09-2010, 1:06 PM

    Hi,

     

    now i had a new problem.

    I had deleted the corrupt mount path.

    And now i get the Error when i want to create a new mount path:

    A mount path already exists at the given location. Please enter a different mount path.

     

    Had anyone solved this problem?

    Or must i open a ticket?.

     

    BR

     

  • Re: Problems with our Magnetic Library
    Posted: 12-09-2010, 1:11 PM

    BR,

    Would it be possible for you to include a screenshot of the error, from Library & Drive Configuration?


    CommVault Development
  • Re: Problems with our Magnetic Library
    Posted: 12-09-2010, 1:19 PM

    The Magnetic Library is in standart configuration. No extra configuratin

    Currently i don't sit in front of the pc so if you need screenshots i had to do ir tomorrow.

    I can only explain it currently.

     

  • Re: Problems with our Magnetic Library
    Posted: 12-09-2010, 3:34 PM

    I assume it's a mount path holding deduped backup data, right?

    If so, there is no other chance than to add the empty mount path as a new one with different location (i.e. another drive letter or additional subfolder in the path).

    Freeing up the old one is only possible when involving support as a special CommCell database modification is needed for that. In any case you should disable the old mount path for write.

    Just be aware that deduped backups referencing to unique blocks stored on the lost mount path might be corrupt and not restorable. This is just in case backups were written across the two mount paths.

    Markus


    Regards,
    MBA
  • Re: Problems with our Magnetic Library
    Posted: 12-20-2010, 4:13 AM

    Hi,

    i had successfully reconfigered the MountPath

    i had every time the problem, one of the MountPath goes Offline and i get nfts errors in the eventlog, all other Mountpath are on the same logical volume.

    Currently the MountPaht how goes offline has only 10 GB now. The different to 2 TB had an another DriverLetter and it works.

    I think Commvault ruined the first volume on the MagLib.

    I can't understand this.

    Any ideas?

  • Re: Problems with our Magnetic Library
    Posted: 12-21-2010, 9:25 AM

    If your mount path goes offline frequently ( there is another issue here ) what type of San are you using?  Is it iscsi or Fiber in any event the issue you should look more closely at is why is your maglib going offline. Could be as simple as a driver.

    Commvault will write to the drive and de dupe will reference the written sectors in the de dupe process, if it can't see or reference what the CS database is telling it should be there is understandable why it is marking the backups unusable.

    One issue seems to be part of a bigger problem. When you get a chance please post some screen shots of what you are seeing. Sometimes there are things that are lost in the translation.

     

    Hope this helps

     

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