Date: Sun, 10 Jun 2012 10:26:25 -0500 From: Karl Denninger <karl@denninger.net> To: Adam Strohl <adams-freebsd@ateamsystems.com> Cc: freebsd-stable@freebsd.org Subject: Re: Backups with 9-STABLE -- Options? Message-ID: <4FD4BCA1.2010502@denninger.net> In-Reply-To: <4FD4B9AC.6090604@ateamsystems.com> References: <4FD3AD35.3090301@denninger.net> <4FD4B9AC.6090604@ateamsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 ®/ <http://market-ticker.org>; Cuda Systems LLC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FD4BCA1.2010502>