Is this how you backup and restore a system?

Is this how you backup and restore a system?

Post by DET » Tue, 16 Jun 1998 04:00:00



I'm working on putting together a complete set of instructions for backing
up SCO, and for rebuilding a new HD if you smoke the old one. I've put
together the following set of instructions from my (insufficient)
experience, from docs, and from posting questions on newsgroups.

**WARNING**

I have *NOT* tried this yet. I want to pass it by the people in this
newsgroup and get any obvious errors fixed. Then I will try it and post
results. Eventually I want to have detailed and dependable enough
instructions to add to a FAQ.

**NOTICE**

Will those of you who keep emailing me to tell me to just use a commercial
product please CUT IT OUT!    I know all about the commercial products, and
I have purchased one. That is *not* the point of this exercise.

[rant mode off]

So, with that in mind, here's what I have. Please send comments and

(This is cut-and-paste from a WORD doc. I hope it comes out legibly)
-------

BACKUP AND RECOVERY
BACKING UP A SCO SYSTEM
AND
RECOVERING FROM A CRASH

BACKUP
1.      Install all hardware and drivers, setup all network cards, install all
printers, set up all users. Essentially, get the system completely ready
for production.

2.      Do a tape backup of the entire system. Use cpio, as tar doesn't save
important things like device inodes and empty directories. Use the
following:

echo "/" | cpio o Abd O /dev/rct0

Note that the cpio options should be customized for your particular
installation. The device name may not be the same, you may have to specify
volume size and block size, etc.
Also, you may want to unmount any filesystems that exist on another
physical HD before doing the tape (or be more specific than "/"). If you
ever need to recover the boot HD, you don't need to or want to restore this
data into the root partition.

3.      Make the emergency boot and root floppies, using mkdev fd. You may have
to do some work to ensure that the floppies are complete. First, if you've
added devices, the script may not be making the floppy filesystem with
enough inodes. To change this, edit the /usr/lib/mkdev/fd file, and do the
following:
look for this line:
/etc/mkfs -y -f EAFS /dev/marry/tmp/ramdisk 5120:1000 >/dev/null 2>&1
and change the 1000 to something higher (I use 1500).

If you want to make sure specific executables are on the floppy, look for
one of these lines:
        core_utils=
        OR
        extra_utils=
And add the executable name to the appropriate list.

4.      Test the floppies by booting from them. Also try to access the tape
drive using:
cpio i I /dev/rct0 -t
DO NOT try to make the hard disk devices at this time. As part of the
"mkdev hd" process, you will probably get your existing filesystems
overwritten. This would be a Bad Thing. Although you could use mknod to
make the device nodes and access the hd at this time, you probably
shouldn't. During the recovery process you are going to have to mkdev,
fdisk, and divvy the new hard disk anyway, and having existing nodes will
just confuse things.

5.      Make a backup set of emergency floppies finding out that one of your
emergency floppies is bad, right in the middle of an emergency, may cause
stress.
In addition, if you have another server or other system available, put an
image of the emergency floppies in a well-known location on the alternate
system. You can get a disk image of a floppy using this:
dd if=/dev/rfd0  of=/tmp/SomeFileName  bs=512
Your floppy device name may vary.

6.      Print the disk configuration. You can do this by executing "script" then
doing a "fdisk" and "divvy" for each HD, then closing the script and
printing the resulting typescript file.

7.      Do a "hwconfig h" to printer. If you have to replace the entire system,
this will help you to remember the setup.

8.      print the /etc/default/filesys file. This will indicate your various
filesystem mounts and mount points.

9.      Put the floppies, the cpio tape, and the printouts in a safe place. One
idea is to make up a loose-leaf binder, labelled with the name of the
system, containing all the media and printouts necessary to rebuild the
system.

10.     In some systems, there are other things that have to be documented or
backed up. For instance, EISA systems will likely need to have the cards in
a replacement system go into exactly the same slots. Also, you should have
a backup copy of the EISA config floppy.

And if you have to modify the CMOS settings, you should document this
(although the emergency root floppy contains a file with the settings
saved).

RECOVERING
This section assumes that you've had the system HD melt down, or have had
to replace the entire system. If the latter, the new system should be
configured identically to the old one.

1.      Boot from emergency floppies.

