Problem with dump over SSH: Operation timed out

[Alex Zbyslaw]

Nikos Vassiliadis wrote:

>Keep in mind that dump(8) uses UFS2 snapshots. I don't know
>the current status, but in the past, snapshots were not working
>that good.
>
This statement is far too general and IMHO does a disservice to those 
who worked on snapshots.

There were (and maybe even are, but I haven't seen a problem report in 
ages) issues with large numbers of snapshots or with large (active?) 
filesystems, but in that case *dump would never have started* as the 
snapshot wouldn't have completed.

I'm still running 5.4 which is pretty "in the past" and have no issue 
with dump -L sending the files over the ethernet either compressing 
locally or remotely.  (Well, I do, but only with one ethernet driver and 
it's either a driver or a hardware fault and nothing to do with dump or 
snapshots).

Other 5.4 systems I run use snapshots on a daily basis for other 
purposes and again have no problems.

Bram Schoenmakers wrote:

># /sbin/dump -0uan -L -h 0 -f - / | /usr/bin/bzip2 | /usr/bin/ssh 
>backup at office.example.com \
>        dd of=/backup/webserver/root.0.bz2
>
>
bzip2 is darned slow and not always much better than gzip -9.  It might 
be that ssh is just timing out in some way (I've seen that but not with 
ethernet dumps specifically).  Can you try the test using gzip -9 
instead of bzip?  If that works, then look for ssh options that affect 
timeouts, keepalives etc.  In particular, ServerAliveInterval 60 in a 
.ssh/config stopped xterm windows dying on me to certain hosts.  YMMV :-(

If you have the disk space then you could try without any compression at 
all; or try doing the compression remotely:

           /sbin/dump -0 -a -C 64 -L -h 0 -f - / | \
                /usr/local/bin/ssh backup at office.example.com 
\               
                "gzip -9 > /backup/webserver/root.0.gz"

Otherwise:

Nikos Vassiliadis wrote:

>1) Can you dump the file locally?
>
>2) Is scp working?

If you can write (and compress if short of disk space) the dump locally and try an scp to your remote host as Nikos is suggesting, that will narrow down the problem a bit.  Any other large file will do: doesn't have to be a dump.

--Alex