From owner-freebsd-fs@FreeBSD.ORG Fri Mar 27 01:52:48 2009 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1886E106564A; Fri, 27 Mar 2009 01:52:48 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id EED798FC0C; Fri, 27 Mar 2009 01:52:46 +0000 (UTC) (envelope-from mi+thun@aldan.algebra.com) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.3/8.14.3) with ESMTP id n2R1qYiG039571; Thu, 26 Mar 2009 21:52:37 -0400 (EDT) (envelope-from mi+thun@aldan.algebra.com) Message-ID: <49CC3162.5090201@aldan.algebra.com> Date: Thu, 26 Mar 2009 21:52:34 -0400 From: "Mikhail T." User-Agent: Thunderbird 2.0.0.18 (X11/20081126) MIME-Version: 1.0 To: Greg Black References: <49C83673.3000604@aldan.algebra.com> <200903251232.11418.doconnor@gsoft.com.au> <49C99204.2050601@aldan.algebra.com> <200903251334.38350.doconnor@gsoft.com.au> <49C99FD2.50609@aldan.algebra.com> <49CA5602.9050001@aldan.algebra.com> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 8bit Cc: Daniel O'Connor , freebsd-stable@freebsd.org, fs@freebsd.org Subject: backup strategy (Re: dump | restore fails) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2009 01:52:48 -0000 Greg Black ΞΑΠΙΣΑΧ(ΜΑ): > Sorry, this person is *not* making backups in any meaningful fashion. > Unless you verify regularly (preferably every time you make a backup) > that you can restore both parts of the backup and the entire thing, you > are not making backups. To qualify for your (and your kind's) recognition then, a person needs to have at least as much extra storage capacity as the largest filesystem they are backing up. They also need non-trivial scripting abilities, because the OS doesn't include anything like what you are describing (and I already do consider scheduling dumps via cron "trivial", which may be a stretch). Yours may thus be an acceptable requirement for a multi-computer shop with dedicated system administration personnel, but for a private home user with only one computer this simply is not reasonable. Stating this as a requirement is ridiculous -- unless you are prepared to say, that such people should not own a computer (with worthy data) at all. And that's even more ridiculous... Make your pick. I would agree with you, if the chosen backup method involved some complex or third-party tools. But if the simple, OS-supplied orthogonal dump/restore don't work together, then the OS is broken -- plain and simple, and pointing a finger at the user: "Well, it is all your fault, because you relied on us providing you with working utilities, ha-ha-ha!" -- is the lamest excuse imaginable. -mi P.S. Some people have actually volunteered to help debug this problem and I'm working on providing them with data (the troublesome partition is, sadly, over 170Gb, so it takes a while). Any results/conclusions will be posted under the original subject. P.P.S. The data transferred fine using tar, but that is not the point -- the bug (confirmed by at least one more person) -- needs to be fixed before a higher-profile embarrassment...