2.      Make the new disk, using:
mkdev hd
Part of this process will also involve fdisk'ing and divvy'ing the new hd.
You don't have to make the new HD the same as the old, but it would make
life easier to keep things the same.

3.      make mount directories:
mkdir /mnt
mkdir /mnt/stand

4.      mount the new hd:
mount /dev/hd0root /mnt
mount /dev/hd0boot /mnt/stand
Note that the name of the devices "hd0root" and "hd0boot" will be based on
what you name the filesystems when you divvy the new HD.

5.      If your entire system was on one filesystem, this is enough. However, if
you had things like a separate /u filesystem, you will have to manually
mount these.
For instance, with a separate /u filesystem, you'd need to do this:
mkdir /mnt/u
mount /dev/hd0u
Note that the name of the device or devices will be based on what you name
the filesystems when you divvy the new HD.

6.      Restore from the cpio tape:
umask 000
cd /mnt
cpio   -i I /dev/rct0

7.      shutdown:
haltsys

8.      boot from floppy, but at the "boot:" prompt, enter:
hd(40)unix

9.      Go into single-user mode. Execute:
dparam w
instbb hd /dev/hd0a

10.     relink the kernel:
/etc/conf/cf.d/link_unix

11.     reboot

There will probably be some cleanup at this point, but you should be
essentially up and running.
------------

OK, I'm sure there are gaping holes. Suggestions accepted gratefully.

 
 
 

Is this how you backup and restore a system?

Post by DET » Thu, 18 Jun 1998 04:00:00


Here's an update to the instructions based on comments by Marnus, Richard,
and Tom. Thanks, guys. Hope I didn't miss anything.

Once again, cut and paste from a Windows doc. If anyone wants me to post
the .DOC as an attachment, let me know.

--------

BACKUP AND RECOVERY
BACKING UP A SCO SYSTEM
AND
RECOVERING FROM A CRASH

BACKUP
1.      Install all hardware and drivers, setup all network cards, install all
printers, set up all users. Essentially, get the system completely ready
for production.

2.      Do a tape backup of the entire system. Use cpio, as tar doesn't save
important things like device inodes and empty directories. Use the
following:

find / -depth print | cpio ocvB O /dev/rct0

Note that the cpio options should be customized for your particular
installation. The device name may not be the same, you may have to specify
volume size and block size, etc.
Also, you may want to unmount any filesystems that exist on another
physical HD before doing the tape (or be more specific than "/"). If you
ever need to recover the boot HD, you don't need to or want to restore this
data into the root partition.

3.      Make the emergency boot and root floppies, using mkdev fd. You may have
to do some work to ensure that the floppies are complete. First, if you've
added devices, the script may not be making the floppy filesystem with
enough inodes. To change this, edit the /usr/lib/mkdev/fd file, and do the
following:
look for this line:
/etc/mkfs -y -f EAFS /dev/marry/tmp/ramdisk 5120:1000 >/dev/null 2>&1
and change the 1000 to something higher (I use 1500).

If you want to make sure specific executables are on the floppy, look for
one of these lines:
        core_utils=
        OR
        extra_utils=
And add the executable name to the appropriate list.

(can we add "uniq" to get rid of one of those error messages mentioned
below?)

4.      Test the floppies by booting from them. Also try to access the tape
drive using:
cpio itvcB I /dev/rct0
DO NOT try to make the hard disk devices at this time. As part of the
"mkdev hd" process, you will probably get your existing filesystems
overwritten. This would be a Bad Thing. Although you could use mknod to
make the device nodes and access the hd at this time, you probably
shouldn't. During the recovery process you are going to have to mkdev,
fdisk, and divvy the new hard disk anyway, and having existing nodes will
just confuse things.

5.      Make a backup set of emergency floppies finding out that one of your
emergency floppies is bad, right in the middle of an emergency, may cause
stress.
In addition, if you have another server or other system available, put an
image of the emergency floppies in a well-known location on the alternate
system. You can get a disk image of a floppy using this:
dd if=/dev/rfd0  of=/tmp/SomeFileName  bs=512
Your floppy device name may vary.

6.      Print the disk configuration. You can do this by executing "script" then
doing a "fdisk" and "divvy" for each HD, then closing the script and
printing the resulting typescript file.

7.      Do a "hwconfig h" to printer. If you have to replace the entire system,
this will help you to remember the setup.

