home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / unix / admin / 7200 < prev    next >
Encoding:
Text File  |  1993-01-22  |  3.3 KB  |  61 lines
  1. Newsgroups: comp.unix.admin
  2. Path: sparky!uunet!destroyer!cs.ubc.ca!newsserver.sfu.ca!sfu.ca!vanepp
  3. From: vanepp@fraser.sfu.ca (Peter Van Epp)
  4. Subject: Re: Dumping a Gigabyte
  5. Message-ID: <vanepp.727719072@sfu.ca>
  6. Sender: news@sfu.ca
  7. Organization: Simon Fraser University, Burnaby, B.C., Canada
  8. References: <1j55eiINNk3d@BSDI.COM> <id.DZQW._25@ferranti.com> <1993Jan17.210451.14999@siemens.com> <761@sadis01.sa.aflc.af.mil>
  9. Date: Fri, 22 Jan 1993 16:11:12 GMT
  10. Lines: 49
  11.  
  12. donr@sadis05.kelly.af.mil (DONALD G. RUEBENSON II - SCST) writes:
  13.  
  14. >Some very good information in this thread.  Sorry I missed the original
  15. >posting.  One issue that has not been addressed: what about mirroring
  16. >filesystems and backing up from a offline mirror when necessary?  Yes,
  17. >this is expensive (disk space $ * 2) but cheap compared to corrupt
  18. >backups when you need them, and would reduce the likelyhood of needing
  19. >the backups in the first place significantly.  performance is usually
  20. >better on the read side as well, depending on the mirroring
  21. >configuration (full spindles preferred), by eliminating head contention
  22. >during the backup operation.  However, few if any tape subsystems I have
  23. >had the pleasure of working with could take advantage of the
  24. >improvement.  NOTE: if the mirrored disk is being used as storage for a
  25. >database (ala ORACLE, UNIFY) care should be taken to shut down the
  26. >database engine prior to taking the mirror partition offline for backup
  27. >or the above claims of data integrity are null and void.  Once the
  28. >mirrored piece is offline the datbase can be restarted immediately and
  29. >can run during the backup operation.  There is also no reason to halt
  30. >the database to reattach the mirrored piece - it will 'catch up'
  31. >automatically.
  32.  
  33. >We run a Pyramid MIS-4/4, but the above behavior has been noted from
  34. >other platforms as well.
  35.  
  36. >    -- donr
  37.  
  38. We run a (home grown) system like this on our Auspex NFS file server. I am
  39. curious about what you mean about the tape subsystem not taking advantage 
  40. of it. How would a tape drive take advantage of it (ours dumps the mirror
  41. volume)? 
  42.     There is a possible additional restore advantage here too, you can
  43. use dd to dump the mirror instead of backup and avoid the time it takes 
  44. restore to create directories on a full restore (you just dd the tape back
  45. to a new disk and fsck). Since (at least on Exabyte 8200s and an Auspex)
  46. you are limited by tape speed, the is no time cost to single file restores
  47. either, you just dd the tape to the mirror drive, fsck it and mount it 
  48. read only somewhere, and all the files on the backup volume are availible
  49. for the users to pick and choose (and they can remain there until the 
  50. next full backup). I have code that both locks /etc/dumpdates (so multiple
  51. dump streams work correctly) and lies through its teeth about what partition
  52. just got dumped (since it is always the mirror volume not the real volume)
  53. so that dump/restore incrementals without mirrors work as well. While I was
  54. at it, I also added labels to the tapes (and the code to check them in the
  55. dump scripts) so that we are sure that the correct partition got dumped to
  56. the correct tape (and it is an ascii file so that it can be dumped with 
  57. dd from the tape if the tape label falls of).
  58.  
  59. Peter Van Epp / Operations and Technical Support 
  60. Simon Fraser University, Burnaby, B.C. Canada
  61.