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.

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=<date-time-of-last-image>.  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!

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

<rgilbert88@comcast.net> 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 incremental=
s,
>> 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 th=
e  =

> proper order!  A slightly better choice would be to use differential  =

> backups.  Do your image once weekly and each succeeding day, do a BACK=
UP  =

> /SINCE=3D<date-time-of-last-image>.  That way there are only two backu=
ps  =

> 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=3DBACKUP.  This is better because you let the machine do y=
our  =

> 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-Lists/FreeBSD/questions/2005-08/1598.h=
tml


-- =

PL/I for OpenVMS
www.kednos.com

On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar <tadamsmar@yahoo.com> 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 <ddelQQQlutr@panQQQix.com> (lose the Q's)

On Mar 20, 2:36=A0pm, Dale Dellutri <ddelQQQl...@panQQQix.com> wrote:
> On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar <tadams...@yahoo.com> =
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. =A0As 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. =A0In other words, it does not properly
> close open files.
>
> I assume that you take image backups. =A0If 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. =A0But 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. =A0You should
> check this backup scheme with the service techs (I assume you have
> a support contract).
>
> --
> Dale Dellutri <ddelQQQl...@panQQQix.com> (lose the Q's)

"tadamsmar" <tadamsmar@yahoo.com> 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

On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar <tadamsmar@yahoo.com> wrote:
> On Mar 20, 2:36?pm, Dale Dellutri <ddelQQQl...@panQQQix.com> wrote:
> > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar <tadams...@yahoo.com> 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 <ddelQQQlutr@panQQQix.com> (lose the Q's)

On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar <tadamsmar@yahoo.com> wrote:
> On Mar 20, 2:36?pm, Dale Dellutri <ddelQQQl...@panQQQix.com> wrote:
> > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar <tadams...@yahoo.com> 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 <ddelQQQlutr@panQQQix.com> (lose the Q's)

On Mar 20, 4:06=A0pm, "John Wallace" <johnwalla...@yahoo.spam.co.uk>
wrote:
> "tadamsmar" <tadams...@yahoo.com> 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. =A0But 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 it=
s
> 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 releva=
nt
> 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 t=
wo
> (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 f=
it
> 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, BASEst=
ar
> (which you have previously mentioned) sometimes has lots of global section=

> files, which should disappear (or at least close cleanly) when you shut do=
wn
> 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 applicatio=
n
> 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.

In article <13u5gub59gtbmca@corp.supernews.com>, johnwallace4
@yahoo.spam.co.uk says...
> 
> "tadamsmar" <tadamsmar@yahoo.com> 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

On Mar 20, 9:02 am, tadamsmar <tadams...@yahoo.com> 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

On Mar 20, 9:28 am, "Richard B. Gilbert" <rgilber...@comcast.net>
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=<date-time-of-last-image>.  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

On Mar 20, 5:24 pm, John Santos <john.san...@post.harvard.edu> wrote:
> In article <13u5gub59gtb...@corp.supernews.com>, johnwallace4
> @yahoo.spam.co.uk says...
>
>
>
>
>
> > "tadamsmar" <tadams...@yahoo.com> 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

In article
<26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com>,
tadamsmar <tadamsmar@yahoo.com> 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?

"John Santos" <john.santos@post.harvard.edu> wrote in message
news:MPG.224cae69cfdc8d4b989793@news.bellatlantic.net...
> In article <13u5gub59gtbmca@corp.supernews.com>, johnwallace4
> @yahoo.spam.co.uk says...
> >
> > "tadamsmar" <tadamsmar@yahoo.com> 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

In article <fruqg2$27a$2@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply) writes:
> In article
> <26eb56f6-ec7b-42be-bf46-64def0b22f3e@m44g2000hsc.googlegroups.com>,
> tadamsmar <tadamsmar@yahoo.com> 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.

On Mar 20, 6:24=A0pm, John Santos <john.san...@post.harvard.edu> wrote:
> In article <13u5gub59gtb...@corp.supernews.com>, johnwallace4
> @yahoo.spam.co.uk says...
>
>
>
>
>
>
>
> > "tadamsmar" <tadams...@yahoo.com> 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. =A0But 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 syste=
m
> > disk, a generic data disk with various files on it, a "pure database" di=
sk
> > 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 file=
s
> > 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 rele=
vant
> > 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 da=
y'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 ha=
ve
> > 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 back=
up
> > is if you want a clean image backup of your system disk - always assumin=
g
> > that any applications you may have active can be persuaded to close any
> > files they may have opened, without shutting VMS down. For example, BASE=
star
> > (which you have previously mentioned) sometimes has lots of global secti=
on
> > files, which should disappear (or at least close cleanly) when you shut =
down
> > BASEstar. Then again, some BASEstar installations I have known have need=
ed
> > BASEstar running 24x7x365. Keeping the system up and running was more
> > important than the small risk of global sections being inconsistent on t=
he
> > 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 applicat=
ion
> > 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. =A0If 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. =A0Don't be editing systartup_vms.com while starting up the
> backup! =A0If 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. =A0Your time tag for the backup date is any time during
> the interval while everything is quiet. =A0You'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. =A0Since 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.) =A0Even 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. =A0You
> 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. =A0(Data dry rot!)
>
> --
> John- Hide quoted text -
>
> - Show quoted text -

On Mar 21, 9:37=A0am, "John Wallace" <johnwalla...@yahoo.spam.co.uk>
wrote:
> "John Santos" <john.san...@post.harvard.edu> wrote in message
>
> news:MPG.224cae69cfdc8d4b989793@news.bellatlantic.net...> In article <13u5=
gub59gtb...@corp.supernews.com>, johnwallace4
> > @yahoo.spam.co.uk says...
>
> > > "tadamsmar" <tadams...@yahoo.com> 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. =A0But 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 incremental=
s,
> > > > 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 hav=
e
> 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 wa=
s
> 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 previo=
us
> 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 "versi=
on
> > > management" tool in place to achieve the same end result, which might
> have
> > > changed the backup requirement. One backup strategy does not necessari=
ly
> 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 an=
y
> > > 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 shu=
t
> 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 al=
l
> 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. =A0If 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. =A0Don't be editing systartup_vms.com while starting up the
> > backup! =A0If 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. =A0Your time tag for the backup date is any time during
> > the interval while everything is quiet. =A0You'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. =A0Since 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.) =A0Even 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. =A0You
> > 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. =A0(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.

On Mar 21, 10:26=A0am, Kilgal...@SpamCop.net (Larry Kilgallen) wrote:
> In article <fruqg2$27...@online.de>, hel...@astro.multiCLOTHESvax.de (Phil=
lip Helbig---remove CLOTHES to reply) writes:
>
> > In article
> > <26eb56f6-ec7b-42be-bf46-64def0b22...@m44g2000hsc.googlegroups.com>,
> > tadamsmar <tadams...@yahoo.com> 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?

On Mar 21, 9:49 am, tadamsmar <tadams...@yahoo.com> 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

Dale Dellutri wrote:
> 
> On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar <tadamsmar@yahoo.com> wrote:
> > On Mar 20, 2:36?pm, Dale Dellutri <ddelQQQl...@panQQQix.com> wrote:
> > > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar <tadams...@yahoo.com> 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

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?

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.

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.

"Michael Moroney" <moroney@world.std.spaamtrap.com> 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?).

On Mar 21, 11:41 am, David J Dachtera <djesys...@spam.comcast.net>
wrote:
> Dale Dellutri wrote:
>
> > On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar <tadams...@yahoo.com> wrote:
> > > On Mar 20, 2:36?pm, Dale Dellutri <ddelQQQl...@panQQQix.com> wrote:
> > > > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar <tadams...@yahoo.com> 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/732FINAL/aa-pvxmj-te/aa-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

"John Wallace" <johnwallace4@yahoo.spam.co.uk> writes:


>"Michael Moroney" <moroney@world.std.spaamtrap.com> 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.

AEF wrote:
> 
> On Mar 21, 11:41 am, David J Dachtera <djesys...@spam.comcast.net>
> wrote:
> > Dale Dellutri wrote:
> >
> > > On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar <tadams...@yahoo.com> wrote:
> > > > On Mar 20, 2:36?pm, Dale Dellutri <ddelQQQl...@panQQQix.com> wrote:
> > > > > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar <tadams...@yahoo.com> 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

"Michael Moroney" <moroney@world.std.spaamtrap.com> wrote in message
news:fs9n15$vfi$1@pcls4.std.com...
> "John Wallace" <johnwallace4@yahoo.spam.co.uk> writes:
>
>
> >"Michael Moroney" <moroney@world.std.spaamtrap.com> 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.

 If the backup happens to contain valid data from these section files,
you're presumably better off than if it didn't? But how do you *know* it
will contain valid restorable data?

In addition to the usual open file concerns, I'd also want to know about the
relationship between the files - as the apps are still active, backups of
files may be individually valid but may relate to different points in time,
which, depending on the app, may or may not actually be a valid consistent
restorable dataset?

Even if you test the backup/restore and it appears to work when you test it,
as far as I can see you've no guarantee that the standard backup will not,
one day, contain inconsistent data e.g. because of unfortunate timing.
Murphy says that sooner or later, you will actually need to restore the data
but it won't be there in a usable form. What would the impact be if (when)
that happened?

If this data really is important to you, and you really really really cannot
quiesce the app somehow, maybe you might want to think about doing something
application-specific (but probably outside the main application) to save a
copy of the important live data; maybe something which "knows" about the
application's behaviour and knows when a good time to take a self-consistent
snapshot might be???? I'm sure there are folks around who could provide
better advice than I'm offering.  They might want $$$, which would
presumably be worthwhile if the data in these files is valuable to you.

Regards
John

On Mar 25, 6:53 pm, David J Dachtera <djesys...@spam.comcast.net>
wrote:
> AEF wrote:
>
> > On Mar 21, 11:41 am, David J Dachtera <djesys...@spam.comcast.net>
> > wrote:
> > > Dale Dellutri wrote:
>
> > > > On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar <tadams...@yahoo.com> wrote:
> > > > > On Mar 20, 2:36?pm, Dale Dellutri <ddelQQQl...@panQQQix.com> wrote:
> > > > > > On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar <tadams...@yahoo.com> 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

Then why does the fine manual say to do it that way?

I guess it's a case of safety vs. speed.

AEF

AEF wrote:
> On Mar 25, 6:53 pm, David J Dachtera <djesys...@spam.comcast.net>
> wrote:
> 
>>AEF wrote:
>>
>>
>>>On Mar 21, 11:41 am, David J Dachtera <djesys...@spam.comcast.net>
>>>wrote:
>>>
>>>>Dale Dellutri wrote:
>>
>>>>>On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar <tadams...@yahoo.com> wrote:
>>>>>
>>>>>>On Mar 20, 2:36?pm, Dale Dellutri <ddelQQQl...@panQQQix.com> wrote:
>>>>>>
>>>>>>>On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar <tadams...@yahoo.com> 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
> 
> 
> Then why does the fine manual say to do it that way?
> 
> I guess it's a case of safety vs. speed.
> 
> AEF

What version of the manual?  Maybe it predates minicopy, or maybe
it wasn't updated when minicopy was added, or maybe it is referring
to the safe way to do a backup when you can't follow the 237 caveats
that have been posted in this thread about the dangers of doing an
online backup of an active application.

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539

On Mar 26, 7:35 pm, John Santos <j...@egh.com> wrote:
> AEF wrote:
> > On Mar 25, 6:53 pm, David J Dachtera <djesys...@spam.comcast.net>
> > wrote:
>
> >>AEF wrote:
>
> >>>On Mar 21, 11:41 am, David J Dachtera <djesys...@spam.comcast.net>
> >>>wrote:
>
> >>>>Dale Dellutri wrote:
>
> >>>>>On Thu, 20 Mar 2008 12:36:19 -0700 (PDT), tadamsmar <tadams...@yahoo.com> wrote:
>
> >>>>>>On Mar 20, 2:36?pm, Dale Dellutri <ddelQQQl...@panQQQix.com> wrote:
>
> >>>>>>>On Thu, 20 Mar 2008 07:02:14 -0700 (PDT), tadamsmar <tadams...@yahoo.com> 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
>
> > Then why does the fine manual say to do it that way?
>
> > I guess it's a case of safety vs. speed.
>
> > AEF
>
> What version of the manual?  Maybe it predates minicopy, or maybe
> it wasn't updated when minicopy was added, or maybe it is referring
> to the safe way to do a backup when you can't follow the 237 caveats
> that have been posted in this thread about the dangers of doing an
> online backup of an active application.
>
> --
> John Santos
> Evans Griffiths & Hart, Inc.
> 781-861-0670 ext 539

The most current version on www.hp.com: The one under the V8.3 tab,
but the manual itself is OpenVMS Alpha 7.3-2. I assume that's the most
current. Has anything been added since? If so, why is it not
documented at www.hp.com ?

AEF

"John Wallace" <johnwallace4@yahoo.spam.co.uk> writes:


>"Michael Moroney" <moroney@world.std.spaamtrap.com> wrote in message
>news:fs9n15$vfi$1@pcls4.std.com...
>>
>> 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.

> If the backup happens to contain valid data from these section files,
>you're presumably better off than if it didn't? But how do you *know* it
>will contain valid restorable data?

These guys have been running wild for years, and have had problems with
bad data, but they brush it off.  I figure a bad backup might be better
than no backup.

>In addition to the usual open file concerns, I'd also want to know about the
>relationship between the files - as the apps are still active, backups of
>files may be individually valid but may relate to different points in time,
>which, depending on the app, may or may not actually be a valid consistent
>restorable dataset?

>Even if you test the backup/restore and it appears to work when you test it,
>as far as I can see you've no guarantee that the standard backup will not,
>one day, contain inconsistent data e.g. because of unfortunate timing.
>Murphy says that sooner or later, you will actually need to restore the data
>but it won't be there in a usable form. What would the impact be if (when)
>that happened?

It has happened.  The system is mostly for tracking and they reenter 
things manually when there are problems.

>If this data really is important to you, and you really really really cannot
>quiesce the app somehow, maybe you might want to think about doing something
>application-specific (but probably outside the main application) to save a
>copy of the important live data; maybe something which "knows" about the
>application's behaviour and knows when a good time to take a self-consistent
>snapshot might be???? I'm sure there are folks around who could provide
>better advice than I'm offering.  They might want $$$, which would
>presumably be worthwhile if the data in these files is valuable to you.

We're the ones trying to make some sanity out of the customer's system.
If we get the contract we will do a rewrite, including MUCH better data
protection, including such things as quiescing the app for proper backups,
and so much more.  You don't want to know.