Summary: Running out of space when backing up the OS to a DDS2 ta pe

Thanks for all the feedback. Everyone seemed to be in agreement
that I was running out of space on the DDS2 tape. As to why the
backup worked on a previous build with the same physical disks in a RAID
1 mirror, no one could explain precisely what was happening. We all
waved our hands and blamed in on the data not compressing as well, which
is probably the case. (The computer scientist in me still wishes I could
put may hands on the actual compression algorithm.)

A few people suggested that you could get better compression from
another program like gzip. Yura Pismerov [ypismerov@tucows.com] wrote:

>> As an option you can try using non-compressing device (0l) and pipe
>> the data through gzip before writing to the tape.
>>
>> dd if=/dev/rdsk/c1t0d0s2 | gzip -c | dd of=/dev/rmt/0l bs=32k
>>
>> to restore
>>
>> dd if=/dev/rmt/ol bs=32k | gzip -cd | dd of=/dev/rdsk/...
>>
>>
>> The only issue is you need to keep gzip utility handy every time you
>> restore.

More than one person wondered why we use dd instead of ufsdump and
ufsrestore. In my original message, I failed to mention that the
reason for doing the backup in the first place is so that we can
easily replicate the build to several identical servers. I more or
less inherited the dd procedure. Since I haven't actually used ufsdump,
I'm hesitant to be too critical; however, the dd command does seem
to be simpler than the slightly more involved process of setting up
the filesystem prior to restoring with ufsrestore. Furthermore, some of
the people responsible for restoring the build from tape can barely
type the dd command correctly, so simple is good. That said, ufsdump
does have the obvious advantage of not backing up useless data like
swap, not to mention the portability advantages if you are not
restoring to identical hardware.

A few people suggested making swap the last slice. Then you could
still use dd to backup each filesystem individually, being
careful not to rewind the tape between backups. And then during the
restore you would put the filesystems back on disk in the same order
that they were backed up.

In the end, I decided to pursue what I felt was (in our case at least)
the simplest solution of all.

Looking at our filesystem layout, I concluded that we've got room
to spare. I don't even have to modify the RAID layout. Instead, during
the Solaris installation, I opt to "Customize the fdisk Partitions". I
somewhat arbitrarily selected 1024 cylinders (it's a pretty number)
which works out to about 8024 MB for slice 2. I stole the space from
/export/home and from swap. Since we're building backend database and
terminal servers, there isn't going to be anything to speak of in
/export/home. And 1615 MB still seems like more than enough swap space
on servers that have 2 GB of main memory.

In the end, this is what our filesystem layout looks like:

0	/			133
1	swap			1615
2	overlap		8024
3
4	/opt			1004
5	/var			4000
6	/usr			1004
7	/export/home	258

Before when I used dd to back up to a DDS2 tape, the output was:

264555+0 records in/out

Backing up to a DLT tape produced:

276870+1 records in/out

Now, backing up to a DDS2 tape produces:

256788+1 records in/out

Of course, now someone is going to ask, "Why all the fuss if you have
DLT drives?" The answer is that on our terminal servers, we only have
DAT 8 drives.

Problem solved! Cheers,
John Spurgeon 
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers