لطفا منتظر باشید ...
Hack 54 Back Up the Metabase
There's more than one reason
for backing up the metabase, and there are different ways of doing it
too.
Instead of storing its configuration settings in the Windows Registry, like
most other services store their configuration settings, IIS stores
most of its settings in a file called the
metabase. On Windows 2000 (IIS 5), the metabase
is a binary file named MetaBase.bin,
found in the %SystemRoot%\system32\inetsrv
folder. Windows Server 2003 (IIS 6) uses XML as the format
for its configuration information, rather than the proprietary binary
format used by IIS 5. As a result, there are two metabase files in
IIS 6: the metabase proper (MetaBase.xml), where
configuration settings are stored, and an associated XML schema file
(MBSchema.xml) that defines the XML syntax of
the MetaBase.xml file. Because of the
differences between these two platforms, we'll have
to consider them separately when backing up IIS settings.
Why Back Up the Metabase?
Many IIS administrators don't realize that there are
two reasons for backing up the metabase and each reason requires a
different method for doing so. The most obvious reason is to prepare
for the eventuality of a disaster. Note that I said
eventuality instead of
possibility, because wise system administrators
know that it's only a matter of time before
something horrid happens. To prepare for such a disaster, you
certainly want to back up the metabase on your IIS machines, but
having a backup of the metabase alone isn't going to
be much help if the hard drive containing your boot volume is toast;
the proper functioning of the metabase depends on having access to
some encryption keys that are part of the System State on your
server. System State is a fancy phrase for a
collection of important configuration information that lets you
recover the predisaster state of your system after a massive failure
renders it unbootable. You'll find more information
about what's included in a server's
System State in [Hack #92] in
Chapter 10.
So, here's the point: if you back up the IIS
metabase without its associated System State, you
won't be able to recover your web server after a
disaster. Microsoft doesn't document clearly in
either their Windows help files or on their web site that, by
default, when you back up the System State information on a Windows
2000 or Windows Server 2003 machine, you also automatically back up
the metabasethat is, if you've left your
backup settings at their defaults. Let's dig a
little deeper.
Advanced Backup Settings
Hidden away in the Windows Backup utility is
a properties box called
Advanced Backup Options (Figure 6-1). To access
Advanced Backup Options, select the items you want to back up, click
Start Backup, and then click Advanced.
Figure 6-1. The Advanced Backup Options properties box in the Backup utility
When you choose to back up the server's System
State, the setting "Automatically backup System
Protected files with the System State" is selected
by default. This setting actually backs up the entire contents of the
%SystemRoot% folder and all its subfolders along
with the rest of the System State information on the server. Of
course, the inetsrv directory where the metabase
is found is part of this directory hierarchy, so the metabase gets
backed up along the way. So, if you want to back up the IIS metabase
for comprehensive recovery from a disaster, simply back up the System
State using Backup (or its command-line version,
ntbackup). Since the
"Automatically backup System Protected Files with
the System State" checkbox automatically adds
several hundred megabytes to the size of your System State backup, if
you're the kind of person who likes living
dangerously and you want to save on tape and speed up your backup,
you could deselect this checkbox. Naturally, it's
usually best to avoid cutting corners like this and leave the setting
checked.
Quick Backups
Preparing for that eventual disaster
isn't the only reason
for backing up the metabase. You should also make backup copies of
the metabase if you plan on tinkering with it, either using MetaEdit
(metaedit.exe)a tool in the Windows 2000
Server Resource Kit, used for editing the IIS 5 metabaseor a
text editor such as Notepad, which you can use to edit the XML
metabase of IIS 6 directly. The danger here is that indelicately
laying hands on the metabase might break something and render your
metabase unreadable to IIS, forcing you to restore before your WWW
Publishing Service starts again and users can access your web sites.
The syntax of the metabase is strict, and any untoward alterations
could cause a service to behave unpredictably at best, or just fail
altogether at worst. So, before you roll up your sleeves and start
fiddling with your metabase, it behooves you to make a quick backup.
You could back up the entire System State on your machine before
touching the metabase, but that's overkill. You
could use Backup to back up only the inetsrv
directory on your server, but there are faster and simpler
ways.
IIS 5
You can back up the metabase from the GUI by using Internet Services
Manager, the MMC console used for configuring and managing IIS.
Right-click on the node that represents your server and select
Backup/Restore Configuration to open a dialog box of the same name,
as shown in Figure 6-2. Click the
"Create backup..." button, type a
descriptive name for your backup, and click OK. Backups are stored in
the %SystemRoot%\System32\InetSrv\MetaBack
directory; to be extra careful, you can include this
directory in your regular tape backups.
Figure 6-2. Backing up the metabase
Restoring the metabase is just as straightforward: select the
metabase backup you want to restore and click Restore.
If you're using MetaEdit to editing the IIS 5
metabase, you're in luck; conveniently enough,
MetaEdit itself is capable of making quick metabase backups.
Before you start using MetaEdit, however,
be sure to download
the latest version of the tool from Microsoft's web
site. Interestingly, when you search the Microsoft Download Center
(http://www.microsoft.com/downloads/) for
metaedit, you only get Version 2.0 of the tool,
which is out of date. To obtain the latest version of the tool
(MetaEdit 2.2), see Microsoft Knowledge Base article 232068
(http://support.microsoft.com/default.aspx?scid=kb;en-us;232068),
which has a link to the installation package.
Once you download and install the self-extracting file, you have two
tools to play with: a Metabase Browser/Editor similar to Registry
Editor and a Metabase Consistency Checker designed to ensure the
syntax of the metabase remains consistent. Unfortunately, the
Consistency Checker isn't too useful, because it
won't repair certain types of mistakes you can make
with the Browser/Editor, such as entering illegal values for metabase
keys. So, just like when you edit the Registry directly,
you're on your own and in dangerous territory.
In fact, it's always a good idea to back up the
metabase periodically, even if you make changes to your metabase only
through the Internet Services Manager GUI. That way, if you make a
lot of configuration changes to IIS and discover your web
applications acting a mite odd, you can reverse those changes quickly
and easily by restoring the metabase from recent backup. In fact,
this might be the only way to return to a working IIS configuration
if you can't remember all the changes
you've made. So, regular metabase backups are a part
of good housekeeping on your IIS machines.
Backing up the metabase with MetaEdit is straightforward: simply open
MetaEdit (it's installed by default under
Administrative Tools) and select
Metabase
Backup/Restore from the menu. This opensthe same Configuration Backup/Restore dialog box (Figure 6-2) and saves backups in the same
MetaBack directory as before. GUI- and
MetaEdit-made backups are compatible, so you can back up using one
way and restore using the other if you prefer.
Remember that these quick backups of the metabase are designed only
to recover from a corrupt metabase or to restore the metabase to an
earlier working condition; you cannot use them to restore an IIS
machine from scratch; use System State for that. Also, note that a
metabase backup made on one machine cannot be restored to a different
machine, due to the differences in System State information between
the machines. There's a workaround for that too,
though: export the metabase instead of backing it up. Exporting saves
all or part of the metabase in a text file instead of in the
proprietary binary format used for metabase backups. Note that
exporting the metabase requires you use MetaEdit, because export
functionality is not included in Internet Services Manager for IIS 5.
Exporting the metabase is useful if you want to document the contents
of your metabase by printing it out. It's also
useful for copying web site configurations from one IIS machine to
another. For example, if you want to mirror a site on two machines,
simply export the metabase keys for the web site and then import the
export file into the second machine. But don't
forget to copy your site content as well; remember that the metabase
contains only IIS configuration information, not the content of your
web sites.
IIS 6
Metabase backups are even easier in IIS 6, because the functionality
is built right into
Internet Services Manager. In fact, in addition to allowing you to
back up the metabase manually, IIS 6 also automatically backs up the
metabase whenever configuration changes have been made.
Let's look at these automatic backups first.
IIS 6 automatically saves time-stamped (versioned) copies of the
metabase; these copies are called history files
and are saved in the %SystemRoot%\system32\intesrv\history
folder. History files are identified by two numbers: major
version and minor version. The major version number is incremented
whenever you stop and start IIS using the GUI or net stop
iisadmin on the command line, when IIS flushes the
in-memory metabase to disk, or when you manually save the IIS
configuration to disk. This provides a safety net, so you can recover
an earlier configuration if you've made a series of
changes and can't remember what they were, let alone
how to undo them. When a new major version history file is saved, IIS
includes a reference to this file in the MetaBase.xml
file itself.
Minor versions are somewhat different. IIS increments the minor
version number if you have edit-while-running
enabled and make modifications to the metabase while IIS is running.
Edit-while-running is a new feature of IIS 6
that allows you to edit the metabase directly while Iisadmin and
other IIS services are still running. Whenever the major version
number is incremented, the minor version number is reset to 0.
If you plan to use the new history feature of IIS
6it's enabled by defaultyou will
probably want to modify the history settings to suit your needs. The
default history settings save a maximum of 10 history files before
overwriting the oldest file. This might not be enough history if you
plan to edit the metabase extensively; you might want to increase
this number to 20, 30, or even 100. Make sure you have sufficient
disk space for all these files, however; if IIS
can't create a new history file due to insufficient
disk space, it will automatically shut down without warning or
explanation.
To change the maximum number of history files IIS should save,
you'll have to modify a metabase setting directly;
there's no way to do it from the GUI. The property
you need to change is called MaxHistoryFiles and
it's located in the
<IIsComputer> section (if
you're navigating the metabase by its key hierarchy)
or the LM location (if you're
navigating by location hierarchy) of the XML code. The metabase can
be a confusing place; you might take a gander at [Hack #56] for guidance.
|
IIS 6 also lets you manually back up the metabase and export portions
to a text file, similar to what we did in IIS 5. The main difference
is that in IIS 6 export functionality is built directly into the GUI,
so you no longer need the old MetaEdit tool for exporting. In fact,
you can't use MetaEdit with IIS 6 because of the
metabase's format change from binary to XML.
GUI differences between IIS 5 and IIS 6
Backing up the metabase from the GUI is done the
same way as it was in IIS 5, with a couple of important differences.
First, an initial metabase backup is automatically performed once you
install IIS on your machine (to reduce the attack surface of your
machine, Windows Server 2003 no longer installs IIS by default). This
initial backup consists of two backup files: an
*.MD0 file that contains a backup of
MetaBase.xml (the metabase proper) and an
*.SC0 file that holds a backup of
MBScehma.xml (the XML schema that defines the
syntax of MetaBase.xml). Note that in IIS 5 the
schema is included as part of the single metabase.bin
file, though in MetaEdit the configuration
(LM) and schema (Schema)
portions of the metabase are displayed as two separate nodes. In
other words, every time you back up the metabase in IIS 6, you back
up both the configuration file and the schema.
Here's another difference. In IIS 5, using Internet
Services Manager, you right-click on the server node and select
Backup/Restore Configuration. To do this in IIS 6, however, you
right-click on the server node and select All Tasks
Backup/Restore Configuration. This is just one example of the
unnecessary, minor changes in Windows Server 2003 that cause
frustration for administrators who are used to working with Windows
2000.
You can also now use a password to encrypt metabase backups. An
encrypted metabase backup can be restored to a different IIS machine,
which gives you a way to clone the IIS configuration of one machine
and copy it to another. This was not possible in IIS 5; you could
restore a metabase backup only to the same machine and only if you
hadn't rebuilt the machine onto new hardware after a
disaster. This is one of many good reasons to upgrade your web
servers to Windows Server 2003, even if you choose to keep your
domain controllers running Windows 2000. Just don't
forget the password you use to encrypt your metabase or you
won't be able to restore from the saved backup.
Finally, IIS 6 also includes some scripts that can be used to back up
and restore the metabase from the command line. For more information
about these scripts and what they can and cannot do, see
[Hack #59].
