home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / sun / admin / 9656 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.3 KB
  1. Xref: sparky comp.sys.sun.admin:9656 comp.sys.sun.misc:5951
  2. Path: sparky!uunet!paladin.american.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!natinst.com!news.dell.com!texsun!cronkite.Central.Sun.COM!rmtc.Central.Sun.COM!sam
  3. From: sam@rmtc.Central.Sun.COM (Sam Falkner)
  4. Newsgroups: comp.sys.sun.managers,comp.sys.sun.admin,comp.sys.sun.misc
  5. Subject: Re: Any way to reduce the size of BackupCoPilot Database?
  6. Message-ID: <1992Dec21.221812.16854@rmtc.Central.Sun.COM>
  7. Date: 21 Dec 92 22:18:12 GMT
  8. References: <MEYER.92Dec11160628@darkwing.uoregon.edu>
  9. Distribution: comp
  10. Organization: Sun Microsystems, Inc.
  11. Lines: 41
  12.  
  13. meyer@darkwing.uoregon.edu (David M. Meyer 503/346-1747) writes:
  14.  
  15. >    Does anyone know if there is a way to reduce the size of
  16. >    BackupCoPilot Database? Ours is huge (like 200MB).
  17.  
  18. here's some general stuff.  you probably already know most of this
  19. stuff, but maybe something will help you.  feel free to email me if
  20. you'd like me to go into it more (but i'll be away from email from
  21. 12/23 to 1/4).
  22.  
  23. there are two main things you can do:
  24.  
  25. (1) speed up your expiration cycle.
  26.  
  27. (2) do a `dumpdm dir_rebuild'.  this does what some people believe
  28. `dumpdm reclaim' does, i.e. it can punt dead records and free up disk
  29. space.  unfortunately, it's cumbersome and relatively slow.  also, i'd
  30. recommend a mapsize of at least 100 (i.e. `-m 100').  note that there's
  31. a misprint in the dumpdm man page -- the default mapsize isn't really
  32. `1', it's `100', and the max is really `500' (at least if you have the
  33. patch).
  34.  
  35. here's some more info:
  36.  
  37. a filesystem with lots of little files is worse than one with a few big
  38. files.  this is obvious, but worth mentioning.
  39.  
  40. when a tape `expires', it doesn't leave the database right then.  it
  41. only leaves the database when rpc.dumpdbd receives a new `file #1' for
  42. that tape.  so, if you have a ton of expired tapes and you decide that
  43. space is more important than recoverability, do a `dumpdm delete' on
  44. expired tapes.  also, if `file #1' didn't make it in for some reason,
  45. you'll have problems.
  46.  
  47. as the admin guide says (i think), you should do `dumpdm reclaim' at
  48. least once every three months.  however, this doesn't buy you any disk
  49. space directly!  many people mistakenly believe that `dumpdm reclaim'
  50. will make their database smaller.  read the man page for dumpdm
  51. carefully.  `reclaim' helps on future updates.
  52.  
  53. - sam
  54.