lvm and dd

[Robert Weilmuenster]

I am running hpux11.0 and have 2 internal disks. 1st disk has the o/s and the 2nd disk will be used as a hot bootable. I call this my (Life Boat). Disk 1 is vg00 and Disk2 is vg01. I am trying to dd the file systems to vg01 or cpio -pmvd. The issue I have is only with the / filesystem. The cpio copies all directories, example /var, /opt, /stand, etc. My filesystems are /stand (hfs), /, /home, /opt, /tmp, /usr, /var (vxfs). I have used this approach on (SUN Solaris) systems. The reason is of dd or cpio thru a cron once a day/week, It allows for a fallback, when a change is made that corrupts the o/s. You can come up asap. After the dd or cpio, I changed the new root location /etc/vfstab to the new c0t0d0sx to c1t0d0sx and ran build.bootblk. The question is how can I get around the root directory copying all the files with HPUX or is there a better approach.

[Rick Garland]

The methodology supposes that you will not be able to boot off the other disk should you have a failure of the root disk. If you would like that, I would suggest MIRROR/UX or to become aquainted with make_recovery, part of the IGNITE package which is a freebie.

If you are not concerned with being able to boot off the other disk, dd or cpio will work fine.

[Antoanetta Naghiu]

The best way is if you use mirroring but you have to pay for it.
What do you say about:
1. making separated mount points and logical volumes for your application
2. build from scrach in the second disk (try to boot from it, if work, add it as Alternative boot path), keep on it a separated fstab, and over night cpio just the application files...
Ignite (free software with HP11, as it was already said it is another option... Or ... Service Guard but this one is even more expensive than Mirror....

[Alan Riggs]

As others have said, Mirrordisk/UX is the best solution. If you cannot purchase that product, then I would suggest establishing the second disk as a bootable emergency root disk. There are several ways to do this, one is:

pvcreate -fB /dev/rdsk/c*t*d*
mkboot /dev/dsk/c*t*d*
vgcreate vg01 /dev/dsk/c*t*d*
create the lvols and filesystems on vg01 to replicate vg00
sed 's/vg00/vg01/g' /etc/fstab > /etc/fstab.root
vi /etc/fstab to add entries for vg01. Have these filesystems mount under /newroot. Make sure the / equivalent mounts first.
setboot -a
lvlnboot -b /dev/vg01/lvol
lvlnboot -r /dev/vg01/lvol3
lvlnboot -s /dev/vg01/lvol2
lvlnboot -d /dev/vg01/lvol2
lvlnboot -v to verify settings.


Then script your periodic data transfers:

mount -a (to mount your vg01 directories)
for FS in / /var /usr /opt /home /stand /tmp
do
cd $FS
find . -depth -xdev | cpio -pdumx /newroot$FS
done
cp /newroot/etc/fstab.root /newroot/etc/fstab

[Christian Aichmair]

Hi !
Seen apart from Mirror/UX, which whould be the best solution for Disk-HW defects, your approach is ok.
In your case, I would prefer "find ...| cpio" over dd.
The reason is that it allows different disk sizes and is might be even faster if the disk is not filled completly, besides it aut
omatically "defragments" the new FS.
To not copy some directories with find | cpio, use "find . ! -path './Omitt_this_dir/*' -depth | cpio -pdmux
To make sure your disk is really bootable you should check a few things (Assuming your real root/boot VG vg00 is disk c0t6d0 and your standby VG should be VG01 which corresponds to disk c0t5d0)
1.) check that your new disk can be booted (PV must have been prepared with "pvcreate -B") and that it contains a boot-loader(see mkboot, check with "lifls -l /dev/rdsk/c0t6d0")
2.) Create LVs on VG01 same size and Options as on VG00, take care, lvol1+2+3 (/stand, prim. swap/dump and /-FS) MUST be contigous and have bad-block relocate off
3.) create FS in VG01/lvol* like on VG00, lvol1 =^= /stand =^= HFS, Rest vxfs)
4.) mkdir /disk
5.) mount /dev/vg01/lvol3 /disk
6.) create Mount-Points under /disk for each FS (i.e. mkdir /disk/stand /disk/tmp /disk/var /disk/usr /disk/opt /disk/home)
7.) mount -F hfs /vg01/lvol1 /disk/stand
8.) mount all other FSs ( e.g.. mount /dev/vg01/lvolX /disk/YY, ...)
9.) cd / ; find . ! -path './disk/*' -depth | cpio -pdmux /disk
10.) change all entries in /disk/etc/fstab from vg00 to vg01
11.) setboot -a HW-Path_of_your_alternate_disk # check with ioscan
12.) lvlnboot -r /dev/vg01/lvol3 ( or whatever LV / really is)
13.) lvlnboot -s /dev/vg01/lvol2 # or real swap-lvol
14.) lvlnboot -b /dev/vg01/lvol1
15.) lvlnboot -d /dev/vg01/lvol_like_swap

