From owner-freebsd-questions Tue Apr 17 23:33:40 2001 Delivered-To: freebsd-questions@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id BE26937B43C for ; Tue, 17 Apr 2001 23:33:35 -0700 (PDT) (envelope-from mwm@mired.org) Received: (qmail 11112 invoked by uid 100); 18 Apr 2001 06:33:34 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15069.13630.549850.806893@guru.mired.org> Date: Wed, 18 Apr 2001 01:33:34 -0500 To: Rick Duvall Cc: questions@freebsd.org Subject: Re: Backup and Verify In-Reply-To: <45022897@toto.iv> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Rick Duvall types: > What is the best way to back up a FreeBSD system to tape and verify the > backup. I have been trying with dump, but I don't know of any way to > verify that. Then, I tried tar with the -W option, and that didn't work > (guess my tape drive doesn't support it). Amanda won't work for us > because I find it isn't really designed for a single box, but rather for > backing up and restoring multiple boxes, AND it's too difficult for the > average ordinary layman to do a disaster recovery with Amanda on a totally > dead system. > > Here are my requirements: Your requirements are incomplete, and I'm not sure they can be met as stated. > * Backups must be done on the live system (single machine with a tape > drive) This is a bad idea. Not "you must be out of your gourd" bad, but "you're asking for trouble" bad. Backups of a live filesystem mean that you can miss files, or dump bad copies of a file. For incrementals, this is a minor problem - you've got one or two files that will need be updated tomorrow. For level 0s, this is a bit of a problem. If some regularly scheduled activity is causing the file to be missed, it may never get backed up, which is bad. For instance, if your backups happen in the midst of updating the financial database, that database will probably never be backed up. > * Backups must be level 0 every time, and must be verified. You forgot to specify what happens when the verify fails. I'd also be interested to know whether the case where a file is backed up, then changed before the backup is verified. Does the verify fail? If not, how is the verification done? Can it fail for just one file, which needs to be backed up again? > * Backups must be logged, especially the verify > > * After the verify, the tape must eject. These are both pretty trivial. > * Must have a disaster recovery solution so that if I get hit by a Mac > Truck, the average joe blow can do the disaster recovery. I prefer a > bootable cd they can put in which will boot, and ask for the last tape, > and will do the restore on a new hard drive, partition it and everything. > virtually no user input for disaster recovery. This seems to imply that you want to back the file system up in a consistent state. That rules out any solution I know could be made to work. You might be able to use vinum to do this for you. The idea is to mirror your file system, then when you want a backup, take one mirror offline, backup that mirror, then put it back and let vinum resync the two drives. You could still catch the file system in the middle of a transaction, which might or might not be acceptable. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message