Hi,

I have a Tru64UNIX system that has 1 system disk with the root, swap,
usr, var and tmp filesystems on. usr, var and tmp are all in the same
Advfs domain.

I want to copy the system disk to a standby disk that I can boot off
in the event of the system disk drive failing.

What is the best way to do this?

Thanks
Andrew

[ Post a follow-up to this message ]

andrewr@cornasys.com wrote:
> Hi,
>
> I have a Tru64UNIX system that has 1 system disk with the root, swap,
> usr, var and tmp filesystems on. usr, var and tmp are all in the same
> Advfs domain.
>
> I want to copy the system disk to a standby disk that I can boot off
> in the event of the system disk drive failing.
>
> What is the best way to do this?
>
> Thanks
> Andrew
>

There are several different solutions for making a copy of your system
disk. Which one is best depends on your need and wether you want it to
be automatically updated or if you want to do it manually.

The easiest way in terms of maintenance work is to use LSM. It makes a
mirror copy of the system disk. Then you don't need to make manual
copies. It needs a license, of course. Either the LSM license or a NAS
server license. How the setup is done is well documented in the LSM
documentation.

Another solution is to make an identical copy of the system disk to the
other disk using vdump/vrestore. First you have to make the disk label
exactly similar on the new disk as it is on the system disk (remember to
use the "-t advfs" switch to make the disk bootable). Then you just make
a vdump -> vrestore copy of the system disk filesystems. You should do
it when your system is in single user mode. The syntax of the copying
command line is documented on the vrestore man page.
This solution needs continuous updates to keep the standby disk current.

Then there are some other possibilities, but they need a lot more care.
Therefore I suggest you use either of the described solutions.

I can provide more detailed descriptions, if you need.

Regards,

Kari

[ Post a follow-up to this message ]

On Thu, 02 Aug 2007 17:16:42 +0300, Uusimäki wrote:

> andrewr@cornasys.com wrote: 
>
> There are several different solutions for making a copy of your system
> disk. Which one is best depends on your need and wether you want it to
> be automatically updated or if you want to do it manually.
>
> The easiest way in terms of maintenance work is to use LSM. It makes a
> mirror copy of the system disk. Then you don't need to make manual
> copies. It needs a license, of course. Either the LSM license or a NAS
> server license. How the setup is done is well documented in the LSM
> documentation.
>
> Another solution is to make an identical copy of the system disk to the
> other disk using vdump/vrestore. First you have to make the disk label
> exactly similar on the new disk as it is on the system disk (remember to
> use the "-t advfs" switch to make the disk bootable). Then you just make
> a vdump -> vrestore copy of the system disk filesystems. You should do
> it when your system is in single user mode. The syntax of the copying
> command line is documented on the vrestore man page.
> This solution needs continuous updates to keep the standby disk current.
>
> Then there are some other possibilities, but they need a lot more care.
> Therefore I suggest you use either of the described solutions.
>
> I can provide more detailed descriptions, if you need.
>
> Regards,
>
> Kari

We've been using the vdump/vrestore method in multi-user
mode for many years with no issues. I have had to boot
from these copies and run the system for several days,
also without issue. We run this weekly. If you keep user data
under file domains separate from root, usr and var, the data
in these system directories should change very little from
week to week.
You can run vdump and vrestore in one command, using stdin
and stdout.
here's an example of how we copy the root filesystem to a
directory we created called /newroot:
vdump -0uf - -D / | vrestore -xf - -D /newroot

Hope this helps!

[ Post a follow-up to this message ]

Does the destination volume HAVE TO HAVE the same disk label, in your
experience?  I'm running into an issue moving from a sysdev on old
RAID to new RAID.  Going from root at 7gb and usr at 7gb and var at
3gb to new allocations of 20/20/20gb.  Old root and usr are on one
drive volume (a and h slices) and var is somewhere off on it's own.
On the new setup, dsk4c dsk5c and dsk13c get the three fsets, each in
their own domains.

It's simply not booting -- advfs corruption message booting ROOT in
single user mode, but it's not corrupt so it's lying.  Its a config
issue.  I've checked all I know to check.  I would not have believed
partition LETTERS would matter.

Thoughts?

[ Post a follow-up to this message ]

Doesnt Compute wrote:
> Does the destination volume HAVE TO HAVE the same disk label, in your
> experience?  I'm running into an issue moving from a sysdev on old
> RAID to new RAID.  Going from root at 7gb and usr at 7gb and var at
> 3gb to new allocations of 20/20/20gb.  Old root and usr are on one
> drive volume (a and h slices) and var is somewhere off on it's own.
> On the new setup, dsk4c dsk5c and dsk13c get the three fsets, each in
> their own domains.
>
> It's simply not booting -- advfs corruption message booting ROOT in
> single user mode, but it's not corrupt so it's lying.  Its a config
> issue.  I've checked all I know to check.  I would not have believed
> partition LETTERS would matter.
>
> Thoughts?
>
>

Unfortunately you have the use the normal type of disklabels and for
root (/) you have to use only the first, the a partition (e.g. dsk4a).
The other filesystems can be configured to reside anywhere else, but not
the root filesystem.
You can, of course, make the new root filesystem bigger - or even
smaller - but you have to stick to the right partition. That rule goes
for systems with LSM also.

Regards,

Kari

[ Post a follow-up to this message ]