Backup and Recovery Survival Guide.pdf

(469 KB) Pobierz
Neverfail.ebook.0607
Backup
IT Pro SERIES
and
Recovery
Survival Guide
Sponsored by
104590041.004.png 104590041.005.png
i
104590041.006.png 104590041.007.png
ii Backup and Recovery Survival Guide
Restoring and Renaming a Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Restoring WITH STANDBY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Partial Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
104590041.001.png
1
Chapter 1
Disaster Prevention:
Preparing for the Worst
Use these best practices to help your system survive
By Kalen Delaney
Many people break the subject of high availability into two parts—disaster prevention and disaster
recovery—and discuss the topic as if every step in a high-availability solution fits neatly into one
arena or the other. However, while planning for this chapter and trying to determine which activities
constitute disaster prevention and which constitute disaster recovery, we found that the line between
the two isn’t a neat one. We also realized that to distinguish between disaster prevention and disaster
recovery, you need a clear definition of “disaster” for your organization.
If you define disaster as something outside the technical realm, such as a flood or earthquake,
then preventing disaster isn’t possible, at least for the IT staff. In such a case, you’d focus on disaster
preparedness. But if you concentrate on disasters directly involving technology, drawing the line
between prevention and recovery is difficult. For example, if you define the loss of your SQL Server
as a disaster, you might implement a clustered SQL Server environment so that a SQL Server on
another machine automatically takes over for the failed server. That failover lets you recover from the
disaster of losing your primary SQL Server. However, most people think of a clustering solution as
disaster prevention.
Similarly, most people think of backup-and-restore strategies as disaster recovery. However, if
you define a disaster as a loss of data and if a complete restore from backups prevents data loss
because of a disastrous event, did the disaster occur, or did you prevent it? Because you need good
backups to perform a complete restore and you have to perform backups before a disaster occurs,
you can think of an effective backup strategy as a disaster-prevention technique.
So what exactly constitutes a disaster? For the purpose of this article, a disaster is a loss of
production data or downtime that causes a loss of productivity. For your own purposes, if you think
a particular event is a disaster for your business, it’s a disaster.
When we distinguish between disaster prevention and disaster recovery, we suggest that
prevention is what you can do before something happens and recovery is what you do after. The
“something” could be an event that’s preventable, such as multiple disk failures, or it could be an
event that’s unpreventable, such as an earthquake. In the latter case, you don’t look for ways to
prevent the event; you look for ways to be prepared and prevent the event from causing an
unacceptable loss of data or productivity.
Brought to you by Neverfail and Windows IT Pro eBooks
104590041.002.png
2 Backup and Recovery Survival Guide
Strategies for Disaster Prevention
Dealing with disaster takes many forms, but I’ve come up with my top five best practices for disaster
prevention. Adhering to these practices will help you plan and implement a disaster-prevention plan
for your organization.
Make a list of possible disasters. No matter how ridiculous or improbable an event might seem, if
it could cause downtime or loss of data, list it and think about what you would do if it happened.
Some improbable examples might be a meteor demolishing your entire site or the entire IT staff
coming down with food poisoning at the company picnic. I always put this step first because
keeping these possibilities in mind will help you decide how to carry out each of the other strategies
I suggest.
After planning for—or at least considering—the worst possible disasters and determining what
steps you can take to minimize the risk, evaluate the cost-benefit ratio of taking those steps. If
protecting your data against a catastrophic but low-probability event—such as a meteor strike—
would cost a lot, you might decide to take the risk and not provide specific protection for that event.
Document your decision so that coworkers and successors know that you at least considered the
possibility. However, you might discover that protecting your data against some low-probability
events doesn’t cost much. For example, you might already store database backups in a location
across town, but what would happen if the meteor destroyed the entire town? If your company
already ships regular backups for another system or application to another town, the cost of adding
tapes of your SQL Server backups to that shipment might be negligible. So although the likelihood of
a meteor strike might be small, the cost to save your data if that unlikely event occurs might also be
small.
Also, be sure to plan for the infamous “user error” in your list of possible disasters. User errors
can be the most difficult disasters to prevent and can take the longest to recover from. Users commit
such errors as accidentally deleting data rows, tables, or an entire database. SQL Server makes it easy
for users with high levels of privilege to do lots of damage. Although referential integrity, schema
binding, and triggers can help prevent inadvertent deleting of rows or dropping of tables, SQL Server
provides little protection against dropping an entire database. Unlike in earlier SQL Server releases, in
which the DROP DATABASE command didn’t actually remove the physical files from the file system,
when you drop a database in SQL Server 2000 or 7.0, SQL Server deletes the disk files holding the
data, so the database is really gone.
Users can also create havoc by implementing the wrong procedure. Many procedures have
similar names, and if a typing error causes a user or an application to call the wrong procedure, you
might not notice the damage for some time. You’ll lose more time while you track down the
problem, and even more time before you start correcting the problem and undoing the damage.
Note that ineffective security can foster user errors. Weak or nonexistent passwords, along with
allowing too many users too much privilege, can compromise system and data integrity. Accidental
deletions are also more likely when users have higher permission levels than they need.
Brought to you by Neverfail and Windows IT Pro eBooks
104590041.003.png

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin