Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!dsinc!netnews.upenn.edu!gynko!rsk From: rsk@gynko.circ.upenn.edu (Rich Kulawiec) Newsgroups: comp.unix.admin Subject: Re: SUMMARY: Backup while in multi-user mode Summary: 4.3BSD (or greater) dump can handle most of it. Message-ID: <43617@netnews.upenn.edu> Date: 22 May 91 13:16:09 GMT References: <1991May20.204327.17694@erg.sri.com> <690@silence.princeton.nj.us> Sender: news@netnews.upenn.edu Organization: Cardiothoracic Imaging Research Center Lines: 25 Nntp-Posting-Host: gynko.circ.upenn.edu In article verber@pacific.mps.ohio-state.edu (Mark Verber) writes: >I understand the desire to do dumps on active file systems for daily >incrementals... but what do people have against doing the level 0 >dumps in single user. Can't you afford a few hours downtime in the >middle of the night once a month to insure a clean dump? The answer to that last question, for some folks in certain environments, is "no, we can't". But if you are running 4.3BSD or a derivative thereof, you are probably running a version of dump(8) that has modifications made at BRL (by Doug Gwyn, I think), Purdue EE (George Goble), Purdue CS (Dan Trinkle) and Purdue CC (me). Some of those modifications are intended to prevent dump from being confused by an active filesystem. Those mods aren't bulletproof -- but in about five years of using this version of dump on many machines (VAX, Sun-3, Sun-4, MIPS, Pmax, etc.) I've never encountered a dump that I couldn't restore, i.e. that wasn't self-consistent. That doesn't mean that all such dumps were "complete", especially since the meaning of "complete" gets fuzzy when we attempt to apply that term to an active filesystem; but it does mean that I had what I needed to recover from crashes. -- ---Rsk rsk@gynko.circ.upenn.edu