Partially success with failure on different files everyday - Veritas Net Backup

This is a discussion on Partially success with failure on different files everyday - Veritas Net Backup ; Master OS: Windows 2003 Server NBU version: NBU5.1 MP4 Client OS: WIndows 2003 Server Error Msg: Error bpbrm(pid=3964) from client PGSSV001NB: ERR - failure reading file: F:\......\D11_83182627_0x5.log (WIN32 13: The data is invalid. ) We have a backup everyday for ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Partially success with failure on different files everyday

  1. Partially success with failure on different files everyday


    Master OS: Windows 2003 Server
    NBU version: NBU5.1 MP4
    Client OS: WIndows 2003 Server
    Error Msg:

    Error bpbrm(pid=3964) from client PGSSV001NB: ERR - failure
    reading file: F:\......\D11_83182627_0x5.log (WIN32 13: The data is invalid.
    )

    We have a backup everyday for this client, it is always partially success
    with failure on a few log files. Apparently those files are not backup, but
    number of files and these failure files are not the same every single day.
    Probably user is running some application that generates different log files
    everyday.

    Tried with enabling and disabling "Windows Open File" & VSP feature but it's
    not helping in anyway.

    Any idea how to workaround this? Thanks a mil.

  2. Re: Partially success with failure on different files everyday

    Hi Keng,

    You must remember that the "VSP" software snapshot technology is only a best
    attempt. It is NOT guaranteed to work every time. Even the manual says
    so, not me. The default of VSP is to wait for up to 300 seconds for a
    "quiescent" (look it up in a dictionary) period of 5 seconds. If the VSP
    part of NetBackup client doesn't see one single complete period of 5 seconds
    of totally quiet no disk activity on the target disk WITHIN a period of 300
    seconds (the default) then it gives up trying to use VSP - and then,
    depending on your setting, the client job will either abandon using VSP for
    the backup and continue - OR - it will abort the backup completely - you can
    configure this behaviour.

    You can try messing around with timeouts and wait periods... up to you. I
    might try a few different settings (which probably won't help), and then
    move on... as below...


    First of all, I would make sure that the snapshot sizes are good and tuned.
    NetBackup is an extremely complex piece of software. It does a great job of
    one size fits all, most of the time. But, it is so BIG that there will
    always be one or two clients that need that special touch to get them to
    work. That's life. 20% of your clients will give you 80% of your
    headaches.

    Anyway, the default VSP snapshot file size is 30GB. Wow! I can't think
    I've ever seen a mature production Windows servers with 30GB free on EVERY
    disk. No way. So.... so, you need to tune it.

    I typically use initial snapshot size of 1000MB (=1GB) and max snapshot size
    of 5000MB (=5GB), sometimes less for each, but never more. At one site, I
    abandoned trying to use VSP altogether on the C: drive of *all* clients.
    Yep, I excluded "C" from VSP for *all* Windows clients across the whole
    organization - and - guess what - the backups ran quicker with fewer
    problems . My two cents is, VSP is good for any drive other than C:.

    Anyway, I digress again, back to your specific problem, you'll see why I
    mentioned all the above when you get into it...



    Back to your problem.

    Some applications simply never release certain files. Even OpenVMS can't
    backup open files that are in the process of being written - if OpenVMS
    can't do it, then, guess what, you've got no chance with Windows. IMHO,
    Windows is a toy/disposable OS (and no one in their right mind would run a
    critical "bust your business" application on a Windows server) - instead you
    run "bust your business" apps on "bet your business" servers - i.e. OpenVMS.

    Sorry, I digressed again...



    Anyway, hopefully you're starting to see that "sometimes" some files just
    can't be secured because some operating systems just can't release the files
    (and look at this way, no application or O/S is just simply going to release
    files just because you want to run a backup) because they are too busy
    writing to the file. To expect all NetBackup clients to backup all files on
    all operating systems on all servers all the time is, well, pure fantasy.



    Anyway, back to your problem...

    The way I see it is you have three choices (each progressively harder) to
    achieve a "blue" status zero and thus a complete and completely reliable
    backup...

    1) Simply exclude the problem file, but only if it has been agreed that the
    file isn't critical for audit purposes (always get management sign off
    before excluding *any* file). In your case, apply an exclusion (to the
    client) of "F:\folder\folder\D*_*_*x*.log" (remember - always try to get the
    best wildcard pattern that matches the least number of your problem file(s),
    *but* doesn't also cover (and thus exclude) too many other non-problem
    files).
    ....or...
    2) Shutdown the app (or service) that is writing the data or log file. You
    use bpstart_notify and bpend_notify for this, see the manual(s). This way
    the app/service is shutdown before the backup starts, and started again
    after the backup completes. This is my favourite approach.
    ....or...
    3) If you can't use option 2 *and* the exclude from option 1 covers too many
    other files (e.g. a collection of logs in one folder), then I use a
    bpstart_notify script to move all the "old", and thus closed, log files to
    another folder so that they get secured/backed-up because they no longer
    exist in the folder that has the exclusion from option 1. What I mean is, I
    move all the closed file to another folder. The exclusion still ensures
    that the one or two locked files are excluded, but because the

    It just depends how important your files are . Most of the time it's a
    simple option 1. *BUT* always first check with your friendly neighbourhood
    technical application support team. Never, and I mean *never* ever exclude
    a file just because you want to.


    Hope this helps dude.

    Regards,
    Dave.



  3. Re: Partially success with failure on different files everyday


    hi DR,

    Thank you very much for your detailed explanation. I'll try the settings
    out... even though it may not work, I've learned something eventually.

    Keng.

    "D R" wrote:
    >Hi Keng,
    >
    >You must remember that the "VSP" software snapshot technology is only a

    best
    >attempt. It is NOT guaranteed to work every time. Even the manual says


    >so, not me. The default of VSP is to wait for up to 300 seconds for a
    >"quiescent" (look it up in a dictionary) period of 5 seconds. If the VSP


    >part of NetBackup client doesn't see one single complete period of 5 seconds


    >of totally quiet no disk activity on the target disk WITHIN a period of

    300
    >seconds (the default) then it gives up trying to use VSP - and then,
    >depending on your setting, the client job will either abandon using VSP

    for
    >the backup and continue - OR - it will abort the backup completely - you

    can
    >configure this behaviour.
    >
    >You can try messing around with timeouts and wait periods... up to you.

    I
    >might try a few different settings (which probably won't help), and then


    >move on... as below...
    >
    >
    >First of all, I would make sure that the snapshot sizes are good and tuned.


    >NetBackup is an extremely complex piece of software. It does a great job

    of
    >one size fits all, most of the time. But, it is so BIG that there will


    >always be one or two clients that need that special touch to get them to


    >work. That's life. 20% of your clients will give you 80% of your
    >headaches.
    >
    >Anyway, the default VSP snapshot file size is 30GB. Wow! I can't think


    >I've ever seen a mature production Windows servers with 30GB free on EVERY


    >disk. No way. So.... so, you need to tune it.
    >
    >I typically use initial snapshot size of 1000MB (=1GB) and max snapshot

    size
    >of 5000MB (=5GB), sometimes less for each, but never more. At one site,

    I
    >abandoned trying to use VSP altogether on the C: drive of *all* clients.


    >Yep, I excluded "C" from VSP for *all* Windows clients across the whole


    >organization - and - guess what - the backups ran quicker with fewer
    >problems . My two cents is, VSP is good for any drive other than C:.
    >
    >Anyway, I digress again, back to your specific problem, you'll see why I


    >mentioned all the above when you get into it...
    >
    >
    >
    >Back to your problem.
    >
    >Some applications simply never release certain files. Even OpenVMS can't


    >backup open files that are in the process of being written - if OpenVMS


    >can't do it, then, guess what, you've got no chance with Windows. IMHO,


    >Windows is a toy/disposable OS (and no one in their right mind would run

    a
    >critical "bust your business" application on a Windows server) - instead

    you
    >run "bust your business" apps on "bet your business" servers - i.e. OpenVMS.
    >
    >Sorry, I digressed again...
    >
    >
    >
    >Anyway, hopefully you're starting to see that "sometimes" some files just


    >can't be secured because some operating systems just can't release the files


    >(and look at this way, no application or O/S is just simply going to release


    >files just because you want to run a backup) because they are too busy
    >writing to the file. To expect all NetBackup clients to backup all files

    on
    >all operating systems on all servers all the time is, well, pure fantasy.
    >
    >
    >
    >Anyway, back to your problem...
    >
    >The way I see it is you have three choices (each progressively harder) to


    >achieve a "blue" status zero and thus a complete and completely reliable


    >backup...
    >
    >1) Simply exclude the problem file, but only if it has been agreed that

    the
    >file isn't critical for audit purposes (always get management sign off
    >before excluding *any* file). In your case, apply an exclusion (to the
    >client) of "F:\folder\folder\D*_*_*x*.log" (remember - always try to get

    the
    >best wildcard pattern that matches the least number of your problem file(s),


    >*but* doesn't also cover (and thus exclude) too many other non-problem
    >files).
    >....or...
    >2) Shutdown the app (or service) that is writing the data or log file.

    You
    >use bpstart_notify and bpend_notify for this, see the manual(s). This way


    >the app/service is shutdown before the backup starts, and started again


    >after the backup completes. This is my favourite approach.
    >....or...
    >3) If you can't use option 2 *and* the exclude from option 1 covers too

    many
    >other files (e.g. a collection of logs in one folder), then I use a
    >bpstart_notify script to move all the "old", and thus closed, log files

    to
    >another folder so that they get secured/backed-up because they no longer


    >exist in the folder that has the exclusion from option 1. What I mean is,

    I
    >move all the closed file to another folder. The exclusion still ensures


    >that the one or two locked files are excluded, but because the
    >
    >It just depends how important your files are . Most of the time it's

    a
    >simple option 1. *BUT* always first check with your friendly neighbourhood


    >technical application support team. Never, and I mean *never* ever exclude


    >a file just because you want to.
    >
    >
    >Hope this helps dude.
    >
    >Regards,
    >Dave.
    >
    >



+ Reply to Thread