As usual a great response thanks to all. There were a few methods and ideas
for doing this procedure
all listed below.
****************************************************************************
**********
ORIGINAL QUESTION
We are sending a machine out to a customer and i was wondering what would
be
the best procedure to backup the machine. It is an alpha station 200
running
DU4.0d. and oracle 7.3.4..
As oracle is time stamped what is the best procedure.
would a vdump be sufficient or do i have to export the databases then do a
vdump.
would a tar be easier to restore
or is there someway of doing a direct copy with links i.e. cp -pR <dir>.
****************************************************************************
**********
What i did in the end was to export the databases first while oracle was
running.
once exports were completed shut down oracle and did a vdump of all disks.
Some points to note :
1)
Backing up an Oracle database is a fairly involved topic, and you MUST
get it right, or your database will not be recoverable. "Oracle Backup &
Recovery Handbook",
by Rama Velpuri, Oracle Press.
2)
The simplest way to backup an Oracle database is the
"cold backup", where you first shut down the database, and then backup
all the database files. We use ADVFS so we
use vdump/vrestore for backup/restore. There's no reason why tar,
cpio, or even cp couldn't work. What you need is perfect copies of
all the relevent files.
A cold backup allows you to recover the whole database to a point
in time. If you want to recover every transaction from the cold
backup to the point of failure, you'll also need to run the
database in archive log mode, and have a scheme to preserve the
archived redo logs, so you can use them to roll forward.
To be able to restore individual tables, you'd also need to have
exported the whole database or the appropriate portion.
It's more complicated, but you can also do "hot backup", where the
database stays up and available while the backup run
3)
Bring the system to single-user mode (using shutdown(8) without a -h or
-r option.
Once in single-user mode, re-mount all the disks:
# bcheckrc
Restart the update process:
update
Run vdump -0 (level 0 vdump) against each partition on the system.
This will give you a tape that you can restore when you get the system back
from the customer. The restore process would involve booting the Digital
UNIX installation CD, selecting the UNIX Shell option, re-creating the file
systems, mounting them, and restoring the tape with vrestore(8). It will
bring your system back to the exact state it was in prior to going off to
the customer.
4)
As long as the database is not "restarted" after you do the vdump then the
vdump works just fine. If you are using AdvFS I would HIGHLY encourage that
you do a verify, in single user mode, before you do the vdump. I have seen
an unreported corrupt inode at the directory level completely hose a vdump,
that of course completed without error! As for doing an export... well it
is another way of restoring the database but only as a last ditch effort,
you have a tendency to "lose" some things on a import, not the data but
things like user rights, and the occasional referential integrity violations
caused by data not all being there at the same instant.
I also use the cp -R and move my live database to a temporary location if
I'm going to do a power down. I have lost disks on a re-start once or twice
and it's nice to be able to just re-place disks and do a cp -R back as
opposed to a RAID level rebuild ( that is if your using RAID ). And last
but not least, I only use tar to "zip" up directories and move them around
disk-to-disk, restoring tar from tape is a pain, works but still a pain.
Thanks to ,
wmills_at_WellsFargo.COM
Phil Rand
John J. Francini
Alan Rollow
Alan Angulo
Zack Ellis
Jason_NEIL_at_paribas.com
Catalin H. Ciontu
Cy Dewhurst
Darrell King
Systems Manager
+353 1 6142430
darrellk_at_apion-ti.com
087-2850314
Received on Tue Apr 20 1999 - 10:22:00 NZST