Re: who is procedure of backup for vms
From: Alan Adams (alan.adams@orchard-way.freeserve.co.uk)
Date: 04/05/03
- Next message: Bill Todd: "Re: COV Sponsors"
- Previous message: Alan Adams: "Re: COV Sponsors"
- In reply to: Paul Sture: "Re: who is procedure of backup for vms"
- Next in thread: Carl Perkins: "Re: who is procedure of backup for vms"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Alan Adams <alan.adams@orchard-way.freeserve.co.uk> Date: Sat, 05 Apr 2003 22:56:33 +0100
In message <VcUA112m6bJZ@elias.decus.ch>
p_sture@elias.decus.ch (Paul Sture) wrote:
> In article <oQ21FuMtfxIx@eisner.encompasserve.org>, briggs@encompasserve.org writes:
> > In article <zSBia.162$gg2.1@news.cpqcorp.net>, hammond@not@peek.ssr.hp.com (Charlie Hammond) writes:
> >> In article <b6ee8n$179$1@aquila.mdx.ac.uk>,
> >> david20@alpha1.mdx.ac.uk (David Webb) writes:
> >>
> >>>Although the "official" position has always been that to backup a system disk
> >>>you need to shutdown the system and do a stand-alone-backup using
> >>>backup/ignore=interlock pretty well always works.
> >>
> >> The "truth" of this statement is *VERY* dependent on the current activity
> >> on the system and on the system disk in particular. In a non-trivial
> >> systemenvironment, it can be *VERY* hard to contol or limit activity.
> >>
> >> Remember: The /IGNORE=INTERLOCK qualifier tells BACKUP that you do not
> >> care if the resulting saveset or image can be correctly restored.
> >
> > And /VERIFY tells BACKUP to tell you how bad the damage is likely to be.
> >
> > Personally, I'm in the "go ahead and use /IGNORE=INTERLOCK" crowd. I've
> > had to recover from lost system disks (or data disks where the queue
> > files and authorization files were redirected) a few times over the
> > years. We lost the queue database every time.
>
> I must admit that in the main, I too am in the "go ahead and use
> /IGNORE=INTERLOCK" crowd.
>
> OTOH, when I was working on a system which drove a production line where
> downtime during working hours would cost tens of thousands of UKP per
> hour, we took the cautious approach. Fortunately we had the luxury of a 12
> hour slot on Friday evenings where we could take full image backups and
> defrag all the disks at the same time.
>
>
> > But we never lost
> > or corrupted SYSUAF or RIGHTSLIST. And I always figured I have
> > umpteen copies of those files on nightly incrementals and previous
> > weekly and monthly backups. Statistically, one of them is pretty much
> > guaranteed to be good.
> >
>
> Another point there is that looking at a backup listing I have here, there
> are 128 files in between RIGHTSLIST.DAT and SYSUAF.DAT. It is perfectly
> possible then that the backups of these files can be out of sync.
>
> > Still, I understand the other point of view. And there's something to
> > be said for the practice of backing up to tape, restoring to an idle
> > disk, swapping the unit plugs and rebooting. Now _that's_ a guarantee
> > that your backup scheme really works.
> >
>
> Agreed. Now for a strategy I haven't seen mentioned in this thread.
>
> Why not take an image backup with /IGNORE=INTERLOCK/RECORD, quiesce the
> applications, then do a BACKUP/SINCE=BACKUP/RECORD ?
>
> This greatly reduces the application down time window, and if you have
> spare disks and processing power, you can easily create a "clean" copy of
> your system disk to take to tape at your leisure.
>
> Another point to note here: BACKUP/IMAGE/RECORD from disk to disk applies
> the backup date to all files on the target disk as it goes along.
>
And SAVESET-MANAGER will do that job for you. (Merging an image and
incrementals together into a new image.)
While on the subject of backups around system upgrades, on slower systems I
used to reckon on:
2 copies to tape before upgrade, then restore one of them. Result contiguous
disk, and upgrade runs faster.
(Never deliberately overwrite a disk unless you have two tape copies.
Bad tape? Even better, restore to a different disk.)
2 copies to tape afterwards, and restore one of them. Result contiguous
system disk and system runs faster.
Keep all the tapes until after the next upgrade at least.
When short of time, I replaced one of the tape copies with a disk-to-disk,
and used the new disk instead of the original.
This used BACKUP/IMAGE DISK1: DISK2:,
not
BACKUP/IMAGE DISK1: DISK2:SAVESET.BCK/SAVE
which doesn't produce a bootable disk.
-- Alan Adams alan.adams@orchard-way.freeserve.co.uk http://www.nckc.org.uk/
- Next message: Bill Todd: "Re: COV Sponsors"
- Previous message: Alan Adams: "Re: COV Sponsors"
- In reply to: Paul Sture: "Re: who is procedure of backup for vms"
- Next in thread: Carl Perkins: "Re: who is procedure of backup for vms"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
