home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / unix / admin / 6846 < prev    next >
Encoding:
Text File  |  1992-12-31  |  2.1 KB  |  44 lines
  1. Newsgroups: comp.unix.admin
  2. Path: sparky!uunet!gatech!destroyer!cs.ubc.ca!uw-beaver!fluke!gtisqr!toddi
  3. From: toddi@mav.com (Todd Inch)
  4. Subject: Re: How do you back up a terabyte?
  5. Message-ID: <1992Dec31.174549.677@mav.com>
  6. Organization: Maverick International Inc.
  7. References: <ericw.724459057@hobbes> <1992Dec16.161430.1109@cc.ic.ac.uk>
  8. Date: Thu, 31 Dec 92 17:45:49 GMT
  9. Lines: 33
  10.  
  11. In article <1992Dec16.161430.1109@cc.ic.ac.uk> cmaae47@imperial.ac.uk writes:
  12. >In article <ericw.724459057@hobbes>, ericw@hobbes.amd.com (Eric Wedaa) writes:
  13. >- And does anyone remember the real reason why dump/tar/cpio is not 
  14. >- a good thing on an acitve filesystem?
  15. >
  16. >Because users may change files while they are being backed up, and you may
  17. >end up with an inconsistent copy on the tape - say a random access file is 
  18. >keeping pointers to records at its end, and the data at the beginning.
  19.  
  20. And likewise two separate files may be interdependant, such as detail
  21. and header records in a database, or a data file and its accompanying
  22. hashed-key file.
  23.  
  24. Also, in my case running the backups during the day, which I do do,
  25. slows down overall system throughput significantly.
  26.  
  27. Because I'm in a database environment and the data files don't all fit
  28. onto one of my tapes, I do full backups during the day when I can swap
  29. the tapes but then automatically back up any recently changed files
  30. that night, which does fit onto one tape.  Because my data files
  31. contain their own hashed keys, the copies I make while the system is in
  32. use are fairly often corrupted internally.
  33.  
  34. Sometimes I'll just "cp" a file to make an on-disk backup, but
  35. afterward I have to double-check the modification times to make sure
  36. the original wasn't changed during my cp process.
  37.  
  38. If you have NO databases, just users doing word processing or somesuch with
  39. text files, most of these issues won't apply.  But then, the built-in Unix
  40. stuff such as accounting and error-logging and things like news all have
  41. database structures that span across multiple files and/or do random writes
  42. to files.  You're only safe if everything writes an entire file in a single
  43. write operation.
  44.