home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!mane.cgrg.ohio-state.edu!arrakis!oodis01!sadis01!sadis05.kelly.af.mil!donr
- From: donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST)
- Newsgroups: comp.unix.admin
- Subject: Re: Dumping a Gigabyte
- Message-ID: <761@sadis01.sa.aflc.af.mil>
- Date: 21 Jan 93 23:34:22 GMT
- References: <1j55eiINNk3d@BSDI.COM> <id.DZQW._25@ferranti.com> <1993Jan17.210451.14999@siemens.com>
- Sender: news@sadis01.sa.aflc.af.mil
- Organization: 1923CCSG/SC Kelly AFB, San Antonio, TX
- Lines: 23
-
- Some very good information in this thread. Sorry I missed the original
- posting. One issue that has not been addressed: what about mirroring
- filesystems and backing up from a offline mirror when necessary? Yes,
- this is expensive (disk space $ * 2) but cheap compared to corrupt
- backups when you need them, and would reduce the likelyhood of needing
- the backups in the first place significantly. performance is usually
- better on the read side as well, depending on the mirroring
- configuration (full spindles preferred), by eliminating head contention
- during the backup operation. However, few if any tape subsystems I have
- had the pleasure of working with could take advantage of the
- improvement. NOTE: if the mirrored disk is being used as storage for a
- database (ala ORACLE, UNIFY) care should be taken to shut down the
- database engine prior to taking the mirror partition offline for backup
- or the above claims of data integrity are null and void. Once the
- mirrored piece is offline the datbase can be restarted immediately and
- can run during the backup operation. There is also no reason to halt
- the database to reattach the mirrored piece - it will 'catch up'
- automatically.
-
- We run a Pyramid MIS-4/4, but the above behavior has been noted from
- other platforms as well.
-
- -- donr
-