ufsdump ufsrestore with ssh to/from remote system's disk/tape drive

Have 3 questions :

I've done :
ufsdump 0uf - /  | ssh remote_user@remote_svr "cd /oradata/bk; cat > svr1.dmp; gzip svr1.dmp*"
If I would like to recovery my svr1 in the event the root partition is corrupted/damaged, what's
the steps command to do it to ufsrestore from remote_svr:/oradata/bk/svr1.dmp.gzip?
 Kindly include "installboot" command.

The local server does not have a tape drive & I would like to ufsdump to remote_svr's tape
drive via ssh.  Is the command :
ufsdump -u0f - /var | /path/to/ssh username@remotesys "dd bs=1024 of=/dev/rmt/0cn"
Is "bs=1024" applicable to tape drive & can I use a higher value, say "bs=1048576" be
used here to increase the speed of the backup (as I've seen in disk to disk "dd", a high
value of bs  is essential to speed up backup)
 This "ufsdump+ssh" should be the equivalent of "ufsdump 0uf /dev/rmt/0cn /var" so
that in the event I could find an external SCSI tape drive, I would like to be able to just
do "ufsrestore -ivf /dev/rmt/0c . "

What's the equivalent command to restore from the backup taken in point (2) above
(using ufsrestore + ssh)
Who is Participating?
robocatConnect With a Mentor Commented:

For (2), there's an easier way to do this: use the syntax

ufsdump -u0f remotesys:/dev/rmt/0cn

You need to enable trust between the two machines, the name of the local system must be included in the /.rhosts file on the remote system.

The reverse can simply be done as a ufsrestore -f remotesys:/dev/rmt/0cn

For (1), you need to
a)boot from cdrom
b)perform a "newfs" on the root if needed
c)mount the root slice on /a and cd /a
d)ssh remote_user@remote_svr "cd /oradata/bk; cat  svr1.dmp.gz | gunzip -c" |  ufsrestore -r

TapeDudeConnect With a Mentor Commented:
For (2), you're quite right, writing to tape with a block size of 1024 will slow things down. However, in my experience, anything over 32k won't make an appreciable difference, and I'd be wary about using anything over 256k as not all drives/drivers will support blocks this big. In fact, a lot of systems start behaving wierdly with anything over 64k (maximum value for an unsigned word integer) so I'd stick to a blocksize of 32768 (32k) or, at max, 65536 (64k)
sunhuxAuthor Commented:
I still need "ufsdump" with "ssh" as  .rhosts (rsh/rlogin etc) is not allowed in
our environment.

So is the command below & its syntax correct :
ufsdump 0uf - /var | /path/to/ssh username@remotesys "dd bs=32768 of=/dev/rmt/0cn"
Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

omarfaridConnect With a Mentor Commented:
if you need to recover a crashed , you can not boot from cd and use ssh (unless ssh is part of the boot cd rom).

Possibly you need to boot from cd to interactive shell then format the disk (create partitions), create file systems, then use rsh which requires the remote system to allow it and trust your system then

rsh remote_server "cd /oradata/bk ; gunzip svr1.dmp* ; cat svr1.dmp" | ufsrestore  -xf -

ssh user@remoteserver "dd if=/dev/rmt/0cn ibs=1024" | (cd /var ; ufsrestore xf -)
robocatConnect With a Mentor Commented:

Note that you can save a lot of time if you pipe the archive through gzip instead of unzipping the archive on disk

ssh remote_user@remote_svr "cd /oradata/bk; cat  svr1.dmp.gz " |  gunzip -c | ufsrestore -f -

Same for creating the archive:

ufsdump 0uf - / | gzip -c  | ssh remote_user@remote_svr "cd /oradata/bk; cat >srv1.dmp.gz"
sunhuxAuthor Commented:
Thanks guys, that would be all.

I just found out the command for Linux doing dd to a Solaris' tape drive & for my own record :
dd if=/dev/sda2 bs=15M conv=sync,noerror | ssh remoteusr@remotesvr "dd of=/dev/rmt/0c"
TapeDudeConnect With a Mentor Commented:
A block size of 15 Mb is ridiculously large and if the data ever needs to be recovered (eg, if there's a bad block on the tape) will mean the guaranteed loss of at least 15Mb.

I'd strongly advise reducing the block size down to 64k.
nilehawkConnect With a Mentor Commented:
you can use the following

Take vdump from server_without_tap root "/"  on server_having_tap:
server_having_tap% ssh -l <user> server_without_tap ufsdump of server_having_tap:/dev/rmt/0mn /
Take vdump from server_without_tap root "/<partition>"  on server_having_tap:            
server_having_tap% ssh -l <user> server_without_tap ufsdump of server_having_tap:/dev/rmt/0mn /<partition>
Take vdump from server_having_tap root "/" on server_having_tap:
server_having_tap% ufsdump  of server_having_tap:/dev/rmt/0mn /
Good luck                  

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.