Not really, as ufsdump is specifically designed for filesystem backups as the name suggests. It is easy, however, to put a number of ufsdumps in the same script and run them consecutively. HTH.
No problem. The follwing is an extract of one of our scripts:
ufsdump 0fuc /dev/rmt/0cbn /
echo \/ backed up at `date` >> /tmp/dumpit.out
ufsdump 0fuc /dev/rmt/0cbn /usr
echo \/usr backed up at `date` >> /tmp/dumpit.out
Basically, the first command backs up the root (/) filesystem to device /dev/rmt/0cbn (note that the n specifies the 'no-rewind' version of the device, so that it's positioned at the end of the save when completed). A line is then inserted in /tmp/dumpit.out to record the save (it might be better to replace /tmp with another directory as this gets emptied when a rebbot takes place).
the next ufsdump command then saves /usr to the same tape, following on from the first, and again writes a report to /tmp/dumpit.out. Add more of these type of commands to backup your other filesystems as necessary.
Your final save could be written to /dev/rmt/0cb so that the tape DOES rewind to the beginning at the end.
Hope this helps - post again if anything's not clear.
None of our Solaris servers require booting using the CD to perform a ufsdump. All I have found it necessary is to ensure is that all database processes etc (eg Oracle) need to be shutdown to ensure consistency. No problems have ever manifested themselves when restoring to our test server using this method. Whether this would work with Tru64 (never having used it), I'm afraid I can't say.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.