The problem, as stated, was:
--start of problem--
We run a standalone server running Solaris 2.5.1 on Intel. We recently
attached an HP JetStore 6000 C1533 tape backup system.
The /dev/rmt/ director lists the appropriate devices. No problems there. I
want to do a full system backup, initially and then dayly updates. (This is
a remote system, no physical access).
I started using
tar -fu /dev/rmt/0c /
But this resulted in tar trying to back /dev/rmt/0 and swap size overflow -
no good. (The tapes are supposed to take 8 Gig, and we only have 4Gig of
So I tried
tar -fu /dev/rmt/0c /var /export/home /opt /usr
I still run out of space, but something funny seems to be happening.
If I do a tar -ft /dev/rmt/0c, all the files in /usr are listed, but then
it starts again at //usr.
--end of problem-- (well...)
Thanks to all who have responded:
Mike Schmidt <firstname.lastname@example.org>
email@example.com (Niall O Broin - Gray Wizard)
"Birger A. Wathne" <birger@Vest.Sdata.No>
Tim Evans <firstname.lastname@example.org>
Tim Thompson <TThompson@mail.ci.lubbock.tx.us>
Fedor Gnuchev <email@example.com>
cde@Fax.COM (Christian D. Evans)
and especially Rich Kulawiec <firstname.lastname@example.org>
The general consensus is that using tar for tape backups is a bad idea.
usfdump/usfrestore should be used instead, for the following reasons:
1. tar has a 100-character pathname limit,
2. tar does not cope with special files/devices,
3. tar has no code to deal with active filesystems.
4. it does not give you a backup that you can easily restore
5. tar can't cope with the entries in /dev.
I was worried that the manual pages state that ufsdump should only be run
on an inactive filesystem, but apparently, this is only a recommendation
and the failure chace is indeed very low.
Acconding to Birger A. Wathne, the commands for a full backup go something
ufsdump 0f /dev/rmt/0cn /
ufsdump 0f /dev/rmt/0cn /usr
ufsdump 0f /dev/rmt/0cn /var
ufsdump 0f /dev/rmt/0cn /opt
ufsdump 0f /dev/rmt/0cn /export/home
but some people prefer to back-up physical devices (/dev/dsk/...).
Rich Kulawiec will post a summary of this and other tape backup issues
later on this evening (EST).
Thanks again, it's been a very 'knowlegdge-enhancing' day.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:48 CDT