home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / bsd / 5114 < prev    next >
Encoding:
Internet Message Format  |  1992-09-04  |  4.9 KB
  1. Path: sparky!uunet!dtix!darwin.sura.net!jvnc.net!yale.edu!ira.uka.de!sun1.ruf.uni-freiburg.de!News.BelWue.DE!news.uni-tuebingen.de!mailserv!zxmsd01
  2. From: zxmsd01@mailserv.zdv.uni-tuebingen.de (Gunther Schadow)
  3. Newsgroups: comp.unix.bsd
  4. Subject: Re: backup w/ compression for UN*X?
  5. Message-ID: <zxmsd01.715606940@mailserv>
  6. Date: 4 Sep 92 11:42:20 GMT
  7. References: <1992Sep3.015437.15379@msuinfo.cl.msu.edu> <dtb.715502483@otto> <1992Sep3.155227.16767@msuinfo.cl.msu.edu>
  8. Sender: news@softserv.zdv.uni-tuebingen.de (News Operator)
  9. Organization: Comp. Center (ZDV) U of Tuebingen, FRG
  10. Lines: 80
  11.  
  12. In <1992Sep3.155227.16767@msuinfo.cl.msu.edu> paoletti@comp/unix/bsdps.msu.edu (David R. Paoletti) writes:
  13.  
  14. >Basically, people have responded to my post by pointing out
  15. >that you can pipe through the compress program.  I know to
  16. >use tar, compress, cpio, dd, pipes, etc.  I should have
  17. >included the following point in my original post:
  18.  
  19. >If you pipe through the compress program, doesn't it write
  20. >its compression/translation table at the beginning of the
  21. >output that it produces?  What happens if the beginning of
  22. >the tape or the first disk is damaged?  Or am I incorrect
  23. >in assuming that compress works this way?
  24. THAT's exactly my problem, I'll repost my suggestions to that problem
  25. here, because I think it already went off on many sites.
  26.   
  27. >Dave Paoletti :)
  28.  
  29. I think it is most desirable to have a tar with a kind of -z option
  30. (say -Z) which does compress each file *before* dumping it into the
  31. archive. This method would be superior against just compressing the
  32. output stream of tar, what the -z option actually does. Yet it is
  33. harder to realize.  
  34.   The -z option can easily be simulated by a pipe: "tar -cf - whatever
  35. |compress >medium". -z and -M wont work together anyway in the current
  36. GNU tar. But the -Z option I am thinking of, is not realizable with a
  37. simple shell scipt. You cannot just say something like "tar -cf medium
  38. (compress whatever)".
  39.   To compress every file on your disk before archiving it is no
  40. solution, because (1) it takes time, (2) you have to uncompress
  41. afterwards and (3) the access time will be modified, so you lose
  42. information.
  43.   I think it is *urgently* necessary to invent such a -Z feature into
  44. GNU tar. The reason why this should be done is at hand: Say, you have
  45. a backup of 30 disks. If this is one huge compressed tar archive, and
  46. you loose one disk for whatever reason, you can forget about getting a
  47. single correct file back from the disks beyond that deficient disk,
  48. because uncompress gets completely out of sync. Why should you make
  49. any backup then, if you cannot rely on it in case of emergency? It is
  50. far more possible, that there is one out of 30 disks damaged -- what
  51. about number 3 :-( -- than your 120 MByte HardDisk will crash over
  52. years.
  53.   GNU tar is abel to skip over damaged records and can even start
  54. untarring from any point within the tar file, but only tar is, not
  55. uncompress. This feature of GNU tar is also useful if you don't want
  56. to spend half an hour playing disk jockey while uncompress|tar skips
  57. over 25 disks until it extracts the 20kByte file you want in a few
  58. seconds. Or even worse you made a type mistake in the file name you
  59. give to tar, or you forgot the actual path to it: Again 30 minutes of
  60. your live...
  61.   Is there anybody who backed up his 240MBytes disk in 240 floppy disk
  62. with the normal dump? Or made an extremely unreliable .tar.Z backup
  63. onto approx 180 disks? I didn't --- and I cross my fingers :-). The
  64. only backup I have is the Network; not that I had the facility to dump
  65. to an NFS, but I publish almost every good changes I made to 386BSD
  66. files onto agate.berkeley.edu.
  67.   Nice to have a tape, but can you afford to pay $50 for a 40MByte
  68. small cardridge of tape, if you need 6 of them for your level-0 dump?
  69. BTW: Has anybody tried to use a video taperecorder to dump his HD onto
  70. a cheap $2.5 videotape? This, together with a tar -Z facility would be
  71. the most convenient, cheap, secure, just effective way of archiving
  72. backup's or etc01 distributions.
  73.   These are just a few of my thoughts about backups, archives, and
  74. tar. I tried once to get into the tar sources to invent my -Z option,
  75. but I failed due to the complexity of tar's method, and mainly due to
  76. my lack of time. If there is anybody familiar with tar code, please
  77. think about my -Z ideas, and help GNU tar to become the best common
  78. archiving program!
  79.  
  80. regards
  81. -Gunther
  82. --
  83. -------------------------------------------------------------------------------
  84. Gunther Schadow,              e-mail: Gunther@mailserv.ZDV.Uni-Tuebingen.DE
  85. Sudetenstrasse 25,              Phone:  (49) 7071/37527
  86. 7400 Tuebingen, Germany.__________Stop__________Horn Please!__________O.K. TATA
  87. --
  88. -------------------------------------------------------------------------------
  89. Gunther Schadow,              e-mail: Gunther@mailserv.ZDV.Uni-Tuebingen.DE
  90. Sudetenstrasse 25,              Phone:  (49) 7071/37527
  91. 7400 Tuebingen, Germany.__________Stop__________Horn Please!__________O.K. TATA
  92.