From owner-freebsd-questions Mon Jan 21 14:37:19 2002 Delivered-To: freebsd-questions@freebsd.org Received: from guru.mired.org (dsl-64-192-6-133.telocity.com [64.192.6.133]) by hub.freebsd.org (Postfix) with SMTP id 46A3537B404 for ; Mon, 21 Jan 2002 14:37:14 -0800 (PST) Received: (qmail 594 invoked by uid 100); 21 Jan 2002 22:37:11 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15436.38934.992453.860566@guru.mired.org> Date: Mon, 21 Jan 2002 16:37:10 -0600 To: Sir Cc: questions@freebsd.org Subject: Re: The tower of Hanoi In-Reply-To: <98444095@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\ From: "Mike Meyer" X-Delivery-Agent: TMDA/0.44 (Python 2.2; freebsd-4.4-STABLE-i386) Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Sir types: > Sir wrote: > > I was following a thread in the freebsd mailing list that you replied > > on. Seems like you have some experience with "dump". A read of the man > > pages has a realy baffling bit about the tower of hanoi algorithm. It > > says incrementals should be taken on a daily basis 3 2 5 4 7 6 9 8 9 > > 9.... It then goes on to say that a weekly should be taken with level > > 1. Well, there's more than 7 levels there so I'm not sure how it all > > fits together. It reads like they should be done all in the same day?? I > > was under the impression you shouldn't "dump" a disk unles it's > > umount'd. And, for us real newbies, how do you un-dump?? As Crist Clark explained, it's designed to balance the amount of data on the disk with the number of steps you need to restore. I've never seen anyone actually use this strategy. The only safe way to dump a file system is when it's static, meaning either unmounted or mounted read-only. Otherwise, you may wind up with a file that's not dumped, or dumped in an inconsistent state. The real danger here is if some daily process is done in sync with your backups, so that the data it produces is *never* properly written to a tape. To avoid that, run all your critical processes and the daily dump with the same invocation of periodic. > Just as an after-thought, ever seen a "bad sblock magic number" before?? Yes. It means your superblock has been written to by something that didn't know what it was doing. 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