1.2. Why Should I Read This Book?
If you've been doing system administration for some time, you may be asking yourself this question. There are many answers. Perhaps self-preservation is your primary motivator. You'd like to make sure you don't lose your job the
next
time a disk drive dies. Perhaps you've already got a decent backup system and you'd just like to make it better. Maybe you are looking for some new ideas about how to deal with upcoming backup and recovery needs. What
follows
are some of the reasons
I
think you should read this book.
1.2.1. Schadenfreude
Schadenfreude is a German word that means to take joy in the misfortunes of others. It's why we watch those weird
videos
on the Internet where some idiot
tries
to do something stupid and ends up hurting himself. Each of the sidebars in this book is a true horror story that really
happened
to someone I know. These are not urban legends or
horror
stories passed on from admin to admin. These are firsthand encounters with disaster. There's a schadenfreude element to reading these stories, of course. But each story also makes a point, and it was not just made up to make that point. The things that I warn about in this book really happen. This can be a very tough job if you are not prepared, so read closely. You might want to start by reading the sidebar "The One That Got Away" later in this chpater. It's the story of the defining moment in my career.
|
"You mean to tell me that we have
absolutely
no
backups
of
paris
whatsoever?" I will never forget those words. I had been in charge of backups for only two months, and I just knew my career was over. We had moved an Oracle application from one server to another about six weeks earlier, and there was one crucial part of the move that I missed. I knew very little about database backups in those days, and I didn't realize that I needed to shut down an Oracle database before backing it up. This was accomplished on the old server by a
cron
job that I never knew existed. I
discovered
all of this
after
a disk on the new server went south.
"Just give us the last full backup," they said. I started looking through my logs. That's when I started seeing the errors. "No problem," I thought, "I'll just use an older backup." The older logs didn't look any better. Frantic, I looked at log after log until I came to one that
looked
as if it were OK. It was just over six weeks old. When I went to grab that volume, I realized that we had a six-week rotation cycle, and we had overwritten that volume two days before.
That was it! At that moment, I knew that I'd be looking for another job. This was our purchasing database, and this data loss would amount to approximately two months of lost purchase orders for a multibillion-dollar company.
So I told my boss the news. That's when I
heard
, "You mean to tell me that we have absolutely no backups of
paris
whatsoever?" Isn't it amazing that I haven't forgotten its
name
? I don't remember any other system
names
from that place, but I remember this one. I felt so small that I could have fit inside a 4 mm tape box. Fortunately, a system administrator worked what, at the time, I could only describe as magic. The dead disk was resurrected, and the data was recovered straight from the disk itself. We lost only a few days' worth of data. Our department had to send a memo to the entire company saying that any purchase orders entered in the last two days had to be reentered. I should have framed a copy of that memo to
remind
me what can happen if you don't take this job seriously enough. I didn't need to though; its image is permanently etched in my brain.
Some of this book's reviewers said things like, "That's pretty bold! You're writing a book on backups, and you start it out with a story about how you messed up. Some authority you are!" Why did I include it? Through all the
years
, and all the outages, this one sticks in my mind. Perhaps that's because it's the only one that almost "got me." Had it not been for the
miraculous
efforts of a wonderful administrator named Joe Fitzpatrick, my career might have been over before it started. I include this anecdote because:
It's the one that changed the direction of my career.
There are several
valuable
lessons that I learned from it, which I discuss in this book.
It could have been avoided if I had had a book like this one.
You must admit that it's pretty darn scary.
|
1.2.2. You Never Want to Say These Words
"We lost only a few days' worth of data." In the sidebar "The One That Got Away," I said that we lost only a few days worth of data. I swore the day I said these words that I would never say them again. From that day forward, I was convinced of the importance of backups. I never again assumed anything, and I
began
to study everything I could about backup technology. This book represents my attempt to compile what I have learned about inexpensive backups into a single volume, and it is written so that no one who reads it should ever need to utter the
preceding
statement. In my opinion,
no amount of data loss is acceptable
. I would also wager that you would be hard-pressed to find an end
user
who would feel much different. Whether it's a spreadsheet that one person created or a customer database representing hours or days of sales invoices and the efforts of hundreds of peopleask the person who needs the data how much data loss they think is acceptable. Every statement, every opinion, every story, and every chapter in this book is based on the
premise
that any data loss is unacceptable. Let me state that again for emphasis.
|
With the technology that is now available, there is no reason for any data to be lostthat is,
if
backups are given the proper attention and priority that they need.
|
|
1.2.3. You're Curious About
Open
-Source Backup Products
Just a few years ago, you could perform your backups with a few scripts and
dump
,
tar
, or
cpio
, or
ntbackup
. The demand for
midrange
computers grew astronomically, and the need for bigger databases, larger
drives
or filesystems, long filenames, and long pathnames grew proportionally. These large databases and filesystems started shipping, which then created a large market for commercial backup utilities, and one or two such products emerged; scores of others eventually followed.
Some of these early products were just GUIs and volume management built on top of existing native backup utilities to provide enhanced levels of functionality. Other companies felt that these native utilities had many limitations that could not be fixed without abandoning them altogether. Those companies chose to develop custom, even proprietary, backup
methods
. They attempted to
overcome
the limitations that products based on
dump
and
tar
could not overcome.
In recent years, the demand for centralized backup and recovery has also given rise to a number of open-source backup and recovery tools, six of which are covered in this book. The open-source backup market followed a pattern similar to the commercial products mentioned. The original open-source backup product, Amanda, is a wrapper around the native utility of your choice. BackupPC
leaves
data in its original format, and Bacula uses a custom format designed to overcome the limitations of GNU
tar
.
There are now a number of choices in the open-source backup market. It's quite possible that one or more of the open-source products covered in this book can meet your backup and recovery needs. This book is currently the only resource that covers all of these tools in a single place.
1.2.4. You Want to Learn About Disk-Based Backup
If you haven't heard of disk-based backup or disk-to-disk-to-tape (D2D2T) backup, then it's time to
turn
off the digital video recorder (DVR) and pick up a trade magazine or two. (Of course, your DVR is nothing more than disk-based backup of your TV. And if you're occasionally making VHS tapes of your DVR shows, it's even a D2D2T system.) The use of disk in backup and recovery systems has exploded in the last few years, and it's really solving a lot of problems.
Chapter 9 covers backup hardware and goes into much more detail about why disks have become a very attractive backup target. Here is a quick summary of some of those reasons:
-
Cost
-
The biggest reason that disk has become such an attractive backup target is that the cost of disk has been dramatically reduced in the last few years. The cost of a reasonably priced disk array is now approximately the same price as a similarly
sized
tape library filled with media. When you consider some of the things you can do with disk, such as eliminating full backups and redundant files, disk becomes even less expensive.
-
Reliability
-
Unlike tapes, disks are closed systems that aren't susceptible to outside
contaminants
. In addition, the actual media of a hard drive is, well,
hard
when compared to a piece of tape media. The result is that an individual disk drive is
inherently
more reliable than a tape drive. Disk drives become even more reliable when you put them in a RAID array.
-
Flexibility
-
Generally speaking, tape drives can only go two speeds:
stop
and
very fast
. Yes, some tape drives support variable speeds. However, they can usually only slow down to about 40 percent of the rated speed of the drive. Disk drives, on the other hand, work at whatever speed you need them to go. If you need to go a few hundred megabytes per second, put a few drives in a RAID group, and blast away. Then if you need that same RAID
group
to write at 10 KB/s, go ahead. Unlike tape drives, disk drives have no problem writing slowly, then quickly, then slowly, then.... You get the picture. This makes disk a perfect match for unpredictable backup streams. Once all that random data has been written in a serial fashion on your disk device, the disks can easily stream backup data to tapeif that's what you want to do. Some people are foregoing that step altogether and replacing it with replication. Try doing that with a tape drive.
Disk-based backups are also an extremely economical way to bring completely automated backups to small and medium businesses (SMBs). While a large tape library can be very inexpensive (on a dollars-per-gigabyte basis) and very expandable, the same is not always true of smaller libraries aimed at the SMB market. The big challenge is expandability. The less expensive a tape library is, the less expandable it usually is. (There are always exceptions, of course.) By comparison, some of the completely automated open-source backup products mentioned in this book can be used with a single disk drive costing less than $100. If you need to expand beyond that, just buy another disk and add it to your volume manager. You can also buy RAID controllers that allow you to start with one disk and add more as your needs grow. You can use this method to expand from hundreds of gigabytes to many terabytes of capacity.
|
