From owner-freebsd-chat Wed Mar 7 7:49:27 2001 Delivered-To: freebsd-chat@freebsd.org Received: from smtppop2pub.verizon.net (smtppop2pub.gte.net [206.46.170.21]) by hub.freebsd.org (Postfix) with ESMTP id 84FAA37B718 for ; Wed, 7 Mar 2001 07:49:24 -0800 (PST) (envelope-from res03db2@gte.net) Received: from gte.net (evrtwa1-ar4-4-34-145-186.dsl.gtei.net [4.34.145.186]) by smtppop2pub.verizon.net with ESMTP ; id JAA105568640 Wed, 7 Mar 2001 09:49:33 -0600 (CST) Received: (from res03db2@localhost) by gte.net (8.9.3/8.9.3) id HAA47689; Wed, 7 Mar 2001 07:49:17 -0800 (PST) (envelope-from res03db2@gte.net) Date: Wed, 7 Mar 2001 07:49:17 -0800 From: Robert Clark To: Terry Lambert Cc: Wes Peters , rjesup@wgate.com, Mike Meyer , Matt Dillon , Alfred Perlstein , josb@cncdsl.com, chat@FreeBSD.ORG Subject: Re: DJBDNS vs. BIND Message-ID: <20010307074917.B47638@darkstar.gte.net> References: <3AA5DB60.86A5C03D@softweyr.com> <200103070840.BAA14141@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <200103070840.BAA14141@usr05.primenet.com>; from tlambert@primenet.com on Wed, Mar 07, 2001 at 08:40:01AM +0000 Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Mar 07, 2001 at 08:40:01AM +0000, Terry Lambert wrote: > > > I would argue that human recovery is not a useful scenario, even > > > in the absence of a backup. > > > > Which flies in the face of every system recovery ever attempted, including > > the one I got to do last week. Even if you just finished a full backup > > of the system when it crashed/got killed, some files may be out of date. > > You are thinking about systems which have sufficient exposed > complexity that there are likely to be operators on hand to > do the job; the incremental costs of doing the job are, I > think, unrelated. A storage format and appropriate tools to > allow severable partial recovery of the data by a human are > generally enough. > > Basically, this means that binary data is not the issue, easy > human recovery in this situation is. > > I'd also argue that this situtation itself is increasingly > rare. In an embedded system running FreeBSD, for example, the > only time an operator with the necessary capability will see > te data, one way or another, is in a post mortem of a returned > system. This means that the vast majority of cases require > the ability to perform automatic "best guess" recovery, at a > minimum, or "last change state rollback" (effectively, working > configuration versioning), at best. > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > In the instance of a post mortem, would a log of successive configuration changes be more valuable than a file where only the last state is stored? Some config files do track successive changes to a small degree. Or at least show something about what added a section to the file. (rc.conf) [RC] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message