Slashdot Log In
Unix Backup And Recovery
from the make-sure-you've-got-it-all dept.
| Unix Backup & Recovery | |
| author | W. Curtis Preston |
| pages | 709 |
| publisher | O'Reilly, 1999 |
| rating | 10/10 |
| reviewer | Greg Smith |
| ISBN | 1-56592-642-0 |
| summary | Complete coverage of Unix backup and recovery, just like the title says |
Cover Image
The Scenario
You're a system administrator suddenly tasked with handling the backup of all your employer's mission-critical data. Or maybe you've been handed a tape of questionable origin with the instructions "I need all the files off of this." Perhaps you're working on your company's disaster-recovery plan and are looking for advice about how to restore all the computers to operation in the event of catastrophe. Unix Backup & Recovery is a comprehensive volume designed to help with all of these tasks and many others.What's Bad
While the organization of topics is clear, the sheer scope of the book prevents easy digestion of the material by the casual reader. Those expecting to read a chapter or two at random may find some of the concepts hard to follow unless they first read the full 65 pages of introductory material. Also, I would have liked to see a clearer discussion of the differences in procedure and general philosophy between a typical small shop (where tapes are organized based on the day the backup was made) and the kind of unique-volume labeling that tends to accompany larger systems or commercial backup products. Since a lot of Unix systems are being managed lately by people whose background is in smaller systems, making this kind of transition is a very important topic.One part of the book's design may be good or bad depending on how you intend to read it. Areas deemed especially time-sensitive, like what features are included with which commercial backup system, are not addressed in the book. Instead, readers are referred to the author's backupcentral.com site for the latest information. While assuming that any Unix administrator has Internet access is probably not unreasonable, I found myself reading a lot of this book during spare moments while waiting for routine chores to complete. It was not helpful that I needed to access the Web site in order to follow the chapter I was reading while I waited for my car's oil to be changed.
What's Good
With many years' worth of practical experience, several specialist contributors, and dozens of technical reviewers, this book leaves few stones unturned. No matter how experienced you are at managing backups, you could probably learn at least a few tricks from Curtis Preston and his crew. Normally discussions about backups are relegated to, at best, a single chapter in a Unix administration book. Unix Backup & Recovery is the first title I've ever seen that covers this territory in full detail. In fact, even if you aren't specifically a Unix administrator, the discussion of topics like the most common causes of system failure and how to pitch a more reliable backup scheme to management are very cross-platform. They're worth reading no matter what type of computer system you rely upon.So What's In It For Me?
The first two chapters of the book provide a real-world approach to backups that include often-unaddressed topics like the availability of the backup hardware in the future, dealing with off-site storage, and exactly how high the cost of poor backups can be. With that basis, the native Unix utilities (dump, cpio, and tar) are evaluated. One particularly good part of that coverage is a discussion of tape portability, and notes on how the GNU versions of those utilities stack up in that and other contexts. Even Unix administrators who aren't involved with backups regularly might find this chapter interesting, as the information about how to read an unfamiliar tape you've been given is alone is worth the price of the book if you're ever stuck in that situation.For those looking to back up systems without much of a budget, a discussion of free backup tools ranges from writing scripts to automate the built-in Unix tools to coverage of the popular AMANDA backup system. The third section covers what to look for in a commercial backup product. This is light on specific recommendations, instead trying to educate the reader well enough to perform his or her own product selection. A somewhat related chapter covers the main ideas behind High Availability, which is obviously too big of a topic to cover fully in a 15-page section.
The next few chapters cover bare-metal backup and recovery, where the goal is to make a backup of the system capable of being used to create a new system in the event of a total failure. Many traditional solutions to this problem involve first re-installing the operating system, then restoring the backup. The author maintains this is a bad approach, and instead focuses on constructing a small bootable system (i.e. a Linux rescue floppy) capable of partitioning the drive and restoring the backup without laying down the OS first. SunOS/Solaris, Linux, Compaq True-64 Unix, HP-UX, IRIX and AIX are all covered.
Four chapters on database backup and recovery suggest how to integrate your backup solution with the database vendor's tools. Along with a general discussion aimed at bringing non-database administrators up to speed on DB lingo, separate chapters cover Informix, Oracle and Sybase. Finally, the three closing chapters to the book include miscellaneous information like backing up Rational's ClearCase product and selecting backup hardware, as well as some notes on upcoming trends.
Competent system administrators, either through forward thinking or past battle scars, develop a level of paranoia about their computers and how strongly their data should be protected that people outside the field find it hard to fathom. If you'd like to hone your own sense that everyone is out to get you, and know how to stop them, Unix Backup & Recovery is as good of an introduction to that topic as you'll find anywhere.
Buy this from ThinkGeek.
Table of Contents
- Preparing for the Worst
- Backing It All Up
- Native Backup & Recovery Utilities
- Free Backup Utilities
- Commercial Backup Utilities
- High Availability
- Bare-Metal Backup & Recovery Methods: SunOS/Solaris
- Bare-Metal: Linux
- Bare-Metal: Compaq True-64 Unix
- Bare-Metal: HP-UX
- Bare-Metal: IRIX
- Bare-Metal: AIX
- Backing Up Databases
- Informix Backup & Recovery
- Oracle Backup & Recovery
- Sybase Backup & Recovery
- ClearCase Backup & Recovery
- Backup Hardware
- Miscellanea
Ah, but the linux piece is free... (Score:3)
While your point about the "hidden cost" of linux books is open to debate, it's moot here since this book's only Linux-focused chapter (bare metal recovery) has been made available for gratis:
http://www.backupcentral.com/bare-metal-recover
Re:This is why free is not better (Score:3)
Important Feature (Score:3)
One of the problems with standard UNIX backup utilities is the fact that they don't have a friendly interface. This isn't a problem for the sysadmin, if he needed a GUI I wouldn't hire him! But what about the secretary or other low-level employee that changes the tapes? Someone has to do that, and in many cases, such as smaller companies, the sysadmin isn't in there full time. A easy to use interface saying exactly what needs to be done is a must. Of course you just need a little prompt saying "Remove current tape" "Inset tape 1" but that can mean the difference between a backup system that gets used and one that is ignored.
Re:We need the opposite book to this (Score:3)
"In general, anything which really needs to be kept should be printed out and archived in duplicate..."
No offense, but this is a bad idea.
I have worked in the biotech industry for a number of years. Now for starters, any data supporting a publication, invention, or patent, has to be kept for seven years. (In Canada--I think it's the same in the US) The difference between seven years and 'permanent' isn't much when the average lifetime of achival media is less than that. In other words, if you're looking for a way of storing data for more than three or four years, your looking for essentially 'permanent' archives.
Secondly, the 'printing out in duplicate' idea implies that all data worth archiving is textual or visual. In one lab, we generated four-dimensional data sets, and did data interpretation on processed slices of extracted cubes. There's no WAY we could print out the data set, and even if we could, it would only be the processed data, using somewhat subjective processing parameters. The original data would be lost.
You do make a good point, though, that much of user 'data' is utter junk. Thing is, if you told people that it would be destroyed at the end of the month, we'd decimate an entire rainforest, printing out 'mouse balls.' One of the nice things about archiving computer data is that it's (relatively) cheap, resource-friendly, and easy. Makes it tempting to archive stuff that you never cared about keeping before.
Backup experiences (Score:4)
In short, for a backup scheme to be effective, it needs to get down and dirty with the filesystem - abstraction layers invariably lose performance (which in this case is defined by backup speed and how much tape is required).
The other problem is an incredible black hole of documentation. I've gone through everything at freshmeat, and none of them met my criterion of being able to do multi-level backups and could span volumes of variable size. These two criterion aren't exactly difficult to satisfy in the Windows world or even commercial UNIXes, but for linux OSS projects, it was nearly impossible to find it.
The list goes on. I hope this book can provide step-by-step documentation for setting up atleast ONE backup program. AMANDA I hear is nice, but when I downloaded the distribution.. I couldn't make heads or tails of it. This is coming from a guy who wasn't phased when setting up procmail recipes and getting Sendmail working in, uhh, unusual configurations.
That's my $0.02. In short, linux offerings are limited. People focus on the more glamorous things like kernel development or creating a GUI.. but I could really go for the basics - like an easy to use CLI-based backup program that has a decent feature set.
Re:We need the opposite book to this (Score:4)
If I could, I'd moderate StreetLawyer up in the hopes of starting a discussion (alas moderators don't hit the book reviews often)
While it may smack of a dark corporate culture of ingrained cover-ups to us geek-types, the fact is that excesive records can be a genuine danger even to those of us who feel we have nothing to hide.
IANAL, but I was recently the plaintiff in a civil suit, and I was surprised by the dismay of my attorney at the voluminous records I had kept, documenting every meeting with the defendant for the past two years (all cc'd to the defendant within days of the meeting, with requests for comments). I thought I was being diligent and even praiseworthy.
Not so. It turns out that my words, even if cc'd for comment, can almost always be used against me, but are apparently rather weak support for my version of events.
Fortunately, (much to my lawyer's surprise) we found nothing it those memos to injure my case, but they also were of no help when the defendant (more accurately, the defendant's employees - the defnadant was a large organization) simply pled "I don't know", "I don't remember the letter", and "I skim those things and throw them away. I don't have any of them in my files"
[It was infuriating, somehow we thing Big Outfits file everything -- and they probably do, but how are you going to prove it? This outfit had defended against such suits in the past, and had learned its lession well)
Most of us could stand to improve the organization in our lives, and are bitten by "I wish I had that file" more than "wish I didn't", but "too much data" is potentially harmful. As cases involving e-mail and USENET have shown, casual, ill-framed, or out-of-context remarks can be damning.
The cleaner your backups, the fewer irrelevant details (especially details even *you* didn't know) to mess you up. If you get sued for copying code, you don't want the plaintiff to be able to find a backup showing a bootleg copy of his program on your network -- even if it was just something your summer intern installed to help him/her understand your product.
If you had something in your house that was useless and potentially toxic, I hope you'd get rid of it (even if it is related to you by marriage
__________
We need the opposite book to this (Score:5)
Speaking as a lawyer, my view of the IT profession in general is that they are, for some weird psychological reason, obsessed with preserving all sorts of data of any sort forever, without any thought to whether keeping it is useful, or even downright destructive. In general, anything which really needs to be kept should be printed out and archived in duplicate (this also has the advantage of settling once and for all what time a document was created, unlike electronic formats), while "backups" of most user information should be more focused on deleting the useless and incriminating crap which most users clog up their hard drives with. Although I suppose that nobody's going to get rich selling new database programs or "enterprise level" record management systems that way.
just my opinion
John Saul Montoya