8.      print the /etc/default/filesys file. This will indicate your various
filesystem mounts and mount points.

9.      Put the floppies, the cpio tape, and the printouts in a safe place. One
idea is to make up a loose-leaf binder, labelled with the name of the
system, containing all the media and printouts necessary to rebuild the
system.

10.     In some systems, there are other things that have to be documented or
backed up. For instance, EISA systems will likely need to have the cards in
a replacement system go into exactly the same slots. Also, you should have
a backup copy of the EISA config floppy.

And if you have to modify the CMOS settings, you should document this. The
emergency root floppy also contains a file with the settings saved, in
"/etc/cmos.root". See CMOS(ADM) to restore it.

RECOVERING
This section assumes that you've had the system HD melt down, or have had
to replace the entire system. If the latter, the new system should be
configured identically to the old one.

1.      Boot from emergency floppies.

2.      Make the new disk, using:
mkdev hd
Part of this process will also involve fdisk'ing and divvy'ing the new hd.
You don't have to make the new HD the same as the old, but it would make
life easier to keep things the same.
There will be some error messages, like:
/usr/lib/mkdev/hd: uniq: not found
mv: /tmp/DKINIT21 not acessable: no file or directory: (error 2)
These can be ignored (can they be avoided? like by putting uniq on the root
floppy?)

3.      make mount directories:
mkdir /mnt

4.      mount the new hd:
mount /dev/hd0root /mnt
mkdir /mnt/stand
mount /dev/hd0boot /mnt/stand
Note that the name of the devices "hd0root" and "hd0boot" will be based on
what you name the filesystems when you divvy the new HD.

5.      If your entire system was on one filesystem, this is enough. However, if
you had things like a separate /u filesystem, you will have to manually
mount these.
For instance, with a separate /u filesystem, you'd need to do this:
mkdir /mnt/u
mount /dev/hd0u /mnt/u
You only have to do this at this point if you want to (or need to) restore
the filesystems from the tape immediately. If you have separate backups for
filesystems like /u, and they are on different tapes, and they are not
essential to the basic recovery strategy, leave them for later.
Note that the name of the device or devices will be based on what you name
the filesystems when you divvy the new HD.

6.      Restore from the cpio tape:
cd /mnt
cpio  -ivmkBud I /dev/rct0

7.      shutdown:
/etc/haltsys

8.      boot from floppy, but at the "boot:" prompt, enter:
hd(40)unix

9.      Go into single-user mode. Execute:
dparam w
instbb hd /dev/hd0a
This step makes the HD bootable.

10.     relink the kernel:
/etc/conf/cf.d/link_unix
This step is not essential for the kernel itself, but it does rebuild the
kernel environment. It's best to do this to ensure that everything is
consistent. It's essential if your new disk layout is different.

11.     reboot

There will probably be some cleanup at this point, but you should be
essentially up and running.

 
 
 

Is this how you backup and restore a system?

Post by DET » Thu, 18 Jun 1998 04:00:00




Quote:> Here's an update to the instructions based on comments by Marnus,
Richard,
> and Tom. Thanks, guys. Hope I didn't miss anything.

> Once again, cut and paste from a Windows doc. If anyone wants me to post
> the .DOC as an attachment, let me know.

Oops. Forgot to fold in some comments by Steve Fabac. Here it is again.

-----

BACKUP AND RECOVERY
BACKING UP A SCO SYSTEM
AND
RECOVERING FROM A CRASH

BACKUP
1.      Install all hardware and drivers, setup all network cards, install all
printers, set up all users. Essentially, get the system completely ready
for production.

2.      Do a tape backup of the entire system. Use cpio, as tar doesn't save
important things like device inodes and empty directories. Use the
following:

find / -depth print | cpio ocvB O /dev/rct0

Note that the cpio options should be customized for your particular
installation. The device name may not be the same, you may have to specify
volume size and block size, etc. You may also want to specify a block size
and/or a volume size; so you might end up with something like:

find / -depth print | cpio ocvB C 10240  K 2000000  O /dev/rct0
Also, you may want to unmount any filesystems that exist on another
physical HD before doing the tape (or be more specific than "/"). If you
ever need to recover the boot HD, you don't need to or want to restore this
data into the root partition.

