Re: duplicating system disks
From: Hoff Hoffman (hoff_at_hp.nospam)
Date: 07/30/03
- Next message: John Travell: "Re: [Change topic -> OT] Pence/Pennies"
- Previous message: Hoff Hoffman: "Re: Model Update Plan"
- In reply to: Mike Naime: "Re: duplicating system disks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 30 Jul 2003 19:38:09 GMT
In article <4skVa.43291$7O4.934305@twister.rdc-kc.rr.com>, "Mike Naime" <mnaime@kc.rr.com> writes:
:
:Z <zarlenga@conan.ids.net> wrote in message
:news:vi92h09vvvkdfe@corp.supernews.com...
:> Mike Naime <mnaime@kc.rr.com> wrote:
:> : (BACKUP/IMAGE/IGNORE=INTER SYS$SYSDEVICE: {target disk}) This way, I
:> ...
:> : Compaq/HP support is fine with this method since we have all of the
:required
:>
:> They're fine with backing up the system disk while the system is
:> running with /ignore=interlock?
:>
:> I don't think so.
:
:Yep. We had a discussion with our Platinum suport TAMS and the Engineering
:group recently about Backup/ignore=interlock. The DR folks where wanting to
:know some specifics about file time stamps when using the backup command.
:Upon recieving theanswer from engineering that you are probably talking
:about. I asked specifically about using it to CLONE an OS disk. This is
:not a prefered method for making a system backup, but it is fine for making
:a CLONE of the OS where you are going to be changing all of the node
:specific data prior to bringing up a new system pack...
I don't think so. I expect you were told it *probably* works, as
OpenVMS Engineering is likely *not* going to tell you it *will* work.
Everything that I and the engineer that is maintaining BACKUP here in
OpenVMS have been discussing in this area back this up, too -- the
result will *probably* work, it does *not* always work.
:When you are dealing with a 24x7 data center, this is your best option for a
:no-downtime backup.
Like the oft-used "realtime" terminology, "24x7" means different
things to different folks.
Here, you will want to get a standalone BACKUP/IMAGE, then track
the upgrades you have made -- using /IGNORE=INTERLOCK will probably
get you to a recoverable environment, but you have to know what you
are doing to rebuild it should you encounter a case where an
interlock you ignored causes your consistency problems. And it is
your own data that is obviously most critical here, and this is an
area OpenVMS Engineering can give you relatively little guidance on
use of /IGNORE=INTERLOCK around -- if your applications always write
to disk and there is minimal caching, /IGNORE=INTERLOCK will likely
work fine. If your applications are aggressive with caching, then
/IGNORE=INTERLOCK can capture stale or inconsistent disk data.
If you are running "24x7", you need to look at shadowing and at RMS
journaling products and at database-level archival options -- the
former can reduce the window for getting a quick copy of a system
disk -- and the latter two options can help recover from file-level
errors that can arise. Then there are discussions of power and
access and hot sites and spares and recovery media, etc.
As for recovery (and assuming you have power, servers, and access,
etc) I'd be looking at how to recover the core critical (application)
data first, then outward to installing the layered products and
operating system and ECOs. And as I have often stated, I'd not
first look to use /IGNORE=INTERLOCK here.
True "24x7" operations are a whole lot tougher to build than it
might initially look.
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com
- Next message: John Travell: "Re: [Change topic -> OT] Pence/Pennies"
- Previous message: Hoff Hoffman: "Re: Model Update Plan"
- In reply to: Mike Naime: "Re: duplicating system disks"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
