restore over ssh hangs (solved)

[David Landgren]

David Landgren wrote:
> List,
> 
> I've implemented backups with dump/restore over ssh to a remote server. 
> The backups work just fine, basically doing something like
> 
> dump -0au -f - / | bzip2 | ssh remote.host \
>     dd of=/backup/root.bz2
> 
> Now backups are only useful if you can restore from them... so I deleted 
> a file and then tried to restore it. I figured the command would be
> 
> ssh remote.host dd if=/backup/root.bz2 | bunzip2 \
>     | restore -vxf - etc/foo
> 
> This produces the following output:

[...]

> And my file hasn't been restored :(
> 
> I could always ferry the entire dump file over, decompress it and then 
> restore from it, but the files in question are pretty colossal, and at 
> some point down the road I won't have enough free space to do it anyway.

Answering my own question, should people ever encounter the same problem.

Sending the dump over to the remote system works fine, what doesn't 
work is bringing it back and trying to restore from it. The other 
night I  had a 3:00am brainwave, and realised that I should try and 
restore locally on the machine that received the dump file.

Logging into that remote server, I ran

	bzcat root.bz2 | restore -vxf - etc/foo

and Bingo! after some 4 minutes of CPU time it asked me "set 
owner/mode for '.'? [yn]" question. I answered yes, and received my 
file, although the ownerships were a bit messed up because of uid/gid 
mismatches between the two systems, but that's easy enough to fix.

Now that I know the approach works this way I think I actually prefer 
it, because at least this way I know there's absolutely no way the 
restored file can clobber the file to be restored, since I'm doing it 
on a different system. (I have done this before; it's quite painful to 
explain to the luser).

It's interesting to note in passing that today's current high-end 
servers - Pentium Xeon 3GHz, 15krpm SCSI disks, 1000Base-T - offer 
such performance that you can do backups this way and still have 
plenty of headroom left on your CPU, disks and network to do your 
usual work.

So, hope this helps someone.

David