3.      Make the emergency boot and root floppies, using mkdev fd. You may have
to do some work to ensure that the floppies are complete. First, if you've
added devices, the script may not be making the floppy filesystem with
enough inodes. To change this, edit the /usr/lib/mkdev/fd file, and do the
following:
look for this line:
/etc/mkfs y f EAFS /dev/marry/tmp/ramdisk 5120:1000 >/dev/null 2>&1
and change the 1000 to something higher (I use 1500).

If you want to make sure specific executables are on the floppy, look for
one of these lines:
        core_utils=
        OR
        extra_utils=
And add the executable name to the appropriate list.

4.      Test the floppies by booting from them. Also try to access the tape
drive using:
cpio itvcB I /dev/rct0
DO NOT try to make the hard disk devices at this time. As part of the
"mkdev hd" process, you will probably get your existing filesystems
overwritten. This would be a Bad Thing. Although you could use mknod to
make the device nodes and access the hd at this time, you probably
shouldn't. During the recovery process you are going to have to mkdev,
fdisk, and divvy the new hard disk anyway, and having existing nodes will
just confuse things.

5.      Make a backup set of emergency floppies finding out that one of your
emergency floppies is bad, right in the middle of an emergency, may cause
stress.
In addition, if you have another server or other system available, put an
image of the emergency floppies in a well-known location on the alternate
system. You can get a disk image of a floppy using this:
dd if=/dev/rfd0  of=/tmp/SomeFileName  bs=512
Your floppy device name may vary.

6.      Print the disk configuration. You can do this by executing "script" then
doing a "fdisk" and "divvy" for each HD, then closing the script and
printing the resulting typescript file.

7.      Do a "hwconfig h" to printer. If you have to replace the entire system,
this will help you to remember the setup.

8.      print the /etc/default/filesys file. This will indicate your various
filesystem mounts and mount points.

9.      Put the floppies, the cpio tape, and the printouts in a safe place. One
idea is to make up a loose-leaf binder, labelled with the name of the
system, containing all the media and printouts necessary to rebuild the
system.

10.     In some systems, there are other things that have to be documented or
backed up. For instance, EISA systems will likely need to have the cards in
a replacement system go into exactly the same slots. Also, you should have
a backup copy of the EISA config floppy.

And if you have to modify the CMOS settings, you should document this. The
emergency root floppy also contains a file with the settings saved, in
"/etc/cmos.root". See CMOS(ADM) to restore it.

RECOVERING
This section assumes that you've had the system HD melt down, or have had
to replace the entire system. If the latter, the new system should be
configured identically to the old one.

1.      Boot from emergency floppies.

2.      Make the new disk, using:
mkdev hd

Part of this process will also involve fdisk'ing and divvy'ing the new hd.
You don't have to make the new HD the same as the old, but it would make
life easier to keep things the same.
There will be some error messages, like:
/usr/lib/mkdev/hd: uniq: not found
mv: /tmp/DKINIT21 not acessable: no file or directory: (error 2)
These can be ignored (can they be avoided? Like by putting uniq on the root
floppy?)
(Steve Fabac suggested using:
Mkdev hd 0 0
Which will apparently walk you through the whole process including fdisk
and divvy.)

3.      make mount directories:
mkdir /mnt

4.      mount the new hd:
mount /dev/hd0root /mnt
mkdir /mnt/stand
mount /dev/hd0boot /mnt/stand
Note that the name of the devices "hd0root" and "hd0boot" will be based on
what you name the filesystems when you divvy the new HD.

5.      If your entire system was on one filesystem, this is enough. However, if
you had things like a separate /u filesystem, you will have to manually
mount these.
For instance, with a separate /u filesystem, you'd need to do this:
mkdir /mnt/u
mount /dev/hd0u /mnt/u
You only have to do this at this point if you want to (or need to) restore
the filesystems from the tape immediately. If you have separate backups for
filesystems like /u, and they are on different tapes, and they are not
essential to the basic recovery strategy, leave them for later.
Note that the name of the device or devices will be based on what you name
the filesystems when you divvy the new HD.

6.      Restore from the cpio tape:
cd /mnt
cpio  -icvmkBud I /dev/rct0

7.      shutdown:
/etc/haltsys

8.      boot from floppy, but at the "boot:" prompt, enter:
hd(40)unix

