Last year, I did a presentation in the IIS Webcast Series called “Disaster Recovery and IIS 6.0: Metabase backups in a Nutshell.” The main reason I put that webcast together is to ensure that customers had prescriptive guidance on the “what” & “how” of doing backups of IIS servers.
The key understanding is that IIS is a part of the operating systems and has many, many dependencies on that platform. A person tasked with understanding a organizations backup strategy cannot overlook this simple fact. This webcast spent some time discussing backups but did so by looking at three major pieces:
- IIS Web Content (i.e. inetpub\wwwroot)
- IIS Configuration (i.e. metabase.xml)
- Operating System Components (i.e. Certificates, COM+, etc.)
During this presentation, I talked about and delivered a sample script that customers can use to back up these pieces of information. I also explained the how & why of each part. I felt that I could summarize here -
IIS Web Content
This is the single most important asset a company has. The intellectual property of the site is completely built around the content that host the companies website. The content, though, goes beyond just web pages, but images, documents, privacy information, etc. In the world of Web Farms, it is important to ensure that everything is in sync. To facilitate a backup strategy, a step that could be taken would to centralized content on a UNC Share. This feature was enhanced significantly in IIS 6.0. This certainly makes backups easy, but there are architectural understandings that need to be known before jumping into UNC scenarios.
Thus, UNC is good for backups in web farm scenarios. However, hosting content locally does not make it impossible. There are several good utilities out there to copy data, but I stick with xcopy as it does a lot of the greatness I was looking for.
You cannot over-emphasize how important backing up the metabase is. In my early days in PSS (circa 2000), I was stunned at the amount of IIS 5.0 customers that did not have a backup of the metabase. The task was fairly simple as it was a single file, metabase.bin, but was hidden in the IIS Manager (UI). To do it (same for IIS 6.0 except choose Web Sites node, not server), right-click on the server, choose All Tasks, and select Backup\Restore option. This will create a backup in the %systemroot%\system32\inetsrv\metaback directory.
In IIS 6.0, we built a nice scriptable command-line utility called iisback.vbs. This can be called throughout any script, such as prior to modifying the configuration, and after if it succeeds. The biggest problem that plagues IT professionals today when backing up IIS is the lack of understanding of “SecureProperties.” There are certain pieces of data that is stored in the metabase that is considered protected, such as passwords, etc. We store the passwords for the anonymous user account (Metabase Property: AnonymousUserPass) and process identities (Metabase Property: WamUserPass). These are not the only properties, but possibly the most sensitive since you can obtain credentials for logging on the server. To protect against this, this data is protected via a hash using the Operating System’s cryptography. This security causes confusion. In short, each installation of Windows has a unique key that can be called for hashing and protection of data. This unique key is lost when machines are “rebuilt” or destroyed by a disaster. A complete, and this does mean complete, backup can be used to restore this functionality using NTBackup or say Veritas’s BackupExec. This is risky though. The overall suggestion for quick & dirty restores is to simply understand how to backup the system and remove this uniqueness. This feature is natively available in the IIS 6.0 user interface but also in iisback.vbs. In my sample script below, I use this feature of providing a password for the backup and remove any use of the system’s cryptography.
There is nothing worse than getting a call\email from a customer who did all of the above (backup content & config) and has one single problem. I am back up and running but none of my Secure Socket Layer (SSL) sites are working. The answer is not a pretty one but one that happens way too often — they failed to remember this in their disaster planning. It is important that certificates are backed up very regularly as they can become corrupt, etc. with very little notice.
Using the Certificates Snap-in (http://support.microsoft.com/kb/q232136/), you can back up the certificates one by one. However, we shipped a cool tool as part of the IIS 6.0 Resource Kit Tools called IIsCertDeploy.vbs. This is a very useful and powerful tool that allows you manage, backup, and restore your certificates. In my script below, I use this tool to export the certificate to a .pfx file that can later be restored in case of failure.
With the evolution of the old-time WinDNA architecture, a key aspect of web development came from the creation of a set of components that housed the business logic. The content covered in part I of this piece would only reference these objects that are essentially a component dll that implements logic and communication to the backend databases. There is no less of a sinking feeling of getting everything restored and firing through your application and getting the horrific error:
This means nothing more than you are missing the component. In this case, you have to rebuild the component services application to ensure the settings are the same, etc. Do you have this documented? If not, there is a means of creating a COM+ MSI that you can later use to restore these components — very cool!
REM My IIS Backup File
REM Get SSL Certificates
iiscertdeploy.vbs -e d:\webbackups\certs\site1.pfx -i w3svc/1 -p site1pwd -q On
iiscertdeploy.vbs -e d:\webbackups\certs\Site2.pfx -i w3svc/1856130344 -p site1856130344pwd -q On
REM Backup IIS Metadata
iisback /backup /b MyMetaBackup /e BackupPass /overwrite
xcopy %windir%\system32\inetsrv\metaback\MyMeta*.* d:\webbackups\metadata /Y
REM Copy COM MSI File(s)
xcopy d:\foo.msi d:\webbackups\COM+
REM Copy all Content, Certs, Metadata, and Content to UNC Share
net use o: \\server\mybackups
xcopy /o /x /e /h /y /c d:\WEBBACKUPS\metadata\*.* o:\Metadata\
xcopy /o /x /e /h /y /c d:\inetpub\wwwroot\*.* o:\content\
xcopy /o /x /e /h /y /c d:\WEBBACKUPS\COM+\*.* o:\COM+\
xcopy /o /x /e /h /y /c d:\WEBBACKUPS\certs\*.* o:\certs\
net use o: /delete /Y
Recently, I wrote up a quick article that was published in Technet Magazine called Plan Ahead to save your Web. It is similar in nature but in the end game simply says - be prepared, be very prepared. Happy Backups...