NetApp NDMP NAS LAN-free auxiliary copy consistently gets I/O mount errors.

Last post 05-19-2011, 9:12 AM by bw512. 3 replies.
Sort Posts: Previous Next
  • NetApp NDMP NAS LAN-free auxiliary copy consistently gets I/O mount errors.
    Posted: 04-28-2011, 1:45 PM

    NetApp NDMP NAS LAN-free auxiliary copy consistently gets I/O errors.  The tape mounts on the NetApp filers for the read appear to work properly but for some reason, the auxiliary copy attempts tape mounts on the NDMP host which is not a NetApp filer but a Windows media agent.  This is where the I/O mount errors occur.  Is this expected behavior?  My theory is that the NDMP host (Windows media agent) that I am using also has "NDMP Remote Server" (NRS) installed which is why it is trying use it on the auxiliary copy write.  My understanding is that the auxiliary copy of the storage policy should only have NetApp filer LAN-free data paths included.  Unless I am doing something wrong?

  • Re: NetApp NDMP NAS LAN-free auxiliary copy consistently gets I/O mount errors.
    Posted: 04-29-2011, 2:37 PM

    It sounds like you might not have the data path set right in your aux copy policy.  It should be the same lib as the NDMP primary (if your primary writes to tape that is).

  • Re: NetApp NDMP NAS LAN-free auxiliary copy consistently gets I/O mount errors.
    Posted: 04-29-2011, 2:46 PM

    Correct, both the primary and synchronous copies are writing to the same physical tape library.  I have two filers (connected to the tape SAN) as data paths defined in the primary copy.  I have same two filers (connected to the tape SAN) as data paths defined in the synchronous copy.  To my knowledge, this configuration should work.  These I/O errors are intermittent.

  • Re: NetApp NDMP NAS LAN-free auxiliary copy consistently gets I/O mount errors.
    Posted: 05-19-2011, 9:12 AM

    This thread was resolved by CommVault support.  It turns out that a mix of 64 and 512KB block size LTO4 media was the culprit.  When the SAN-attached NetApp filer tried to overwrite the OML of a 512KB LTO4 tape, it would generate an I/O error.  The source data path for these NDMP SAN-attached NetApp filers is configured for 64KB block size for the LTO4 media.  Apparently with this shared scratch media pool using a range of block sizes for LTO4 media, we would consistently run into this.  All that had to be done was to check the "When content verification fails" checkbox of the "Overwrite Media" section of the "Library Properties.  Since we did this, the auxiliary copy has been running fine.

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