Please critique my backup practices - VMS

This is a discussion on Please critique my backup practices - VMS ; To do a backup, I pop a drive out of a shadowset, back it up and put it back. The problem is, I don't record the backup dates. I have a incremental that runs every night that does record backup ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 45

Thread: Please critique my backup practices

  1. Please critique my backup practices

    To do a backup, I pop a drive out of a shadowset, back it up and put
    it back.

    The problem is, I don't record the backup dates.

    I have a incremental that runs every night that does record backup
    dates.

    If I had to restore, I would apply the last image and all the
    incrementals after it. But I guess I would get some extra files.

    This is easy, I never have to shutdown, but what are the gotchas?

    Note that if I am *planning* to do a restore I don't use incrementals,
    I just use a fresh image backup.

    I have never had to do an emergency image restore using incrementals.

  2. Re: Please critique my backup practices

    tadamsmar wrote:
    > To do a backup, I pop a drive out of a shadowset, back it up and put
    > it back.
    >
    > The problem is, I don't record the backup dates.
    >
    > I have a incremental that runs every night that does record backup
    > dates.
    >
    > If I had to restore, I would apply the last image and all the
    > incrementals after it. But I guess I would get some extra files.
    >
    > This is easy, I never have to shutdown, but what are the gotchas?
    >
    > Note that if I am *planning* to do a restore I don't use incrementals,
    > I just use a fresh image backup.
    >
    > I have never had to do an emergency image restore using incrementals.


    I'd avoid doing emergency restores using incrementals if at all
    possible! Somebody has to load all those incrementals and do it in the
    proper order! A slightly better choice would be to use differential
    backups. Do your image once weekly and each succeeding day, do a BACKUP
    /SINCE=. That way there are only two backups
    to restore with only one right way and one wrong way to restore.

    Remember that emergency restores are "panic time" when it's easiest to
    screw up! When your boss is hovering over your desk saying "how much
    longer" every two or three minutes, is NOT a good time to try to do
    anything in any way more complicated than it absolutely has to be.

    If you do your full backups with /RECORD you can do your differential
    with /SINCE=BACKUP. This is better because you let the machine do your
    bookeeping! It's less likely to screw up than you are!


  3. Re: Please critique my backup practices

    On Thu, 20 Mar 2008 07:28:00 -0700, Richard B. Gilbert
    wrote:

    > tadamsmar wrote:
    >> To do a backup, I pop a drive out of a shadowset, back it up and put
    >> it back.
    >> The problem is, I don't record the backup dates.
    >> I have a incremental that runs every night that does record backup
    >> dates.
    >> If I had to restore, I would apply the last image and all the
    >> incrementals after it. But I guess I would get some extra files.
    >> This is easy, I never have to shutdown, but what are the gotchas?
    >> Note that if I am *planning* to do a restore I don't use incrementals,
    >> I just use a fresh image backup.
    >> I have never had to do an emergency image restore using incrementals..

    >
    > I'd avoid doing emergency restores using incrementals if at all
    > possible! Somebody has to load all those incrementals and do it in the
    > proper order! A slightly better choice would be to use differential
    > backups. Do your image once weekly and each succeeding day, do a BACKUP
    > /SINCE=. That way there are only two backups
    > to restore with only one right way and one wrong way to restore.
    >
    > Remember that emergency restores are "panic time" when it's easiest to
    > screw up! When your boss is hovering over your desk saying "how much
    > longer" every two or three minutes, is NOT a good time to try to do
    > anything in any way more complicated than it absolutely has to be.
    >
    > If you do your full backups with /RECORD you can do your differential
    > with /SINCE=BACKUP. This is better because you let the machine do your
    > bookeeping! It's less likely to screw up than you are!
    >

    For incrementals Tower of Hanoi algorithm is usually employed, googling

    http://unix.derkeiler.com/Mailing-Li...5-08/1598.html


    --
    PL/I for OpenVMS
    www.kednos.com

  4. What sysgen param needs to be changed?

    Trying to open files over DECNET (IV) and I get the error below:

    -RMS-E-ACC, ACP file access failed
    -SYSTEM-F-REMRSRC, insufficient system resources at remote node

    Is this caused by a SYSGEN param. or an account setting for the DECNET
    account or both ?



  5. Re: What sysgen param needs to be changed?

    On Thu, 20 Mar 2008, Hank Vander Waal wrote:

    > Trying to open files over DECNET (IV) and I get the error below:
    >
    > -RMS-E-ACC, ACP file access failed
    > -SYSTEM-F-REMRSRC, insufficient system resources at remote node
    >
    > Is this caused by a SYSGEN param. or an account setting for the
    > DECNET account or both ?


    What does NETSERVER.LOG on the remote node say? This file will be in
    the login in directory of the remote user.


    --

    Rob Brown b r o w n a t g m c l d o t c o m
    G. Michaels Consulting Ltd. (780)438-9343 (voice)
    Edmonton (780)437-3367 (FAX)
    http://gmcl.com/


  6. RE: What sysgen param needs to be changed?


    I am running the program on I64 and the programs are on that machine. I am
    opening files on alpha 7.1 system
    The netserver.log file does not show any errors

    -----Original Message-----
    From: Rob Brooks [mailto:brooks@cuebid.zko.hp.nospam]
    Sent: Thursday, March 20, 2008 2:21 PM
    To: Info-VAX@Mvb.Saic.Com
    Subject: Re: What sysgen param needs to be changed?

    "Hank Vander Waal" writes:
    > Trying to open files over DECNET (IV) and I get the error below:
    >
    > -RMS-E-ACC, ACP file access failed
    > -SYSTEM-F-REMRSRC, insufficient system resources at remote node
    >
    > Is this caused by a SYSGEN param. or an account setting for the DECNET
    > account or both ?


    What version of the Operating system and platform are you using?

    I believe there is an issue with activating I64 images over the network,
    although I don't know how that error would be signalled.

    --

    Rob Brooks MSL -- Nashua brooks!cuebid.zko.hp.com


  7. RE: What sysgen param needs to be changed?


    $ V = F$VERIFY(NETSERVER$VERIFY)

    --------------------------------------------------------

    Connect request received at 20-MAR-2008 12:43:14.92
    from remote process YETI::"0=HANKVW"
    for object "SYS$COMMON:[SYSEXE]FAL.EXE"

    --------------------------------------------------------

    %PURGE-W-FILNOTPUR, error deleting DRA0:[HANKVW]NETSERVER.LOG;8
    -RMS-E-FLK, file currently locked by another user
    %PURGE-W-FILNOTPUR, error deleting DRA0:[HANKVW]NETSERVER.LOG;7

    And that's all

    -----Original Message-----
    From: Rob Brown [mailto:mylastname@gmcl.com]
    Sent: Thursday, March 20, 2008 12:44 PM
    To: Info-VAX@Mvb.Saic.Com
    Subject: Re: What sysgen param needs to be changed?

    On Thu, 20 Mar 2008, Hank Vander Waal wrote:

    > Trying to open files over DECNET (IV) and I get the error below:
    >
    > -RMS-E-ACC, ACP file access failed
    > -SYSTEM-F-REMRSRC, insufficient system resources at remote node
    >
    > Is this caused by a SYSGEN param. or an account setting for the
    > DECNET account or both ?


    What does NETSERVER.LOG on the remote node say? This file will be in
    the login in directory of the remote user.


    --

    Rob Brown b r o w n a t g m c l d o t c o m
    G. Michaels Consulting Ltd. (780)438-9343 (voice)
    Edmonton (780)437-3367 (FAX)
    http://gmcl.com/


  8. Re: What sysgen param needs to be changed?

    "Hank Vander Waal" writes:
    > Trying to open files over DECNET (IV) and I get the error below:
    >
    > -RMS-E-ACC, ACP file access failed
    > -SYSTEM-F-REMRSRC, insufficient system resources at remote node
    >
    > Is this caused by a SYSGEN param. or an account setting for the DECNET
    > account or both ?


    What version of the Operating system and platform are you using?

    I believe there is an issue with activating I64 images over the network,
    although I don't know how that error would be signalled.

    --

    Rob Brooks MSL -- Nashua brooks!cuebid.zko.hp.com

  9. Re: Please critique my backup practices

    On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar wrote:
    > To do a backup, I pop a drive out of a shadowset, back it up and put
    > it back.


    I assume you're talking about VMS Volume Shadowing. As far as I know,
    taking a drive out of a shadowset causes the drive to look the same as
    if there'd been a power failure. In other words, it does not properly
    close open files.

    I assume that you take image backups. If so, there's no benefit to
    taking the drive out of the shadowset to take the image backup.
    According to service techs that I talked to when I first set up
    volume shadowing, there's no advantage over taking an image backup
    of the volume set (the DSA device).

    I assume that this is still true.

    > The problem is, I don't record the backup dates.


    You could record backup dates if you simply took an image backup
    of the volume set.

    > I have a incremental that runs every night that does record backup
    > dates.


    > If I had to restore, I would apply the last image and all the
    > incrementals after it. But I guess I would get some extra files.


    > This is easy, I never have to shutdown, but what are the gotchas?


    > Note that if I am *planning* to do a restore I don't use incrementals,
    > I just use a fresh image backup.


    > I have never had to do an emergency image restore using incrementals.


    I'm not an expert, so what I've said above may be wrong. You should
    check this backup scheme with the service techs (I assume you have
    a support contract).

    --
    Dale Dellutri (lose the Q's)

  10. Re: What sysgen param needs to be changed?

    In article <007f01c88aa4$99db60e0$6500a8c0@dellxp30>, "Hank Vander Waal" writes:
    > Trying to open files over DECNET (IV) and I get the error below:
    >
    > -RMS-E-ACC, ACP file access failed
    > -SYSTEM-F-REMRSRC, insufficient system resources at remote node
    >
    > Is this caused by a SYSGEN param. or an account setting for the DECNET
    > account or both ?


    Could be either. Someone on the remote node needs to investigate.


  11. Re: Please critique my backup practices

    On Mar 20, 2:36*pm, Dale Dellutri wrote:
    > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar wrote:
    > > To do a backup, I pop a drive out of a shadowset, back it up and put
    > > it back.

    >
    > I assume you're talking about VMS Volume Shadowing. *As far as I know,
    > taking a drive out of a shadowset causes the drive to look the same as
    > if there'd been a power failure. *In other words, it does not properly
    > close open files.
    >
    > I assume that you take image backups. *If so, there's no benefit to
    > taking the drive out of the shadowset to take the image backup.
    > According to service techs that I talked to when I first set up
    > volume shadowing, there's no advantage over taking an image backup
    > of the volume set (the DSA device).
    >
    > I assume that this is still true.
    >
    > > The problem is, I don't record the backup dates.

    >
    > You could record backup dates if you simply took an image backup
    > of the volume set.


    Don't I have to shutdown my system to do that?

    >
    > > I have a incremental that runs every night that does record backup
    > > dates.
    > > If I had to restore, I would apply the last image and all the
    > > incrementals after it. *But I guess I would get some extra files.
    > > This is easy, I never have to shutdown, but what are the gotchas?
    > > Note that if I am *planning* to do a restore I don't use incrementals,
    > > I just use a fresh image backup.
    > > I have never had to do an emergency image restore using incrementals.

    >
    > I'm not an expert, so what I've said above may be wrong. *You should
    > check this backup scheme with the service techs (I assume you have
    > a support contract).
    >
    > --
    > Dale Dellutri (lose the Q's)



  12. Re: Please critique my backup practices


    "tadamsmar" wrote in message
    news:26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com...
    > To do a backup, I pop a drive out of a shadowset, back it up and put
    > it back.
    >
    > The problem is, I don't record the backup dates.
    >
    > I have a incremental that runs every night that does record backup
    > dates.
    >
    > If I had to restore, I would apply the last image and all the
    > incrementals after it. But I guess I would get some extra files.
    >
    > This is easy, I never have to shutdown, but what are the gotchas?
    >
    > Note that if I am *planning* to do a restore I don't use incrementals,
    > I just use a fresh image backup.
    >
    > I have never had to do an emergency image restore using incrementals.


    Give the community some more background and you may get better answers.
    Relevant practices may vary depending on what you're backing up (a system
    disk, a generic data disk with various files on it, a "pure database" disk
    with nothing on it except the database itself in which case it may have its
    own backup tools...).

    E.g. when I cared about backups, in a software development environment, it
    was always a goal to have files on at least two sets of media (even files
    which may only have existed for a couple of days), so that if there was a
    problem and one set of media wasn't usable for whatever reason, the relevant
    files would still be recoverable from another set. This was done by
    abandoning the usual "incremental" or "differential" schemes and doing a
    weekly full backup and a daily backup with files created in the previous two
    (or do I mean three) days, so each new file would go on the following day's
    daily backup, AND the daily one after that. Others might have a "version
    management" tool in place to achieve the same end result, which might have
    changed the backup requirement. One backup strategy does not necessarily fit
    all, not comfortably anyway.

    Usually the only time you need completely shut down VMS for doing a backup
    is if you want a clean image backup of your system disk - always assuming
    that any applications you may have active can be persuaded to close any
    files they may have opened, without shutting VMS down. For example, BASEstar
    (which you have previously mentioned) sometimes has lots of global section
    files, which should disappear (or at least close cleanly) when you shut down
    BASEstar. Then again, some BASEstar installations I have known have needed
    BASEstar running 24x7x365. Keeping the system up and running was more
    important than the small risk of global sections being inconsistent on the
    backup (generally the global sections could be recreated correctly and
    simply from other data within BASEstar). Other applications may not all be
    so well behaved. You need to understand your needs and relevant application
    behaviours.

    Regards
    John



  13. Re: Please critique my backup practices

    On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar wrote:
    > On Mar 20, 2:36?pm, Dale Dellutri wrote:
    > > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar wrote:
    > > > To do a backup, I pop a drive out of a shadowset, back it up and put
    > > > it back.

    > >
    > > I assume you're talking about VMS Volume Shadowing. ?As far as I know,
    > > taking a drive out of a shadowset causes the drive to look the same as
    > > if there'd been a power failure. ?In other words, it does not properly
    > > close open files.
    > >
    > > I assume that you take image backups. ?If so, there's no benefit to
    > > taking the drive out of the shadowset to take the image backup.
    > > According to service techs that I talked to when I first set up
    > > volume shadowing, there's no advantage over taking an image backup
    > > of the volume set (the DSA device).
    > >
    > > I assume that this is still true.
    > >
    > > > The problem is, I don't record the backup dates.

    > >
    > > You could record backup dates if you simply took an image backup
    > > of the volume set.


    > Don't I have to shutdown my system to do that?


    I don't know. It depends on what you're running.

    I just said that when I checked into this, taking a disk out of
    a shadow set to take an image backup gives you no advantage over
    simply making an image backup of the volume set on the running
    system.

    Also, as I said below, I could be wrong. Please check with
    your service techs.

    > >
    > > > I have a incremental that runs every night that does record backup
    > > > dates.
    > > > If I had to restore, I would apply the last image and all the
    > > > incrementals after it. ?But I guess I would get some extra files.
    > > > This is easy, I never have to shutdown, but what are the gotchas?
    > > > Note that if I am *planning* to do a restore I don't use incrementals,
    > > > I just use a fresh image backup.
    > > > I have never had to do an emergency image restore using incrementals.

    > >
    > > I'm not an expert, so what I've said above may be wrong. ?You should
    > > check this backup scheme with the service techs (I assume you have
    > > a support contract).


    --
    Dale Dellutri (lose the Q's)

  14. Re: Please critique my backup practices

    On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar wrote:
    > On Mar 20, 2:36?pm, Dale Dellutri wrote:
    > > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar wrote:
    > > > To do a backup, I pop a drive out of a shadowset, back it up and put
    > > > it back.

    > >
    > > I assume you're talking about VMS Volume Shadowing. ?As far as I know,
    > > taking a drive out of a shadowset causes the drive to look the same as
    > > if there'd been a power failure. ?In other words, it does not properly
    > > close open files.
    > >
    > > I assume that you take image backups. ?If so, there's no benefit to
    > > taking the drive out of the shadowset to take the image backup.
    > > According to service techs that I talked to when I first set up
    > > volume shadowing, there's no advantage over taking an image backup
    > > of the volume set (the DSA device).
    > >
    > > I assume that this is still true.
    > >
    > > > The problem is, I don't record the backup dates.

    > >
    > > You could record backup dates if you simply took an image backup
    > > of the volume set.


    > Don't I have to shutdown my system to do that?


    I finally found the relevant item in "HP Volume Shadowing for
    OpenVMS", v7.3-2. Chapter 7, Section titled "Data Consistency
    Requirements": "Removal of a shadow set member results in what
    is called a crash-consistent copy. That is, the copy of the
    data on the removed member is of the same level of consistency
    as what would result if the system had failed at that instant."
    (pg 124 in my copy).

    Actually, reading the entire section titled "Guidelines for
    for Using a Shadow Member for Backup" would be very useful.

    > >
    > > > I have a incremental that runs every night that does record backup
    > > > dates.
    > > > If I had to restore, I would apply the last image and all the
    > > > incrementals after it. ?But I guess I would get some extra files.
    > > > This is easy, I never have to shutdown, but what are the gotchas?
    > > > Note that if I am *planning* to do a restore I don't use incrementals,
    > > > I just use a fresh image backup.
    > > > I have never had to do an emergency image restore using incrementals.

    > >
    > > I'm not an expert, so what I've said above may be wrong. ?You should
    > > check this backup scheme with the service techs (I assume you have
    > > a support contract).



    --
    Dale Dellutri (lose the Q's)

  15. Re: Please critique my backup practices

    On Mar 20, 4:06*pm, "John Wallace"
    wrote:
    > "tadamsmar" wrote in message
    >
    > news:26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com...
    >
    >
    >
    >
    >
    > > To do a backup, I pop a drive out of a shadowset, back it up and put
    > > it back.

    >
    > > The problem is, I don't record the backup dates.

    >
    > > I have a incremental that runs every night that does record backup
    > > dates.

    >
    > > If I had to restore, I would apply the last image and all the
    > > incrementals after it. *But I guess I would get some extra files.

    >
    > > This is easy, I never have to shutdown, but what are the gotchas?

    >
    > > Note that if I am *planning* to do a restore I don't use incrementals,
    > > I just use a fresh image backup.

    >
    > > I have never had to do an emergency image restore using incrementals.

    >
    > Give the community some more background and you may get better answers.
    > Relevant practices may vary depending on what you're backing up (a system
    > disk, a generic data disk with various files on it, a "pure database" disk
    > with nothing on it except the database itself in which case it may have its
    > own backup tools...).
    >
    > E.g. when I cared about backups, in a software development environment, it
    > was always a goal to have files on at least two sets of media (even files
    > which may only have existed for a couple of days), so that if there was a
    > problem and one set of media wasn't usable for whatever reason, the relevant
    > files would still be recoverable from another set. This was done by
    > abandoning the usual "incremental" or "differential" schemes and doing a
    > weekly full backup and a daily backup with files created in the previous two
    > (or do I mean three) days, so each new file would go on the following day's
    > daily backup, AND the daily one after that. Others might have a "version
    > management" tool in place to achieve the same end result, which might have
    > changed the backup requirement. One backup strategy does not necessarily fit
    > all, not comfortably anyway.
    >
    > Usually the only time you need completely shut down VMS for doing a backup
    > is if you want a clean image backup of your system disk - always assuming
    > that any applications you may have active can be persuaded to close any
    > files they may have opened, without shutting VMS down. For example, BASEstar
    > (which you have previously mentioned) sometimes has lots of global section
    > files, which should disappear (or at least close cleanly) when you shut down
    > BASEstar. Then again, some BASEstar installations I have known have needed
    > BASEstar running 24x7x365. Keeping the system up and running was more
    > important than the small risk of global sections being inconsistent on the
    > backup (generally the global sections could be recreated correctly and
    > simply from other data within BASEstar). Other applications may not all be
    > so well behaved. You need to understand your needs and relevant application
    > behaviours.
    >
    > Regards
    > John- Hide quoted text -
    >
    > - Show quoted text -


    I am running VMS 7.3.2 on a DS10. I have shadowed system disks (2).
    This is about backing up a system disk.

    The app that runs on it is designed to come up clean after a crash.


  16. Re: Please critique my backup practices

    In article <13u5gub59gtbmca@corp.supernews.com>, johnwallace4
    @yahoo.spam.co.uk says...
    >
    > "tadamsmar" wrote in message
    > news:26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com...
    > > To do a backup, I pop a drive out of a shadowset, back it up and put
    > > it back.
    > >
    > > The problem is, I don't record the backup dates.
    > >
    > > I have a incremental that runs every night that does record backup
    > > dates.
    > >
    > > If I had to restore, I would apply the last image and all the
    > > incrementals after it. But I guess I would get some extra files.
    > >
    > > This is easy, I never have to shutdown, but what are the gotchas?
    > >
    > > Note that if I am *planning* to do a restore I don't use incrementals,
    > > I just use a fresh image backup.
    > >
    > > I have never had to do an emergency image restore using incrementals.

    >
    > Give the community some more background and you may get better answers.
    > Relevant practices may vary depending on what you're backing up (a system
    > disk, a generic data disk with various files on it, a "pure database" disk
    > with nothing on it except the database itself in which case it may have its
    > own backup tools...).
    >
    > E.g. when I cared about backups, in a software development environment, it
    > was always a goal to have files on at least two sets of media (even files
    > which may only have existed for a couple of days), so that if there was a
    > problem and one set of media wasn't usable for whatever reason, the relevant
    > files would still be recoverable from another set. This was done by
    > abandoning the usual "incremental" or "differential" schemes and doing a
    > weekly full backup and a daily backup with files created in the previous two
    > (or do I mean three) days, so each new file would go on the following day's
    > daily backup, AND the daily one after that. Others might have a "version
    > management" tool in place to achieve the same end result, which might have
    > changed the backup requirement. One backup strategy does not necessarily fit
    > all, not comfortably anyway.
    >
    > Usually the only time you need completely shut down VMS for doing a backup
    > is if you want a clean image backup of your system disk - always assuming
    > that any applications you may have active can be persuaded to close any
    > files they may have opened, without shutting VMS down. For example, BASEstar
    > (which you have previously mentioned) sometimes has lots of global section
    > files, which should disappear (or at least close cleanly) when you shut down
    > BASEstar. Then again, some BASEstar installations I have known have needed
    > BASEstar running 24x7x365. Keeping the system up and running was more
    > important than the small risk of global sections being inconsistent on the
    > backup (generally the global sections could be recreated correctly and
    > simply from other data within BASEstar). Other applications may not all be
    > so well behaved. You need to understand your needs and relevant application
    > behaviours.
    >
    > Regards
    > John
    >
    >
    >


    I want to second everything John said...

    The split-the-shadow-set, backup, rejoin the shadow-set method
    can be useful and reasonably safe, but you have to understand your
    applications.

    It's like hot-splicing an electrical circuit or mid-air refueling,
    if you have to ask, you probably shouldn't be doing it!

    If you can quiesce your application (close all files or at least
    flush all I/o buffers and hold it there, or activate a recovery
    journal or any of a dozen other techniques, and hold it there for
    a little while (10 seconds to a minute or so, depending on how
    automated everything is), you can dismount one member of the shadow
    set and be guaranteed it is complete and consistent as of that
    time. If you can't do this (like for a system disk), if you can
    make sure this is done at a quiet time, you can at least be
    reasonably sure that you've got a good snapshot, but you really
    need to understand what might be inconsistent and how to recognize
    and recover from any problems that occur when you try to restore.
    Often times, it will be just like trying to recover from a crash.

    For a system disk, the issues might be people logging in and changing
    info in the UAF, people changing passwords, creating, modifying or
    deleting user accounts, batch or print jobs (queue manager issues),
    etc. Don't be editing systartup_vms.com while starting up the
    backup! If you can be sure these things aren't happening (middle of
    the night, nothing in the batch or print queues currently printing
    or scheduled to execute in the next several minutes, etc.), then
    your odds of getting a usable backup are pretty good, but never 100%.

    Once you've split off the shadow set member, you can resume normal
    operations, unquiescing the application or restarting it as the
    case may be. Your time tag for the backup date is any time during
    the interval while everything is quiet. You'll need to write this
    down.

    Mount the split-out member privately with /nowrite, and back it up
    any way you wish (image, incremental, differential, random bunch of
    specific files, or whatever, depending on what's on the disk and your
    restore strategy.)

    *DON'T* use /RECORD!
    (You can't on a disk mounted /nowrite, and even if you did, the
    date stamps would all get erased when you add it back to the shadow
    set.)

    When the backup completes, dismount the disk, remount back into
    the shadow set (minicopy is a HUGE win here, reducing the copy
    time from hours to seconds.)

    There is no need to quiesce anything while adding the disk back
    into the set.

    The advantages of this over just doing a live backup of the shadow
    set are several-fold. Since the snapshot is done instantly and
    while there is no (or very little) activity, the chances of getting
    an inconsistent backup are greatly reduced (to zero if you can
    quiesce or shut down the application.) Even if the best you can
    do is do this during a relatively quiet time this is much better
    than doing a live backup of the active shadow set.

    The advantage of this method over an offline backup is speed. You
    don't have to shut the system down first and reboot it afterward.
    The application only has to be offline for a few seconds (or not
    at all if you have the hooks in it to record your own journal files
    to another disk while the disk being backed up is being split.)

    It doesn't matter how long the backup itself takes (well, if it
    takes too long, minicopy will approach normal copy times, and if
    it's a 2-member shadow set, you'll be working without a net until
    the member rejoins.)

    An advantage to doing the backup online, vs. booting the VMS CD
    and backing up from there (the only truly safe method of backing
    up a system disk) is you can script everything in DCL, so there
    are no typos (or at least no random, non-repeating operator typos),
    no mounting and backing up the wrong disk, the time critical bits
    (quiescing, dismounting, resuming) happen as fast as possible,
    which minimizes downtime, and you can keep a log of everything.

    BTW, since the time required by the backup doesn't matter much,
    I almost always do full image backups when using this method.

    To repeat all the warnings though, this method only gives
    reliable backups if the application can be quiesced or
    completely shutdown while the shadow set is being split.
    Otherwise some operation will write some data to both disks
    before the dismount and only to the remaining disk after the
    dismount, and your backup disk will be inconsistent, possibly
    in a way you won't notice till months later. (Data dry rot!)


    --
    John

  17. Re: Please critique my backup practices

    On Mar 20, 9:02 am, tadamsmar wrote:
    > To do a backup, I pop a drive out of a shadowset, back it up and put
    > it back.
    >
    > The problem is, I don't record the backup dates.


    Yes, that is a problem with this method.

    >
    > I have a incremental that runs every night that does record backup
    > dates.
    >
    > If I had to restore, I would apply the last image and all the
    > incrementals after it. But I guess I would get some extra files.


    No. You will get the disk restored to the state it was in as seen by
    your last incremental pass. The penalty is that your first incremental
    save set after the last image save was done will contain more files
    than necessary (and WAY more if there are no backup dates at all on
    the volume). But it all gets straightened out automatically during the
    restore. Incremental disk backups save all .DIR files so that BACKUP
    has all the information necessary to accomplish this.

    BACKUP/INCREMENTAL does this by comparing the backup date of each .DIR
    file in the save set with the matching .DIR file on the disk. Then
    BACKUP/INCREMENTAL uses the data in the more recent of the two and
    attempts to bring the matching directory to agree.

    If the save set .DIR file is more recent, BACKUP/INCREMENTAL deletes
    files in the matching directory on the disk that are not in the .DIR
    file in the save set, restores files from the save set for that
    directory, and creates empty file entries for files that are listed in
    its .DIR file, but are not found in the save set or already on disk.

    If the .DIR file on the disk is the more recent of the two, BACKUP/
    INCREMENTAL then simply restores every missing file it has a copy of.

    This is why you can restore the incremental save sets in any order,
    but the most efficient is to run them in reverse chronological order.
    With pre-V6.2 BACKUP, if you renamed any directories, then, TTBOMK,
    the disk can fill up even using reverse chronological order. The cure
    is to reapply the incrementals.

    [Well, I never tried using any old order with .GE.V6.2 BACKUP, but I
    don't see why it wouldn't work. It would just take longer than with
    reverse chronological order.]

    > This is easy, I never have to shutdown, but what are the gotchas?


    You need to close all files on the volume before removing the member
    by shutting down anything that is using it. (You can't do that if this
    is the SYSTEM disk, of course.) Otherwise, any files open for write
    might not be copied in a consistent manner (and won't be copied at all
    if you don't use /IGNORE=INTERLOCK).

    The proper way to do this is to shut down all apps accessing the
    volume. DISMOUNT the volume. Re-MOUNT the volume with one less member.
    Back up that member. Then put that member back into the shadow set.
    This way you avoid any problems with open files, incomplete I/O
    operations, etc.

    >
    > Note that if I am *planning* to do a restore I don't use incrementals,
    > I just use a fresh image backup.


    Good.

    >
    > I have never had to do an emergency image restore using incrementals.


    Also good! ;-)

    AEF

  18. Re: Please critique my backup practices

    On Mar 20, 9:28 am, "Richard B. Gilbert"
    wrote:
    > tadamsmar wrote:
    > > To do a backup, I pop a drive out of a shadowset, back it up and put
    > > it back.

    >
    > > The problem is, I don't record the backup dates.

    >
    > > I have a incremental that runs every night that does record backup
    > > dates.

    >
    > > If I had to restore, I would apply the last image and all the
    > > incrementals after it. But I guess I would get some extra files.

    >
    > > This is easy, I never have to shutdown, but what are the gotchas?

    >
    > > Note that if I am *planning* to do a restore I don't use incrementals,
    > > I just use a fresh image backup.

    >
    > > I have never had to do an emergency image restore using incrementals.

    >
    > I'd avoid doing emergency restores using incrementals if at all
    > possible! Somebody has to load all those incrementals and do it in the
    > proper order! A slightly better choice would be to use differential
    > backups. Do your image once weekly and each succeeding day, do a BACKUP
    > /SINCE=. That way there are only two backups
    > to restore with only one right way and one wrong way to restore.
    >
    > Remember that emergency restores are "panic time" when it's easiest to
    > screw up! When your boss is hovering over your desk saying "how much
    > longer" every two or three minutes, is NOT a good time to try to do
    > anything in any way more complicated than it absolutely has to be.
    >
    > If you do your full backups with /RECORD you can do your differential
    > with /SINCE=BACKUP. This is better because you let the machine do your
    > bookeeping! It's less likely to screw up than you are!


    I'm reasonably sure you can restore in any order, but reverse
    chronological is the most efficient.

    Differential backups are appropriate when your backup windows are
    large enough. You spend more time and resources saving, but restores
    are quicker as you only need to apply the latest image followed by the
    latest differential.

    But since BACKUP/INCREMENTAL deletes files from the volume that were
    not present at the time of the most recent save set that you've
    already restored, it shouldn't usually take a lot longer with the
    regular incremental method unless you've got a lot of tapes or have to
    skip over a lot of large files. It depends on your situation.

    AEF

  19. Re: Please critique my backup practices

    On Mar 20, 5:24 pm, John Santos wrote:
    > In article <13u5gub59gtb...@corp.supernews.com>, johnwallace4
    > @yahoo.spam.co.uk says...
    >
    >
    >
    >
    >
    > > "tadamsmar" wrote in message
    > >news:26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com...
    > > > To do a backup, I pop a drive out of a shadowset, back it up and put
    > > > it back.

    >
    > > > The problem is, I don't record the backup dates.

    >
    > > > I have a incremental that runs every night that does record backup
    > > > dates.

    >
    > > > If I had to restore, I would apply the last image and all the
    > > > incrementals after it. But I guess I would get some extra files.

    >
    > > > This is easy, I never have to shutdown, but what are the gotchas?

    >
    > > > Note that if I am *planning* to do a restore I don't use incrementals,
    > > > I just use a fresh image backup.

    >
    > > > I have never had to do an emergency image restore using incrementals.

    >
    > > Give the community some more background and you may get better answers.
    > > Relevant practices may vary depending on what you're backing up (a system
    > > disk, a generic data disk with various files on it, a "pure database" disk
    > > with nothing on it except the database itself in which case it may have its
    > > own backup tools...).

    >
    > > E.g. when I cared about backups, in a software development environment, it
    > > was always a goal to have files on at least two sets of media (even files
    > > which may only have existed for a couple of days), so that if there was a
    > > problem and one set of media wasn't usable for whatever reason, the relevant
    > > files would still be recoverable from another set. This was done by
    > > abandoning the usual "incremental" or "differential" schemes and doing a
    > > weekly full backup and a daily backup with files created in the previous two
    > > (or do I mean three) days, so each new file would go on the following day's
    > > daily backup, AND the daily one after that. Others might have a "version
    > > management" tool in place to achieve the same end result, which might have
    > > changed the backup requirement. One backup strategy does not necessarily fit
    > > all, not comfortably anyway.

    >
    > > Usually the only time you need completely shut down VMS for doing a backup
    > > is if you want a clean image backup of your system disk - always assuming
    > > that any applications you may have active can be persuaded to close any
    > > files they may have opened, without shutting VMS down. For example, BASEstar
    > > (which you have previously mentioned) sometimes has lots of global section
    > > files, which should disappear (or at least close cleanly) when you shut down
    > > BASEstar. Then again, some BASEstar installations I have known have needed
    > > BASEstar running 24x7x365. Keeping the system up and running was more
    > > important than the small risk of global sections being inconsistent on the
    > > backup (generally the global sections could be recreated correctly and
    > > simply from other data within BASEstar). Other applications may not all be
    > > so well behaved. You need to understand your needs and relevant application
    > > behaviours.

    >
    > > Regards
    > > John

    >
    > I want to second everything John said...
    >
    > The split-the-shadow-set, backup, rejoin the shadow-set method
    > can be useful and reasonably safe, but you have to understand your
    > applications.
    >
    > It's like hot-splicing an electrical circuit or mid-air refueling,
    > if you have to ask, you probably shouldn't be doing it!
    >
    > If you can quiesce your application (close all files or at least
    > flush all I/o buffers and hold it there, or activate a recovery
    > journal or any of a dozen other techniques, and hold it there for
    > a little while (10 seconds to a minute or so, depending on how
    > automated everything is), you can dismount one member of the shadow
    > set and be guaranteed it is complete and consistent as of that
    > time. If you can't do this (like for a system disk), if you can
    > make sure this is done at a quiet time, you can at least be
    > reasonably sure that you've got a good snapshot, but you really
    > need to understand what might be inconsistent and how to recognize
    > and recover from any problems that occur when you try to restore.
    > Often times, it will be just like trying to recover from a crash.
    >

    [...]
    >
    > To repeat all the warnings though, this method only gives
    > reliable backups if the application can be quiesced or
    > completely shutdown while the shadow set is being split.
    > Otherwise some operation will write some data to both disks
    > before the dismount and only to the remaining disk after the
    > dismount, and your backup disk will be inconsistent, possibly
    > in a way you won't notice till months later. (Data dry rot!)
    >
    > --
    > John


    I believe the recommended and cleanest method is the following:

    Shut down everything accessing the volume, thereby closing all files
    (except system access to INDEXF.SYS, of course.)

    DISMOUNT the shadow set. (This avoids the dismounted improperly
    syndrome.)

    Re-MOUNT the shadow set minus one member.

    MOUNT the removed member separately and back it up.

    DISMOUNT the removed, backed-up member (now it's own volume).

    Add the backed-up member back to the original shadow set.

    AEF

  20. Re: Please critique my backup practices

    In article
    <26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com>,
    tadamsmar writes:

    > To do a backup, I pop a drive out of a shadowset, back it up and put
    > it back.


    Are there any open files on the shadow set?


+ Reply to Thread
Page 1 of 3 1 2 3 LastLast