check if bootable wih lvlnboot -v vg01, test booting from this disk !!

Hope it helps,
Christian

[Shannon Petry]

Everyone already gave great advice on how to mirror, with things other than dd, so I wont go there.
The reason that dd works for Sun/Solaris is you dump slice 2, which is the whole disk. This also works for HP-UX dd, but you can not do so by logical volume. I.E.
dd if=/dev/dsk/c0t1d0s2 of=/dev/dsk/c0t3d0s2,
and your disk is copied. You can do slices separate too, but usually whole disks are mirrored. I have successfully dumped a whole 9Gb SCSI in HPUX by
dd if=/dev/rdsk/c0t1d0 of=/dev/rdsk/c0t2d0.
this will take care of the boot area, and all lv's, but can not be made active while the other disk is too. The LV's will have the be identical even in name.
The downside is, the only way to test this is to down your system, and boot from the second disk.

[Alan Riggs]

One final caveat for using dd. Under LVM, dd will *not* correctly copy the boot area of a disk. You will not be able to make an emergency boot disk with a dd copy.

[Stefan Farrelly]

Ive just successfully completed the following;

To create an image backup of a system disk (without using the approved methods; ignite or mirror/ux);

dd if=/dev/rdsk/c0t9d0 of=/dev/rdsk/c0t8d0 bs=2k

c9t0d0 is my system disk and c0t0d8 is a completely unused disk, same model and size (essential). Then I rebooted the server, removed the Jamaica disk on SCSI 9 and replaced the backup copy with it (so the boot disk is still on SCSI 9 and thus all the device info is correct) and rebooted successfully off it.

The only problem is that it took 10.5 hours to dd (on a 9GB disk) - because of using such a small block size but you must use 2k to make the copy bootable.

It would probably be quicker to have the second disk partially mounted and use find+cpio as mentioned earlier to make and keep the backup copy in sync rather than using dd, but using dd at least it is an exact copy - apart from what may have changed during the 10.5 hours it took to dd, but as long as no apps running then only a few logfiles etc. should have been modified.

[Dragan Krnic]

The disk will be bootable no matter what the "bs=". Hence make it as big as possible. 1024k is a good measure. A 9 GB disk should copy in about 10 minutes. Such a disk is a mirror image of the original system disk, which means it is not clean and needs to be fsck'd or else you need to wait for fsck to finish when you first boot off it (only a problem if it is formated as hfs).

However, when you want to switch to this disk you either have to change its SCSI address to that of the original disk, which can be messy, or boot first in maintenance mode ("hpux -lm" at the "ISL>"-prompt) and destroy and relink the volumes with "lvrmboot" and "lvlnboot" commands respectively and reboot. If you don't either, you'll get panic "No swap device".

[Vincente Fernandes]

If you can't use mirror or ignite option dd is the best choice. As mentioned by steven dd can be used with "bs=2k" even though it takes some time. A cron job can be created to run on a certain day or the weekend(probably during night) when there is no/very less activity on the system.

[Stefan Farrelly]

Dragan is correct, you dont need to use a miserly block size of 2k, thats for making tapes bootable! Using a blocksize of 1024k it took 25 minutes to make the backup copy (9Gb disk). The 2 disks were on the same bus though, if on separate bus'es that time should be halved or more.

Not only is this the simplest way to make an image backup but also the fastest.

[Alan Riggs]

The use of lifcp or dd to write the boot area of a disk will corrupt the PVRA and BDRA structures.

As mentioned above, you can swap the physical drive locations to boot cleanly off of the "copy". IF you have hot swappable drives this might not be an issue for you. Personally, I dislike solutions that require physical access to devices for implementation. An emergency root disk created with LVM can be booted from simply by specifying the path with setboot. I find this to be a more robust (and remotely available) solution. I also find it is easier to talk a remote operator through repointing a boot path (in the event of a hard crash recovery need) than to talk them through a disk swap.

YMMV, of course.