seek failure

Last post 01-05-2011, 12:47 PM by Bill Baumann. 19 replies.
Sort Posts: Previous Next
  • seek failure
    Posted: 12-07-2010, 11:19 AM

    Trying to restore from a magnetic library keep getting "seek failure happened". Anyone else ever see this?

  • Re: seek failure
    Posted: 12-07-2010, 1:21 PM

    Hello gmartin,

    Is the disk online and accessible?

    This message is normally received when CV can't find data residing on the disk. Typically outcome is that the disk is offline or the chunk file(s) were deleted from storage.

     

     

  • Re: seek failure
    Posted: 12-07-2010, 1:38 PM

    disk is online. I am guesssing the chunks were deleted but not sure how that would have happenned. Virus scans are disabled on these volumes

  • Re: seek failure
    Posted: 12-07-2010, 2:22 PM
    Would you be able to run a data verification job for the backup you're trying to restore from?
  • Re: seek failure
    Posted: 12-07-2010, 3:50 PM

    I get an error message when doing that.. it says no resources please check the streams tab

  • Re: seek failure
    Posted: 12-07-2010, 3:52 PM

    What does the streams tab say?

  • Re: seek failure
    Posted: 12-07-2010, 3:56 PM

    There is no streams tab

     


    Attachment: error.jpg
  • Re: seek failure
    Posted: 12-07-2010, 4:16 PM

    Can you provide us a screenshot?

  • Re: seek failure
    Posted: 12-07-2010, 7:04 PM
    • zzz is not online. Last active: 12-03-2015, 7:57 PM zzz
    • Top 50 Contributor
    • Joined on 07-06-2010
    • Adept
    • Points 261

    We had the same error several times. Couldn't catch it with Commvault support because it came with serious cluster issue. Once the cluster node was rebooted and the error disappeared as well.

    Would like to know what causes it and how to prevent it happening.

    Thanks.

  • Re: seek failure
    Posted: 12-07-2010, 8:46 PM

    zzz - interesting that you mention having this issue with a cluster resource. I came across that exact same scenario last week where the disk had literally disappeared from cluadmin which subsequently caused a few errors including seek failure. This was on Win2k8 R2 and after reboot of each node my disk had returned.

     

    @original poster: If you can execute a data verification job it would tell you what chunks it could not find, however being that you're getting a streams error I'm thinking you may have a different issue.

    Question: Can you run backups to this disk? 

  • Re: seek failure
    Posted: 12-07-2010, 9:00 PM
    • zzz is not online. Last active: 12-03-2015, 7:57 PM zzz
    • Top 50 Contributor
    • Joined on 07-06-2010
    • Adept
    • Points 261

    The cluster nodes are Windows 2008 R2.

    The disks didn't disappeared, both resource and destination. I could copy data from Maglib and create file/folder in Maglib. The backup was OK to run, however, we rebooted the nodes. I think I did data verification and it was OK (not very sure).

  • Re: seek failure
    Posted: 12-08-2010, 9:23 AM

    SConnington:

    zzz - interesting that you mention having this issue with a cluster resource. I came across that exact same scenario last week where the disk had literally disappeared from cluadmin which subsequently caused a few errors including seek failure. This was on Win2k8 R2 and after reboot of each node my disk had returned.

     

    @original poster: If you can execute a data verification job it would tell you what chunks it could not find, however being that you're getting a streams error I'm thinking you may have a different issue.

    Question: Can you run backups to this disk? 

    Yes I can and have been running backups to disk.There are definetly chunks missing, also on some of the backups the index cache is missing on the shared index cache server. This is a serious issue as hardly any of my backups are restorable. I either get a seek failure or index cache can't be restored error. I am going to have to go back to tapes I guess. So far there has no one at commvault that can explain it.

  • Re: seek failure
    Posted: 12-08-2010, 9:33 AM

    gmartin,

    Agreed, this is a serious issue and I think an incident needs to be logged for us to investigate where the chunk data is dissapearing too. I would also suggest checking windows event viewer for any errors that may give insight to where the problem lies.

    Please reference this thread when opening the case.

  • Re: seek failure
    Posted: 12-09-2010, 1:23 PM

    Hi gmartin,

    Please post your case number or private message it to me as I want to assist with getting to the bottom of this dilemma.

  • Re: seek failure
    Posted: 12-09-2010, 1:25 PM

    Do you have encryption enabled?

  • Re: seek failure
    Posted: 12-09-2010, 3:05 PM

    Might not be the issue here, but recommend to enable "use unbuffered I/O" on every mountpath of MagLibs in order to avoid FS Cache loss issues (especially on clusters when active node dies). Caching doesn't help when writing large data streams, so it's useless anyway for backup to my experience.

    Also, avoid mounting SAN-based mount paths to an existing file system (if applicable). Instead, I'd prefer to mount to a drive letter as this will provide more transparancy and additionally get around some OS issues with that in 2008 (if used).

    Appart from that, the only cases where I saw chunks disappearing were related to virus scanning. Although you said mount paths are excluded from scanning, it might be that the backup/writer process in RAM is not, so there might be a small chance that data is already been quarantined in RAM before it gets to the mount path or even to the writer. Do you use a virus scanner that allows for excluding active processes from scanning?

     


    Regards,
    MBA
  • Re: seek failure
    Posted: 12-20-2010, 8:00 PM

    I had the same error too yesterday trying to restore our 186GB exchange DB. The resotre is slow and big enough without the need getting the error 6 hours into the restore. I'm trying again now in a hope it will work.

  • Re: seek failure
    Posted: 01-04-2011, 3:44 PM

    seems there isn't data missing, now we're looking into the configuration of the shared disk library. Library has 4 mounts, 2 on each media agent. They don't have access to each other's drive but when I view media on the job i'm looking to restore, I browse to recover using that media agent and I am getting the same results.

  • Re: seek failure
    Posted: 01-04-2011, 3:53 PM

    seems there isn't data missing, now we're looking into the configuration of the shared disk library. Library has 4 mounts, 2 on each media agent. They don't have access to each other's drive but when I view media on the job i'm looking to restore, I browse to recover using that media agent and I am getting the same results.

  • Re: seek failure
    Posted: 01-05-2011, 12:47 PM

    We needed to have these setup as shared disk libs with acessible paths from all MA's. In order for MA 1 to access the data on a local mount path on MA 2 it needs to be shared out and the path needs to be a UNC path to the location. This way MA 1 can read the data on MA 2 mag lib and vice versa.

    Now that this has been corrected your restores are working.

    Please let us know if you encounter further issues with this.

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