9.      Go into single-user mode. Execute:
dparam w
instbb hd /dev/hd0a
This step makes the HD bootable.

10.     relink the kernel:
/etc/conf/cf.d/link_unix
This step is not essential for the kernel itself, but it does rebuild the
kernel environment. It's best to do this to ensure that everything is
consistent. It's essential if your new disk layout is different.

11.     reboot

There will probably be some cleanup at this point, but you should be
essentially up and running.

 
 
 

Is this how you backup and restore a system?

Post by Marnus van Nieker » Fri, 19 Jun 1998 04:00:00


Looks great!

For backup: instead of unmounting /u or whatever you could
do:
find  /   /stand   -depth -mount -print | cpio    (extra
spaces added for clarity!)

The -mount flag restricts cpio to the current filesystem but
then your dir list must be / and /stand

--

Marnus van Niekerk
    (B.Sc., SCO ACE)
MJVN Computer Consulting
If needed e-mail is mvn at mjvn co za

Quote:>Here's an update to the instructions based on comments by
Marnus, Richard,
>and Tom. Thanks, guys. Hope I didn't miss anything.

>Once again, cut and paste from a Windows doc. If anyone
wants me to post
>the .DOC as an attachment, let me know.

>--------

>BACKUP AND RECOVERY
>BACKING UP A SCO SYSTEM
>AND
>RECOVERING FROM A CRASH

>BACKUP
>1. Install all hardware and drivers, setup all network
cards, install all
>printers, set up all users. Essentially, get the system
completely ready
>for production.

>2. Do a tape backup of the entire system. Use cpio, as tar
doesn't save
>important things like device inodes and empty directories.
Use the
>following:

>find / -depth print | cpio ocvB O /dev/rct0

>Note that the cpio options should be customized for your
particular
>installation. The device name may not be the same, you may
have to specify
>volume size and block size, etc.
>Also, you may want to unmount any filesystems that exist on
another
>physical HD before doing the tape (or be more specific than
"/"). If you
>ever need to recover the boot HD, you don't need to or want
to restore this
>data into the root partition.

>3. Make the emergency boot and root floppies, using mkdev
fd. You may have
>to do some work to ensure that the floppies are complete.
First, if you've
>added devices, the script may not be making the floppy
filesystem with
>enough inodes. To change this, edit the /usr/lib/mkdev/fd
file, and do the
>following:
>look for this line:
>/etc/mkfs -y -f EAFS /dev/marry/tmp/ramdisk 5120:1000
>/dev/null 2>&1
>and change the 1000 to something higher (I use 1500).

>If you want to make sure specific executables are on the
floppy, look for
>one of these lines:
> core_utils=
> OR
> extra_utils=
>And add the executable name to the appropriate list.

>(can we add "uniq" to get rid of one of those error
messages mentioned
>below?)

>4. Test the floppies by booting from them. Also try to
access the tape
>drive using:
>cpio itvcB I /dev/rct0
>DO NOT try to make the hard disk devices at this time. As
part of the
>"mkdev hd" process, you will probably get your existing
filesystems
>overwritten. This would be a Bad Thing. Although you could
use mknod to
>make the device nodes and access the hd at this time, you
probably
>shouldn't. During the recovery process you are going to
have to mkdev,
>fdisk, and divvy the new hard disk anyway, and having
existing nodes will
>just confuse things.

>5. Make a backup set of emergency floppies finding out
that one of your
>emergency floppies is bad, right in the middle of an

emergency, may cause
Quote:>stress.
>In addition, if you have another server or other system
available, put an
>image of the emergency floppies in a well-known location on
the alternate
>system. You can get a disk image of a floppy using this:
>dd if=/dev/rfd0  of=/tmp/SomeFileName  bs=512
>Your floppy device name may vary.

>6. Print the disk configuration. You can do this by

executing "script" then

- Show quoted text -

Quote:>doing a "fdisk" and "divvy" for each HD, then closing the
script and
>printing the resulting typescript file.

>7. Do a "hwconfig h" to printer. If you have to replace
the entire system,
>this will help you to remember the setup.

>8. print the /etc/default/filesys file. This will indicate
your various
>filesystem mounts and mount points.

>9. Put the floppies, the cpio tape, and the printouts in a
safe place. One
>idea is to make up a loose-leaf binder, labelled with the
name of the
>system, containing all the media and printouts necessary to
rebuild the
>system.

