Solaris

First of all, great web site! I have been using it for a while but just registered today. It's been a great resource for me. Now, on to my issue.


I'm geographically separated from six (Sun v245s) development servers that I have been asked to backup and restore as development is done and redone to verify procedures. I have a guy there locally that will manage the backups and is able to put hands on the boxes. Before I was charged with this my boss purchased six 1TB USB drives to store the backups for each server. Space is not an issue these servers have four 146G drives set up in RADI 1+0.


I provided instructions to my guy there locally to boot off a live CD and use dd to copy the data over to the usb drives. Here is the syntax of the commands we are using:

Code:

dd if=/dev/dsk/c0t0... | gzip > /usbdrive/image_name.gz
gzip -dc /usbdrive/image_name.gz | dd of=/dev/dsk/c0t0...

This process works fine, the only complaint I got was the time it takes to accomplish this. Honestly, I don't care but I wanted to help him out. He was asking about using usfdump/ufsrestore, but I've always been a dd person.
Does anyone see a better way of doing this? We need the multiple backups so that we can put the server in the different stages of development for testing. Thanks.

maybe you can use LiveUpgrade to do this work!

cpio and gunzip or tar for cheap backup, for furthere use migrate UFS to ZFS using lucreatre, luactivate commands and in the future you can easily backup your data on remote server using ssh and zfs send, zfs receive.
Problem with ufsdump is that only Solaris knows how to read it because UFS isn't platform independent. As one more solution you can create UDF image with lofi device and then move one UDF image.

This shouldn't be a problem for the OP backups which will be restored on the same platforms.
I guess you mean OS dependent here.

hm, USB is not so reliable. I have had problems with it in past. but then again it was with USB1 flash ram. a single bit errors were common. USB2 with external power is another thing, but I'd still check it with md5sum to be sure (for eg. by putting it after dd and before gzip).

ufsdump would obviously produce smaller file.
are you using dd to dump the whole thing, including swap slice?
if so, you could reduce the backup by zeroing the swap first, just don't forget to skip the partition table like this:
dd if=/dev/zero of=/dev/dsk/c0t1d0s1 bs=256k oseek=1

you would also get further space saving by wiping free space, cat is faster with that:
cat /dev/zero >delete_me

to be extra safe, I'd do that cleaning after having first backup. or do it on dd image files later with qemu or something.

oh, and it might be a good idea to defragment the image, too.

all that would be unnecessary with ufsdump, but dd has its advantages.

Yes. I expressed myself wrong

Thanks all.
I'm not crazy about using the USB drives, but that's what the boss bought and it's what I've got to work with. These v245 do not have SCSI cards so I can't use our tape library. I never trust tape backups anyway.

I'm going to go against my gut and use ufsdump/restore. I've always liked dd but my guy that has hands on the boxes wants to try that. Mainly because it won't take so long.
Any suggestions before I start writing up procedures for him? I've always booted off a live CD when using dd. Should I do the same using ufsdump? Single user mode?