Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!pa.dec.com!bacchus!mwm From: mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) Newsgroups: comp.unix.admin Subject: Re: SUMMARY: Backup while in multi-user mode Message-ID: Date: 21 May 91 16:10:50 GMT References: <1991May20.123129.14433@forwiss.uni-passau.de> <1991May20.204327.17694@erg.sri.com> <690@silence.princeton.nj.us> Sender: news@pa.dec.com (News) Organization: Missionaria Phonibalonica Lines: 27 In-Reply-To: jay@silence.princeton.nj.us's message of 21 May 91 07:30:05 GMT In article <690@silence.princeton.nj.us> jay@silence.princeton.nj.us (Jay Plett) writes: Look at the odds. The probability of a disk crash on any particular day is really very small. The probability of a bad level 0 done on a live filesystem might be larger, but it's still small. The probability of two successive bad tapes is smaller. This last statement is only true if you assume that bad dumps are unrelated. This is a false assumption. Given that someone was doing something that caused a dump to be bad one day, I'd say the probability of them having done that the previous day is larger than the probability that a dump would be bad. And the longer they've been doing it, the more likely it is that the dump is bad. For instance, if you find that every dump made on a weekday night for the last month is bad, which way would you bet on the dump for tonight, if it were a weekday? You're right - a stable file system doesn't guarantee that you can do a restore. It eliminates one source of problems, and one that can be set up to occur on a regular basis, at that.