Unix Backup & Recovery by W. Curtis Preston Unconfirmed error reports are from readers. They have not yet been approved or disproved by the author or editor and represent solely the opinion of the reader. If you have technical questions or error reports, you can send them to booktech@oreilly.com. Please specify the printing date of your copy. This page was last updated April 01, 2003. Here's the key to the markup: [page-number]: serious technical mistake {page-number}: minor technical mistake : important language/formatting problem (page-number): language change or minor formatting problem ?page-number?: reader question or request for clarification UNCONFIRMED errors and suggestions from readers: [script] in script comments; there is a variable in the script called B_FACTOR.. should that not also be B_SIZE? or is the factor indeed 64,000.. that seems rather large.... (41) 4th Paragraph; As I read it, the text referring to the table and the contents (not the headings) of the table are not in agreement. The text refers to a level 0 backup on Monday, whereas the table indicates a level 3. The subsequent referrals to backup levels in the text are all shifted off the table data by one day. I read the change note indicating that the table headings were changed in the December printing, but that note made no reference to the table's contents. {92} bottom, under "blocking factor"; in the first paragraph under "blocking factor" it is written "use dd to read the volume, and pipe the output of dd to dump...." then there is an example of what to type, in bold courrier, where the output is piped to restore.. basically, the text shout read "use dd to read the volume, and pipe the output to restore" (as the example shows) (75) 2nd bullet item; Small typo in the second dump command on this page: The command currently reads: dump 0unbdsf 126 141000 11500 /backup/home.dump/home The command should be: dump 0unbdsf 126 141000 11500 /backup/home.dump /home (107) 1st paragraph, under "Option: .... (B)"; the header for the section says "Option: specifying a blocking factor of 5120 (B)".. shouldnt that be blocking SIZE? its not as if the 5120 is multiplied by anything to get the blocking size.. its the final number.. {117} The author says (as I say) that wild cards aren't supported in tar in the definition of files you're trying to recover. This is wrong. Here is an example of a wild card use that works: el bid A lot of folks seem to think this. However, wild cards to define recovery targets are just fine in GNU tar. The trick is to make sure they're protected from expansion by the shell. For example: tar xvzf LiVid.tgz "*news.html" ...will happily recover LiVid/html/news.html from the tarball. (120) The last sentence in the last bulleted item in the sidebar now reads: "(You can suppress this with the -p option.)" Should read: "(You can suppress this with the -P option.)" {123} In the last paragraph, the author states that dump, tar, and cpio do not have the capability of piping their output through compress. Dump and tar (Solaris versions) allow the "-" specifier with the "f" option to send their output to stdout instead of a file or device. The stdout can then be piped to compress (or any other compress utility such as gzip, bzip2, etc.). {126} In the 1st full paragraph, the author states that tar cannot use ssh for networked backups. The table on the next page also states that tar can only use rsh for backup across the network. In fact GNU tar, in my opinion, deserves another look: The option --rsh-command= accepts any command, not only other locations for the standard rsh, as is mentioned in the GNU tar manual. Thus, adding --rsh-command=ssh prevents most problems piping might create, e.g., nonfunctional multivolume backups on a remote tape server. [126] In the second example on the page, which shows how to create backup tapes on remote hosts, the first two lines now read: #dump 0bdsf 64 100000 100000 - \ | ssh remote_host "dd if=device bs=64k" Should read: #dump 0bdsf 64 100000 100000 - / \ | ssh remote_host "dd of=device bs=64k" (146) The first paragraph under "AMANDA" now reads: "AMANDA, the Advanced Maryland Automated Network Disk Archiver, is a public domain utility..." Should read: "AMANDA, the Advanced Maryland Automated Network Disk Archiver, is an open source utility..." (268) The code line just after the third paragraph reads: # installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/ c0t0d0s0 This incorrectly refers to SCSI target disk #0 (/dev/rdsk/c0t0d0s0) rather than target disk #3 (/dev/rdsk/c0t3d0s0), which is the default boot disk as well as the example used in all previous examples in the step-by-step instruction. (279) line 4; The partition type for /dev/hda5 is listed as 82 Linux native, this should be Linux swap (as it is in various other samples on this and the previous page) {364} The third line of the footnote reads: "can be used in conjunction with rman to back up to disk." Should read: "can be used in conjunction with rman to back up to tape." {Online Chapter 14} Could this be better? There are two problems with the preceding scenario described. The first problem is that the log of Art's transaction should have been flushed to disk as soon as the transaction was committed. Changing the instance to unbuffered logging fixes this problem. With the previous buffered logging example, Art's transaction would be lost. However, if it were flushed as soon as it was committed, the chances of the transaction being lost would be greatly reduced. To be honest, I can't find a good reason to run an instance in buffered-logging mode anymore. Buffered logging used to provide a performance gain, but in Informix 7.x, the performance difference between unbuffered and buffered logging is minimal. (In fact, many DBAs tell me the gain was never that great.) This performance gain was the only reason for using >unbuffered< logging, and I believe the risk of database corruption is just too great. Another error: "last" word should be ? {492}, 2nd paragraph after the first example. The two log files listed in italics have the same pathname, I suspect the 2nd italicized entry should be: /db/Oracle/b/oradata/crash/redocrash01.log which will result in two more corrections in the subsequent paragraph: --------------------------------------------------------------------------- For example, if /db/Oracle/a/oradata/crash/redocrash01.log was missing, but /db/Oracle/b/oradata/crash/redocrash01.log was intact, issue the following command: $ cp /db/Oracle/b/oradata/crash/redocrash01.log \ /db/Oracle/a/oradata/crash/redocrash01.log --------------------------------------------------------------------------- {493} There are a number of references to: /logs1redolog01.log /logs1redolog02.log /logs1redolog03.log /logs2redolog01.log /logs3redolog01.log /logs2redolog02.log /logs3redolog02.log /logs2redolog03.log /logs3redolog03.log These should read as: /logs1/redolog01.log /logs1/redolog02.log /logs1/redolog03.log /logs2/redolog01.log /logs3/redolog01.log /logs2/redolog02.log /logs3/redolog02.log /logs2/redolog03.log /logs3/redolog03.log (Note the addidtion of the / ) [616] The second bold heading reads: "Choosing on a Backup Drive" Perhaps it should be: "Choosing a Backup Drive" or "Deciding on a Backup drive"