From owner-freebsd-stable@FreeBSD.ORG Sun Jun 10 15:26:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D52AD106564A for ; Sun, 10 Jun 2012 15:26:26 +0000 (UTC) (envelope-from karl@denninger.net) Received: from FS.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id 881958FC1B for ; Sun, 10 Jun 2012 15:26:26 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by FS.denninger.net (8.14.4/8.13.1) with ESMTP id q5AFQP8s053383 for ; Sun, 10 Jun 2012 10:26:26 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [127.0.0.1] [192.168.1.40] by Spamblock-sys (LOCAL); Sun Jun 10 10:26:26 2012 Message-ID: <4FD4BCA1.2010502@denninger.net> Date: Sun, 10 Jun 2012 10:26:25 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Adam Strohl References: <4FD3AD35.3090301@denninger.net> <4FD4B9AC.6090604@ateamsystems.com> In-Reply-To: <4FD4B9AC.6090604@ateamsystems.com> X-Enigmail-Version: 1.4.2 X-Antivirus: avast! (VPS 120610-0, 06/10/2012), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: Backups with 9-STABLE -- Options? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 15:26:26 -0000 On 6/10/2012 10:13 AM, Adam Strohl wrote: > On 6/10/2012 3:08, Karl Denninger wrote: >> With SU+J as the default filesystem, what options actually WORK now? >> >> 1. Dump "L" will NOT -- it doesn't hang any more but now just bitches >> and refuses to run. I suppose that beats a hang.... > > Heh, yeah that is improved from what it did before ;D > >> 2. Dump without "L" and take your chances? What risks am I running by >> doing this on a running system? > > Depends on what is running and how it does file writes. For example > SQL DB storage engines are unlikely to do well (ie; the restore will > be corrupted if there are changes during the process). Something like > CouchDB though which is "always consistent on disk" probably wouldn't > care. Well, backup with snapshots don't do well EITHER on a database unless you can snapshot BOTH the dbms data store(s) and the transaction log store(s) /*at the exact same instant*/. If you cannot then you're asking for trouble and are likely to get it. But I've dealt with that particular "gotcha" problem in a different way for the DBMS I use (Postgresql) > > Past specific applications (or user activity) the inherent risk is > unpredictable usefulness of your backups. Since you're doing backups > as a safeguard (and are very likely your last hope if things really go > wrong) you don't want to find out that a key piece corrupted or > missing entirely due to files moving around during the dump when you > end up needing it. Yeah, that's the problem. >> 3. Other? >> >> Dump has been the canonical means of backing up... forever. And it >> still is claimed to be the canonical means in the documentation. >> >> So what options do we have now that actually work -- is there now a new >> "canonical" backup method that is recommended? > > My solution is to turn off journals for any build. Dump is a great > tool (especially when scripted) and is very efficient. > > And as neat as journals are, backups using dump with snapshots is way > more valuable and important in my book. > > My .02. So basically what you're saying is that SU+J leaves you exposed to having no real backup option that provides a rational guarantee of the ability to restore the backup taken. Yet this was made the default.... why? -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC