none
Systemback with tapeco-location fails i/o error 0x8007045D RRS feed

  • Question

  • Goodmorning,

    We are using Dpm2010 with an Msl 6030 Tapelibrary with Tape colocation enabled. The problem is when we do a systemstatebackup this job fails.

    When we do a systemstate without co-location there is no problem. Also with  a file or sql backupjob with co-location enabled there is no problem. We have tried the following solution but that did not work:

    Still no luck so we continued and changed the native capacity on the tapes in the registry. We tried this hoping that DPM should roll over to a new tape when the new limit was reached. We had tapes with 400GB capacity so we changed it to 399GB instead.
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Agent] "TapeSize"=dword:00399000
     That didn''t help so we continued the troubleshooting and got the advice from Microsoft Support to change the bufferQueuSize in the registry
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Agent] "BufferQueueSize"=dword:00000001
    After one final reboot we got it to work and finally the backup job spanned multiple tapes.

    I Don't think that it is a hardwareissue because others jobs have no problem.

     

    Does someone have an idea?

    Thanks! Regards Mattu

    • Moved by Praveen D [MSFT] Monday, July 19, 2010 7:27 AM Moving to DPM SS and BMR Protection Forum (From:Data Protection Manager)
    Wednesday, July 14, 2010 7:53 AM

Answers

  •  

    As per your solution:

        [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Agent] "BufferQueueSize"=dword:00000001
        After one final reboot we got it to work and finally the backup job spanned multiple tapes.

    This indicates that the hardware / driver does not handle multiple buffer queues very well.

    Without the registry key the default buffer queue size is 10. Every time the buffer is written it compares the queue size to the value. When it is set to 1 the MTFLIB_S_QUEUE_FULL is returned.

    This avoids putting the buffer in a queue that is flushed later.

    The setting of 1 flushes the data to tape for every queue and in turn keeping the tape header information updated more frequently.

     


    Regards, Mike J [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, July 28, 2010 10:09 PM
    Moderator

All replies

  •  

    As per your solution:

        [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Agent] "BufferQueueSize"=dword:00000001
        After one final reboot we got it to work and finally the backup job spanned multiple tapes.

    This indicates that the hardware / driver does not handle multiple buffer queues very well.

    Without the registry key the default buffer queue size is 10. Every time the buffer is written it compares the queue size to the value. When it is set to 1 the MTFLIB_S_QUEUE_FULL is returned.

    This avoids putting the buffer in a queue that is flushed later.

    The setting of 1 flushes the data to tape for every queue and in turn keeping the tape header information updated more frequently.

     


    Regards, Mike J [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, July 28, 2010 10:09 PM
    Moderator
  • Thanks Mike,

    I am on holiday now, i will try you solution over 2 weeks!! I will let you know

    Regards mattu

    Thursday, August 5, 2010 7:53 AM
  • Thanks it has been solved!!
    Friday, August 27, 2010 8:18 PM
  •  

    Thanks for the confirmation.

    You may have trouble perfroming tape catalogging or restores with this set to 1:

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Agent] "BufferQueueSize"=dword:00000001

     

    I recommend setting it to 3 and if the problem comes back, try 2.  Worst case you need to keep it at 1 for backups, and set it to 3 for restores.

    cheers


    Regards, Mike J [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, August 27, 2010 9:45 PM
    Moderator