Please critique my backup practices - VMS

This is a discussion on Please critique my backup practices - VMS ; "John Santos" wrote in message news:MPG.224cae69cfdc8d4b989793@news.bellatlantic. net... > In article , 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 ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 45

Thread: Please critique my backup practices

  1. Re: Please critique my backup practices


    "John Santos" wrote in message
    news:MPG.224cae69cfdc8d4b989793@news.bellatlantic. net...
    > 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


    Thank you for the kind words. However, I actually forgot some of the most
    important words (they were implied, but not made explicit). That is: the
    backup strategy has to be driven by what's important when doing a *restore*.
    E.g. A fast non-selective bare-metal restore may lead to different
    procedures than something designed for ease of restoration of individual
    files. Again, one size does not fit all.

    It's helpful to actually test the restore procedures occasionally too,
    though testing does not necessarily expose latent flaws such as the "data
    dry rot" you mention (you don't even need a shadowset for that kind of
    problem, back in the days of IAS, ANALYSE/DISK/REPAIR didn't properly lock
    the disk, and when two apps both thought they had control of space
    allocation... well, the damage was instant, but it wasn't instantly
    *obvious*, till corrupt files started appearing, because blocks had become
    "owned" by more than one file. A serious learning exercise.).

    Doing backups/restores properly isn't always easy. But if they're not done
    properly, there's little point doing them at all, it's just a false sense of
    security.

    2p
    John



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

    In article , Rob Brown writes:
    > 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.


    If there weren't enough resouces to open the link, there may not have
    been enough accomplished on the remote node to open the log.


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

    In article <009001c88ab1$e57f2a60$6500a8c0@dellxp30>, "Hank Vander Waal" writes:
    >
    > Connect request received at 20-MAR-2008 12:43:14.92


    Can you corrrelate that system time to your access attempt?


  4. Re: Please critique my backup practices

    In article , helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    > 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?


    If there are, then quiescing the disk is the way to improve this process.

    The advantage of breaking the shadow set over just doing a backup is
    that breaking the shadow set gives a quick way to snapshot a disk that
    has been momentarily quiesced.

  5. Re: Please critique my backup practices

    On Mar 20, 6: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 previoustwo
    > > (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 necessarilyfit
    > > 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.


    Does VMS have any real problems coming back up after a power failure?
    I have never seen any?

    I wrote the app on this computers. Its designed to come up clean
    after a power failure.

    I am backing up the system disk.

    >
    > 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,


    Anybody that has an extra disk can script everything. You
    can probably put it on a floppy, but I never tried that.

    You just mount the extra disk and run the script (command file) off
    that.

    > 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- Hide quoted text -
    >
    > - Show quoted text -



  6. Re: Please critique my backup practices

    On Mar 21, 9:37*am, "John Wallace"
    wrote:
    > "John Santos" wrote in message
    >
    > news:MPG.224cae69cfdc8d4b989793@news.bellatlantic. net...> 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 doinga
    > > > 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

    >
    > Thank you for the kind words. However, I actually forgot some of the most
    > important words (they were implied, but not made explicit). That is: the
    > backup strategy has to be driven by what's important when doing a *restore*.
    > E.g. A fast non-selective bare-metal restore may lead to different
    > procedures than something designed for ease of restoration of individual
    > files. Again, one size does not fit all.
    >
    > It's helpful to actually test the restore procedures occasionally too,
    > though testing does not necessarily expose latent flaws such as the "data
    > dry rot" you mention (you don't even need a shadowset for that kind of
    > problem, back in the days of IAS, ANALYSE/DISK/REPAIR didn't properly lock
    > the disk, and when two apps both thought they had control of space
    > allocation... well, the damage was instant, but it wasn't instantly
    > *obvious*, till corrupt files started appearing, because blocks had become
    > "owned" by more than one file. A serious learning exercise.).
    >
    > Doing backups/restores properly isn't always easy. But if they're not done
    > properly, there's little point doing them at all, it's just a false sense of
    > security.
    >
    > 2p
    > John- Hide quoted text -
    >
    > - Show quoted text -


    BTW, the image/incrementals are not my only recovery strategy.

    I backup key application files every night to two other alphas.

    If a system fails, I can get the app up on a backup computer in less
    than 30 minutes without any tapes.

    I have never had to do a restore an image from tape. I think in terms
    of a fire or something that would destroy both disks in the
    shadowset. If I just had an ordinary computer failure, swapping out a
    disk (or both disks) to another computer would be the fastest
    recovery perhaps. (I do have one oddball AS800 with disks I can't
    swap, but its not really being used for production.)

    I guess somebody could issue a massive delete by accident, that might
    force an image recovery.



  7. Re: Please critique my backup practices

    On Mar 21, 10:26*am, Kilgal...@SpamCop.net (Larry Kilgallen) wrote:
    > In article , hel...@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
    >
    > > In article
    > > <26eb56f6-ec7b-42be-bf46-64def0b22...@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?

    >
    > If there are, then quiescing the disk is the way to improve this process.
    >
    > The advantage of breaking the shadow set over just doing a backup is
    > that breaking the shadow set gives a quick way to snapshot a disk that
    > has been momentarily quiesced.


    Does VMS 7.3.2 have a power failure problem that I have never seen? I
    don't recall anything more than an automate disk rebuild.

    I wrote the app and its designed for power failure recovery.

    So what does quiescence buy me?

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

    Bob & all,
    I have several users on the remote site that are working its when I get more
    than a couple of them, and each one opens about 15 files, that I get the
    error. I am not sure if it is a user setting or a SYSGEN setting?
    The netserver.log file does not report any errors

    -----Original Message-----
    From: Bob Koehler [mailto:koehler@eisner.nospam.encompasserve.org]
    Sent: Friday, March 21, 2008 10:17 AM
    To: Info-VAX@Mvb.Saic.Com
    Subject: Re: What sysgen param needs to be changed?

    In article , Rob
    Brown writes:
    > 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.


    If there weren't enough resouces to open the link, there may not have
    been enough accomplished on the remote node to open the log.


  9. Re: Please critique my backup practices

    On Mar 21, 9:49 am, tadamsmar wrote:
    [...]
    > > - Show quoted text -

    >
    > BTW, the image/incrementals are not my only recovery strategy.
    >
    > I backup key application files every night to two other alphas.
    >
    > If a system fails, I can get the app up on a backup computer in less
    > than 30 minutes without any tapes.
    >
    > I have never had to do a restore an image from tape. I think in terms
    > of a fire or something that would destroy both disks in the
    > shadowset. If I just had an ordinary computer failure, swapping out a
    > disk (or both disks) to another computer would be the fastest
    > recovery perhaps. (I do have one oddball AS800 with disks I can't
    > swap, but its not really being used for production.)
    >
    > I guess somebody could issue a massive delete by accident, that might
    > force an image recovery.


    Yes. This is why volume shadowing is not a substitute for doing
    backups. Also, do you send any backup tapes off-site in case of
    building fire or the like?

    AEF

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

    On Mar 20, 12:41 pm, "Hank Vander Waal" wrote:
    > 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:bro...@cuebid.zko.hp.nospam]
    > Sent: Thursday, March 20, 2008 2:21 PM
    > To: Info-...@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


    Is it possible that you've reached the maximum number of links allowed
    on the remote node? Run MCR NCP SHOW EXEC and MCR NCP SHOW KNOWN LINKS
    on the remote node and see if the numbers are close or equal.

    AEF

  11. Re: Please critique my backup practices

    Dale Dellutri wrote:
    >
    > 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.


    The usual technique is to quiesce the application (cause it to close its
    files), THEN split the shadow-sets. We do something similar with BCVs on
    an EMC DMX array. This minimizes your "backup window".

    Once upon many moons ago, I developed some code that would take a
    BACKUP/LIST file and produce a file list for use with DFU's SET command
    such that backup dates could be recorded after a shadow-set split
    backup.

    I could probably resurrect that, if needed. It uses SEARCH to reduce the
    data to the list of files and EDT in batch(!!) to perform the final
    edits and cleanup. The result gets fed to the SET command in DFU:

    $ MCR DFU SET/BACKUP='date' "@filespec"

    Use SET PROC/PRIO=0 before invoking DFU to minimize impact on
    production.

    David J Dachtera
    (formerly dba) DJE Systems

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

    Remote file opens do not count toward your vms licenses do they ??
    I have found that by increasing the ncp alias file limit I could get more
    people accessing the system.

    -----Original Message-----
    From: Bob Koehler [mailto:koehler@eisner.nospam.encompasserve.org]
    Sent: Friday, March 21, 2008 3:04 PM
    To: Info-VAX@Mvb.Saic.Com
    Subject: RE: What sysgen param needs to be changed?

    In article <010201c88b66$2c3c8d30$6500a8c0@dellxp30>, "Hank Vander Waal"
    writes:
    > Bob & all,
    > I have several users on the remote site that are working its when I get

    more
    > than a couple of them, and each one opens about 15 files, that I get the
    > error. I am not sure if it is a user setting or a SYSGEN setting?
    > The netserver.log file does not report any errors
    >


    Do you by any chance have a limited number of users in the VMS
    license for the remote system?

    If not, I'd check the pool and page file, using SHOW MEMORY.


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

    In article <010201c88b66$2c3c8d30$6500a8c0@dellxp30>, "Hank Vander Waal" writes:
    > Bob & all,
    > I have several users on the remote site that are working its when I get more
    > than a couple of them, and each one opens about 15 files, that I get the
    > error. I am not sure if it is a user setting or a SYSGEN setting?
    > The netserver.log file does not report any errors
    >


    Do you by any chance have a limited number of users in the VMS
    license for the remote system?

    If not, I'd check the pool and page file, using SHOW MEMORY.


  14. Re: Please critique my backup practices

    We have heard many time: "Thou shalt not use BACKUP/IGNORE=INTERLOCK".
    But I have an application that runs continuously and doesn't close its
    files, so the alternative is no backup of them. I had the idea of doing
    two incremental backups, the first being a BACKUP/MOD/SINCE=BACKUP/RECORD
    of the disk, and the second being BACKUP/MOD/SINCE=BACKUP/IGNORE=INTERLOCK
    (note: no /RECORD) of the disk. The first is a "clean" incremental backup
    of the disk, and the second, since it is run immediately after the first,
    will contain only open files plus perhaps a few modified very recently.
    It would only be used in emergencies. The lack of /RECORD is so the files
    backed up on the second backup are not considered properly backed up, and
    any file closed before the next pass of incremental backups will be
    properly backed up during the next pass. Comments?


  15. Re: Please critique my backup practices

    Michael Moroney wrote:
    > We have heard many time: "Thou shalt not use BACKUP/IGNORE=INTERLOCK".
    > But I have an application that runs continuously and doesn't close its
    > files, so the alternative is no backup of them. I had the idea of doing
    > two incremental backups, the first being a BACKUP/MOD/SINCE=BACKUP/RECORD
    > of the disk, and the second being BACKUP/MOD/SINCE=BACKUP/IGNORE=INTERLOCK
    > (note: no /RECORD) of the disk. The first is a "clean" incremental backup
    > of the disk, and the second, since it is run immediately after the first,
    > will contain only open files plus perhaps a few modified very recently.
    > It would only be used in emergencies. The lack of /RECORD is so the files
    > backed up on the second backup are not considered properly backed up, and
    > any file closed before the next pass of incremental backups will be
    > properly backed up during the next pass. Comments?
    >


    If you can't stop the application, you can't guarantee a consistent
    backup! Some applications, such as databases, provide a means to get a
    consistent backup. If yours does not, you could ask the vendor how to
    back up those files in such a way that a restore will be valid and
    usable. If the answer is "No way!" then you need to think carefully
    about your options. As I see them, they are:

    1. Live with the risk!
    2. Shut the application down while its files are being backed up.
    3. Get a different application that both meets your needs as an
    application and also allows a consistent backup.


  16. Re: Please critique my backup practices

    Richard B. Gilbert wrote:

    > If you can't stop the application, you can't guarantee a consistent
    > backup! Some applications, such as databases, provide a means to get a
    > consistent backup.


    And some databases (read "Rdb") does it in a much easier and
    cleaer way then the rest. Using Rdb, online backup of "data"
    is an absolute no-brainer, just add /ONLINE to the RMU/BACKUP
    command. No nead to do anything with the application.

    Jan-Erik.


  17. Re: Please critique my backup practices


    "Michael Moroney" wrote in message
    news:fs918n$qf8$1@pcls4.std.com...
    > We have heard many time: "Thou shalt not use BACKUP/IGNORE=INTERLOCK".
    > But I have an application that runs continuously and doesn't close its
    > files, so the alternative is no backup of them. I had the idea of doing
    > two incremental backups, the first being a BACKUP/MOD/SINCE=BACKUP/RECORD
    > of the disk, and the second being BACKUP/MOD/SINCE=BACKUP/IGNORE=INTERLOCK
    > (note: no /RECORD) of the disk. The first is a "clean" incremental backup
    > of the disk, and the second, since it is run immediately after the first,
    > will contain only open files plus perhaps a few modified very recently.
    > It would only be used in emergencies. The lack of /RECORD is so the files
    > backed up on the second backup are not considered properly backed up, and
    > any file closed before the next pass of incremental backups will be
    > properly backed up during the next pass. Comments?
    >


    What do you know about the relationship between the continuously-running
    application's in-memory copy of the file (which the application will see),
    and the on-disk copy of the file (which BACKUP will see)? Without that kind
    of knowledge, comments on the efficacy of /IGNORE=INTERLOCK are likely
    nothing more than speculation (unless the comment is "it's pointless", which
    isn't news to you).

    And/or, asking a slightly different question, how do the commercial products
    which claim to do "open file backup" get around this problem (if indeed
    there are any such products on VMS?).



  18. Re: Please critique my backup practices

    On Mar 21, 11:41 am, David J Dachtera
    wrote:
    > Dale Dellutri wrote:
    >
    > > 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.

    >
    > The usual technique is to quiesce the application (cause it to close its
    > files), THEN split the shadow-sets. We do something similar with BCVs on
    > an EMC DMX array. This minimizes your "backup window".


    Why not...
    shut the app
    check that no files are open (except for INDEXF.SYS by the system)
    dismount the shadows set entirely
    remount with one less member
    backup the removed member
    put the removed member back in the save set

    In fact, this is what it says in the manual.

    (See http://h71000.www7.hp.com/doc/732FIN...-pvxmj-te.HTML
    Performing System Management Tasks on Shadowed Systems, Performing
    Backup Operations on a Shadow Set


    Record the time you dismounted the shadow set and use that time with /
    MODI/SINC=that_time for subsequent incremental backups, or use your
    method with DFU to update the backup dates of backed up files



    AEF
    >
    > Once upon many moons ago, I developed some code that would take a
    > BACKUP/LIST file and produce a file list for use with DFU's SET command
    > such that backup dates could be recorded after a shadow-set split
    > backup.
    >
    > I could probably resurrect that, if needed. It uses SEARCH to reduce the
    > data to the list of files and EDT in batch(!!) to perform the final
    > edits and cleanup. The result gets fed to the SET command in DFU:
    >
    > $ MCR DFU SET/BACKUP='date' "@filespec"
    >
    > Use SET PROC/PRIO=0 before invoking DFU to minimize impact on
    > production.
    >
    > David J Dachtera
    > (formerly dba) DJE Systems



  19. Re: Please critique my backup practices

    "John Wallace" writes:


    >"Michael Moroney" wrote in message
    >news:fs918n$qf8$1@pcls4.std.com...
    >> We have heard many time: "Thou shalt not use BACKUP/IGNORE=INTERLOCK".
    >> But I have an application that runs continuously and doesn't close its
    >> files, so the alternative is no backup of them. I had the idea of doing
    >> two incremental backups, the first being a BACKUP/MOD/SINCE=BACKUP/RECORD
    >> of the disk, and the second being BACKUP/MOD/SINCE=BACKUP/IGNORE=INTERLOCK
    >> (note: no /RECORD) of the disk. The first is a "clean" incremental backup
    >> of the disk, and the second, since it is run immediately after the first,
    >> will contain only open files plus perhaps a few modified very recently.
    >> It would only be used in emergencies. The lack of /RECORD is so the files
    >> backed up on the second backup are not considered properly backed up, and
    >> any file closed before the next pass of incremental backups will be
    >> properly backed up during the next pass. Comments?
    >>


    >What do you know about the relationship between the continuously-running
    >application's in-memory copy of the file (which the application will see),
    >and the on-disk copy of the file (which BACKUP will see)? Without that kind
    >of knowledge, comments on the efficacy of /IGNORE=INTERLOCK are likely
    >nothing more than speculation (unless the comment is "it's pointless", which
    >isn't news to you).


    The application maps data files via $CRMPSC/$MGBLSC and generally forces a
    writeback ($UPDSEC) when something important changes. The application is
    homegrown and plays *very* fast and loose with the data, but due to the
    nature of this beast, that's not as bad as it sounds.

  20. Re: Please critique my backup practices

    AEF wrote:
    >
    > On Mar 21, 11:41 am, David J Dachtera
    > wrote:
    > > Dale Dellutri wrote:
    > >
    > > > 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.

    > >
    > > The usual technique is to quiesce the application (cause it to close its
    > > files), THEN split the shadow-sets. We do something similar with BCVs on
    > > an EMC DMX array. This minimizes your "backup window".

    >
    > Why not...
    > shut the app
    > check that no files are open (except for INDEXF.SYS by the system)
    > dismount the shadows set entirely


    Doing so disables mini-copy. See HELP DISMOUNT /POLICY

    David J Dachtera
    (formerly dba) DJE Systems

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