From owner-freebsd-stable@FreeBSD.ORG Sun Jun 10 15:13:59 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 910C71065672 for ; Sun, 10 Jun 2012 15:13:59 +0000 (UTC) (envelope-from adams-freebsd@ateamsystems.com) Received: from fss.sandiego.ateamservers.com (fss.sandiego.ateamservers.com [69.55.229.149]) by mx1.freebsd.org (Postfix) with ESMTP id 7664D8FC0A for ; Sun, 10 Jun 2012 15:13:59 +0000 (UTC) Received: from [192.168.15.220] (unknown [118.175.84.92]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by fss.sandiego.ateamservers.com (Postfix) with ESMTPSA id E52AEB9F22; Sun, 10 Jun 2012 11:13:57 -0400 (EDT) Message-ID: <4FD4B9AC.6090604@ateamsystems.com> Date: Sun, 10 Jun 2012 22:13:48 +0700 From: Adam Strohl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Karl Denninger References: <4FD3AD35.3090301@denninger.net> In-Reply-To: <4FD3AD35.3090301@denninger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:13:59 -0000 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. 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. > 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. -- Adam Strohl http://www.ateamsystems.com/