From owner-freebsd-questions@FreeBSD.ORG Thu Aug 9 14:39:47 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3971E16A418 for ; Thu, 9 Aug 2007 14:39:47 +0000 (UTC) (envelope-from xfb52@dial.pipex.com) Received: from blaster.systems.pipex.net (blaster.systems.pipex.net [62.241.163.7]) by mx1.freebsd.org (Postfix) with ESMTP id D12A413C428 for ; Thu, 9 Aug 2007 14:39:46 +0000 (UTC) (envelope-from xfb52@dial.pipex.com) Received: from [192.168.23.2] (62-31-10-181.cable.ubr05.edin.blueyonder.co.uk [62.31.10.181]) by blaster.systems.pipex.net (Postfix) with ESMTP id 01687E000A1B; Thu, 9 Aug 2007 15:39:44 +0100 (BST) Message-ID: <46BB2730.8090702@dial.pipex.com> Date: Thu, 09 Aug 2007 15:39:44 +0100 From: Alex Zbyslaw User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-GB; rv:1.7.13) Gecko/20061205 X-Accept-Language: en MIME-Version: 1.0 To: Nikos Vassiliadis , Bram Schoenmakers References: <200708091025.43912.bramschoenmakers@xs4all.nl> <200708091213.47740.nvass@teledomenet.gr> <200708091543.11003.bramschoenmakers@xs4all.nl> <200708091704.31952.nvass@teledomenet.gr> In-Reply-To: <200708091704.31952.nvass@teledomenet.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Problem with dump over SSH: Operation timed out X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2007 14:39:47 -0000 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@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@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