>10. In some systems, there are other things that have to be
documented or
>backed up. For instance, EISA systems will likely need to
have the cards in
>a replacement system go into exactly the same slots. Also,
you should have
>a backup copy of the EISA config floppy.

>And if you have to modify the CMOS settings, you should
document this. The
>emergency root floppy also contains a file with the
settings saved, in
>"/etc/cmos.root". See CMOS(ADM) to restore it.

>RECOVERING
>This section assumes that you've had the system HD melt
down, or have had
>to replace the entire system. If the latter, the new system
should be
>configured identically to the old one.

>1. Boot from emergency floppies.

>2. Make the new disk, using:
>mkdev hd
>Part of this process will also involve fdisk'ing and

divvy'ing the new hd.

- Show quoted text -

Quote:>You don't have to make the new HD the same as the old, but
it would make
>life easier to keep things the same.
>There will be some error messages, like:
>/usr/lib/mkdev/hd: uniq: not found
>mv: /tmp/DKINIT21 not acessable: no file or directory:
(error 2)
>These can be ignored (can they be avoided? like by putting
uniq on the root
>floppy?)

>3. make mount directories:
>mkdir /mnt

>4. mount the new hd:
>mount /dev/hd0root /mnt
>mkdir /mnt/stand
>mount /dev/hd0boot /mnt/stand
>Note that the name of the devices "hd0root" and "hd0boot"
will be based on
>what you name the filesystems when you divvy the new HD.

>5. If your entire system was on one filesystem, this is
enough. However, if
>you had things like a separate /u filesystem, you will have
to manually
>mount these.
>For instance, with a separate /u filesystem, you'd need to
do this:
>mkdir /mnt/u
>mount /dev/hd0u /mnt/u
>You only have to do this at this point if you want to (or
need to) restore
>the filesystems from the tape immediately. If you have

separate backups for

- Show quoted text -

Quote:>filesystems like /u, and they are on different tapes, and
they are not
>essential to the basic recovery strategy, leave them for
later.
>Note that the name of the device or devices will be based
on what you name
>the filesystems when you divvy the new HD.

>6. Restore from the cpio tape:
>cd /mnt
>cpio  -ivmkBud I /dev/rct0

>7. shutdown:
>/etc/haltsys

>8. boot from floppy, but at the "boot:" prompt, enter:
>hd(40)unix

>9. Go into single-user mode. Execute:
>dparam w
>instbb hd /dev/hd0a
>This step makes the HD bootable.

>10. relink the kernel:
>/etc/conf/cf.d/link_unix
>This step is not essential for the kernel itself, but it
does rebuild the
>kernel environment. It's best to do this to ensure that
everything is
>consistent. It's essential if your new disk layout is
different.

>11. reboot

>There will probably be some cleanup at this point, but you
should be
>essentially up and running.

 
 
 

1. help. restoring a backup dump/restore

Hi
I'm having problems with restoring a backup that has been made with dump

It's a redhat 6.1 machine
I want to restore the files on a redhat 7.1 machiene

cd /space
restore rf /dev/ht0

#(very long list)#
#and then half way#

Mount tape volume 2
Enter ``none'' if there are no more tapes
otherwise enter tape name (default: /dev/ht0) none
Warning: End-of-input encountered while
./data/data/fromcvs/development_2/com/data/support/producerconsumer/java/tes
t/CVS/Root/file
entry type: LEAF
inode number: 4214662
flags: NEW
abort? [yn] y
dump core? [yn] n

The backup went well on the machine where the backup was made if i need to
believe dump.
You whould realy help me with an tip/solution on this one :)
Maybe the syntax `restore rf /dev/ht0` is not the right way ?

-Bas Keur

2. Why am I paging?

3. Restore data from DDS (((AKA further proof of backup/restore issues on linux

4. Is Sol 2.4 x86 promotion over?

5. System crash when restoring a backup

6. Keyboard not working in R5 V2

7. Best way to backup/restore Tru64 system?

8. HTTP traffic via VPN

9. Backup and Restore an entire system

10. Restoring system from tape backup (how ?)

11. Restoring 3.1.5 backups on 3.2 system

12. How to restore system from backup

13. This is how you backup and restore a system (LATEST VERSION)