home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / aix / 9386 < prev    next >
Encoding:
Text File  |  1992-09-04  |  2.6 KB  |  59 lines
  1. Newsgroups: comp.unix.aix
  2. Path: sparky!uunet!spool.mu.edu!sdd.hp.com!cs.utexas.edu!sun-barr!ames!haven.umd.edu!darwin.sura.net!uvaarpa!murdoch!holmes.acc.Virginia.EDU!op
  3. From: op@holmes.acc.Virginia.EDU (Olaf  Pors)
  4. Subject: Re: rootvg restores by inode
  5. Message-ID: <1992Sep4.130451.10370@murdoch.acc.Virginia.EDU>
  6. Sender: usenet@murdoch.acc.Virginia.EDU
  7. Organization: University of Virginia
  8. References: <1992Sep3.181334.13202@murdoch.acc.Virginia.EDU> <6420@vtserf.cc.vt.edu>
  9. Date: Fri, 4 Sep 1992 13:04:51 GMT
  10. Lines: 47
  11.  
  12. In article <6420@vtserf.cc.vt.edu> valdis@vttcf.cc.vt.edu (Valdis Kletnieks) writes:
  13. >What I've always done is the following:
  14. >
  15. >(a) take a full backup once a week - in this case, a 'mksysb' flavor.
  16. >(b) The backup script touches /fulldump
  17. >(c) The incremental does a 'find / -newer /fulldump -print | backup -i'
  18. >
  19. >In case of failure, you just spin the mksysb - this gets you something
  20. >back that will at least *BOOT*.  Then you just /etc/restore the incremental
  21. >over the now-semi-functional system.
  22.  
  23. >I don't see that backup-by-inode is a big issue - the functionality
  24. >is there via other means.  
  25.  
  26.   I think you must have missed my original posting on this
  27. issue.  Your solution unfortunately brings back files that
  28. were removed between the incremental restores.  This could
  29. possibly overflow the filesystem.
  30.  
  31.   There's another problem: your restore of the mksysb tape
  32. has created a bootable system.  Great, you boot the
  33. thing.  Now, you attempt to restore files from the
  34. incremental tapes, and in most cases you'd be ok.
  35. However, there may be some files on a tape, such as a new
  36. version of a shared library, which cannot just be copied
  37. over top of one currently in use without crashing the
  38. machine.  This is one reason why such things are done from
  39. a RAM filesystem.  Knowing this, you then find out that the
  40. "limited function maintenance shell" facility on a standard
  41. boot tape is not equipped to handle incremental restores.
  42. I don't know about you, but I don't need glitches, gotchas,
  43. and surprises when a major machine is down and needs to
  44. be restored.  And this is the worst time to have to
  45. pick through the list of files on an incremental backup
  46. tape and hand-restore some of them.
  47.  
  48.   These are reasons why backup-by-inode is a big issue -
  49. the functionality is otherwise NOT there.  The problem is
  50. that people come up with fairly good solutions, like
  51. yours, that work most of the time, so generally people are
  52. happy and don't complain.  But that 1% of the time that
  53. the solution fails, you get a lot of wasted time, unhappy
  54. users, upset administrators, and bad sentiments against
  55. IBM.  Why wait for this?  Why not fix the whole thing
  56. right to begin with?
  57.  
  58. Olaf Pors
  59.