データベースの保守について調べてみる
SERVER
Microsoft SQL Server 7.0
2004/07/06 の時点では 2000 というバージョンが最新となっていますけど、今回は Microsoft 社のデータベースサーバ Microsoft SQL Server 7.0 のお話です。
データベースサーバというものは、正常に稼動していればデータも目に見えるし、何かと便利なのですけど。ひとたび機嫌を損ねてしまうと少し厄介なこととなります。バックアップをしていなければそのままデータが闇に消えてしまう危険性が非常に高いでしょうし、たとえバックアップを取っていたとしても、正しく取っていたつもりでもそれが間違っていたならば、壊れたときには後の祭りです。
Microsoft SQL Server 7.0 は、バックアップ機能も備わっていて、簡単な選択肢を選ぶだけでバックアップを自動的にしてくれるように設定することが出来るのですけど、果たしてそれが正しいデータを収集してくれているのか、そもそも障害時にはどういった方法にて復元作業を行えばいいのか。そのあたりの把握が非常におろそかだったので、改めて調べてみることにしました。
データベース保守計画
Microsoft SQL Server 7.0 には "データベース保守計画" という、データベースを定期的に管理する機能が備わっています。
どのデータベースを保守するか、インデックスの再構成や整合性の確認、データベース全体とトランザクションログのバックアップ、そういったことを個別にスケジュールして自動的に行うことが出来るようになっています。
設定方法も簡単で、Microsoft SQL Server の Enterprise Manager から該当するデータベースサーバを選択して、「管理」 の中の 「データベース保守計画」 で、ウィザードを使って登録することが出来ます。
設定自体が簡単なので余計にすっかり安心してしまうのですけど、これで本当に復旧することが出来るのか、どういった手順で復元することになるのか。また機器の故障以外にも、これらのバックアップ、特にトランザクションログを有効活用できるのか、いろいろと気になりだしてみたので、今回の本題へと続くのでした。
バックアップに関する調査：種類
復元についてを調べていたら、バックアップの種類についても少し細かく知ることができたので、まずはそれについて触れてみようと思います。
フルバックアップ
フルバックアップは、その時点でのデータベースをまるごとバックアップする方法です。
各オブジェクトやデータに加えて、コミットされていないトランザクションログも、バックアップの対象になるとの事です。確実で簡単なバックアップ方法ながら、大規模なデータベースを取り扱っている場合は容量がかさんだり、時間がかかったりしてしまうとのこと。
もっとも基本的なバックアップ方法で、その他のバックアップ方法を採用する場合にも、まずはこのフルバックアップを行う必要があります。
差分バックアップ
差分バックアップは、前回のフルバックアップ以降に更新されたデータのみをバックアップする方法です。
変更された部分のみをバックアップするため、容量や作業時間の短縮につながります。対象となるデータは前回のフルバックアップ以降のデータ全てとなるそうです。使い方としては、フルバックアップを取る間に、適度に差分バックアップを挟み、必要とあればさらにトランザクションバックアップをはさむ感じになるようです。
トランザクションバックアップ
トランザクションバックアップは、データベース操作の際に発生したトランザクションのログをバックアップする方法です。
前回のフルバックアップまたは差分バックアップ、またはトランザクションバックアップ以降のトランザクションがバックアップの対象となるそうです。使い方としては、フルバックアップと、場合によっては差分バックアップとを行い、さらに細かい間隔でトランザクションバックアップを行うという感じになるようです。
バックアップに関する調査：方法
Microsoft SQL Server 7.0 は Enterprise Manager にて簡単にバックアップすることが出来るようになっています。
手順も特には難しいところはないので勘でも問題なく進められるのですけど、気になることとしては、「バックアップ」 と 「データベース保守計画」 の 2 箇所でバックアップの設定が出来るような感じです。
ただこれらは互いに独立しているようで、また少し勝手が違うので、いったいどちらでバックアップすればいいのかが判断しづらいのですけど、名前からも察せるように、「バックアップ」 の方は本当にバックアップ専門で、「データベース保守計画」 の方は最適化などの作業のほかにバックアップも行うことが出来るというような感じのようです。
”バックアップ”
「バックアップ」 の方は、バックアップデバイスというのを定義した上でそこへバックアップするのが主体のようです。
バックアップデバイスはあらかじめ登録する必要があり、登録するとバックアップデバイス名とそのデバイスを保存するファイルとが対応付けられたデータが master データベースの sysdevices テーブルに登録されます。そしてこのデバイスを指定してバックアップのスケジューリングを行えばいいようです。
また、このようにバックアップデバイスを宣言しなくても、ファイル名を指定してバックアップを行うことも出来るようです。
バックアップデバイスはバックアップのスケジューリングを行う際に使用し、ひとつのファイルを追記したり上書きしたりという形で繰り返し利用するのだとか。そしてファイル名を指定するほうは、そのファイルごとに１回限りのバックアップとして、何か大きめな作業をする前などのちょっとしたバックアップに使用するとのことです。
この画面では登録されているバックアップデバイスの一覧だけが表示され、実際にどんなバックアップスケジュールが設定されているかが確認できなくて不安だったのですけど、調べてみると SQL Server エージェントの 「ジョブ」 を見ることで確認することができました。
”データベース保守計画”
データベース保守計画では、保守の一環としてデータベースのバックアップ機能が備わっているようです。
バックアップは指定したディレクトリに、自動的に適切な名前が付けられたファイルとして保存されて行きます。期間を指定してそれよりも古いファイルは削除するようにも設定できるなど、使い勝手がよさそうな感じです。ただし、どうやら差分バックアップは出来なそうな感じでした。
バックアップとあわせて、最適化や整合性のチェックなども一緒にスケジュールすることが出来ます。
登録されている保守計画は、画面ですぐに確認したり再調整したりすることが出来るのでなんとなく安心です。実際にはこちらも、”バックアップ” のときと同様に SQL Server エージェントの 「ジョブ」 にてスケジュールが管理されていることには変わりないみたいなのですけどね。
データベースをバックアップしてみる
データベースのバックアップ方法は、”全体” と ”差分” と ”トランザクションログ” の意味が解っていれば設定自体はさほど難しくないと思うので、ここではそれ以外に注意すべきことを挙げてみようと思います。
復元したいデータベースのほかに、バックアップしておくべきデータベースがいくつかあります。その中で一番重要となるのが master データベースです。このデータベースには、Microsoft SQL Server にどんなデータベースが登録されているかとか、ログイン情報とか、リンクサーバとか、いろいろなシステム関連のデータが保存されています。
ですので何か障害があったときに治せるように、新しくデータベースを作成したりした場合には特に注意して、バックアップしておく必要があるようです。このデータベースを復元できない場合は、sp_attach_db ストアドプロシージャを使ってデータベースファイルを認識させる必要があったり、そのほかの必要なものを登録しなおす必要があります。
master データベースが損傷を受けてしまって、かつ、バックアップをとっていない場合は、SQL Server が無事ならば binn フォルダ内にある rebuildm.exe を実行して master データベースを初期状態に戻すか、SQL Server 自体が損傷しているならば再インストールしなおす、などの対応も必要となります。
master データベースのほかに必要となりうるのが msdb データベースです。
これもけっこう重要で、バックアップのスケジュールなどのタスクや、バックアップ履歴、レプリケーション関連の情報の一部などを担っているそうです。ですのでこれも master 同様に注意してバックアップをとるのがよさそうです。こちらのバックアップが存在しない場合は、タスクを登録しなおすなどの再設定を行う必要が出てきて、何かと大変そうです。
また、レプリケーションを行っている場合には、distribution データベースも重要になってくるとの事でした。
それ以外のデータベースでは、新規にデータベースを作成した場合の雛形となる model データベースや、SQL Server が作業用に使用する tempdb などがあります。model の方は変更する機会も少ないでしょうから変更のたびにバックアップを取っておけばよさそうです。tempdb の方は、SQL Server 起動時にデータが初期化されるとのことですので、バックアップはいらないか、または念のため最初に１回だけバックアップしておく程度でよさそうです。
データベースを復元してみる
まっさらな状態へ master を復元してみる
復元してみるにも既に稼働中のデータベースに障害を発生させてみるのはなかなか勇気がいるので、バックアップをつかって、新規 SQL Server 7.0 へ既存の環境を復元してみることにします。バックアップは今まで "データベース保守計画" で定期的に取得していたフルバックアップとトランザクションログバックアップを使用します。
新規に用意した Windows 2000 Professional の PC に、Microsoft SQL Server 7.0 Developer Edition および Service Pack 4 をインストールして…、って、復旧の際にバージョンや Service Pack ってあわせないといけないものなのでしょうか…。
本来は完全に一致していたほうが良いのでしょうけど、今回は行き当たりばったりでやってみることにします。
なお、どの Service Pack が充てられている状態かは、SQL Server のバージョン番号によって、一応は知ることが出来るようになっているようです。
バージョン番号は、Enterprise Manager をつかって該当サーバのプロパティから 「製品バージョン」 を参照したり、ディフォルトでは C:\MSSQL7\Log\ フォルダに保存されている ERRORLOG ファイルの先頭行あたりを見ることで確認できます。
Microsoft SQL Server 7.00 - 7.00.623 SQL Server 7.0 Microsoft SQL Server 7.00 - 7.00.699 SQL Server 7.0 SP1 Microsoft SQL Server 7.00 - 7.00.842 SQL Server 7.0 SP2 Microsoft SQL Server 7.00 - 7.00.996 SQL Server 7.0 SP3 Microsoft SQL Server 2000 - 8.00.194 SQL Server 2000 Microsoft SQL Server 2000 - 8.00.384 SQL Server 2000 SP1 Microsoft SQL Server 2000 - 8.00.534 SQL Server 2000 SP2 Microsoft SQL Server 7.00 - 7.00.623 MSDE Microsoft SQL Server 7.00 - 7.00.699 MSDE SP1 Microsoft SQL Server 7.00 - 7.00.842 MSDE SP2 Microsoft SQL Server 7.00 - 7.00.961 MSDE SP3 Microsoft SQL Server 2000 - 8.00.194 MSDE2000 Microsoft SQL Server 2000 - 8.00.384 MSDE2000 SP1 Microsoft SQL Server 2000 - 8.00.534 MSDE2000 SP2 Microsoft SQL Server 7.0 Developer Edition の Desktop Edition をインストールし終えた状態で、バージョン番号は 7.00.623 となりました。続いて Microsoft SQL Server 7.0 Service Pack 3 を充ててみると、7.00.961 になりました。バックアップをとった側の SQL Server も確認してみたのですけど、Edition こそ違うもののバージョンは 7.00.961 と同一となったようでした。
また、データベースを復元する場合は、シングルユーザーモードにて SQL Server を起動する必要があるそうです。起動の仕方は、Enterprise Manager を起動して目的のサーバのプロパティを表示し、「起動時のパラメータ」 として -m を追加します。そうしたらいったん SQL Server を停止させて再び起動させてあげます。
…、これでシングルユーザモードになっているのかいまひとつ実感がないのですけど。
なのでためしに他のコンピュータからも同時に接続してみることにしました。別の PC の Enterprise Manager を起動して、そこへ今回の復旧実験の対象となる PC を登録して接続…。すると見事に接続が拒否されました。もっとも、シングルユーザーモードだからという通知はなかったのですけど、ためしにまた -m をはずして再起動してみると、ちゃんと接続できるようになったのでどうやら間違いないようです。
その後に知ったのですけど、管理ツールのイベントビュアを見ると、その中に、シングルユーザーモードで起動したことを示すログが見つかりました。また、SQL Server 起動時にバージョン番号も出力されていました。
そしていよいよ、データベースの復元実験です。
バックアップデータを DVD-R に焼いていざ挑戦…、なのですけど、どうやら素直には行かないようです。とりあえず Enterprise Manager を起動して master データベースを選択し、全てのタスクから 「データベースの復元」 を選んでみたのですけど、バックアップファイルを指定するというところまでたどり着けませんでした。
新規のサーバなので当然バックアップ履歴などは存在しないわけで、「データベース」 の復元で master こそ指定できるものの肝心のバックアップがないため不可。「ファイルグループまたはファイル」 の復元というのはそのデータベースを構成するファイルを直す感じのような気がするので違いそうですし。「デバイスから」 を選んでもデバイス選択で CD-ROM ドライブを選べず、また無理やりパスを指定しても、エラーとなってしまいました。
バックアップファイルをそのまま指定するのはなんだかややこしそうだけれど、バックアップデバイスを登録するのはそれほど難しくはなさそう。そう思ったので、とりあえず一度、バックアップデバイスからのバックアップを行ってみようと思います。
まずは、バックアップもとのサーバへ、TEST という名前ででもバックアップデバイスを登録します。そしてそこへ、Master データベースのフルバックアップを行ってみました。それを復元したいサーバへコピーしたら、そのファイルをバックアップデバイスとして登録してみます。
バックアップデバイスの登録でそのファイルを指定してみると、既に存在するけれど良いか聞かれるので 「はい」 を選択してそのまま登録します。登録完了後、内容を見てみると、そのデバイス内にバックアップがちゃんと存在していました。
ではこれを使って復元できるかを実験してみます。
master データベースの 「全てのタスク」 から、データベースの復元を選択します。そして 「デバイスから」 を選んで、先ほど登録したバックアップデバイス TEST を選択します。そしてバックアップセットの復元を、"データベース - 全体" として、[OK] を押します。
すると、さほど待たされることもなく、復元を知らせるダイアログボックスが画面に表示されました。× 印が付いていてちょっとびっくりしたのですけど、内容を読んでみると master データベースが正常に復元され、SQL Server を再起動しているとのことでした。
これで復元完了かと思って、SQL Server へ再接続しようとしてみたところ、サーバが存在しないかアクセス拒否とのことで、接続エラーとなってしまいました。
復元によって接続時に使用するパスワードが変わったのかとも思ったのですけど、どうやらそうではない様子。サービスマネージャを使用して何度か起動を試みてみるも、開始ボタンを押しても、しばらく待たされた後にエラーを知らされることなくまた開始ボタンが押せるように、つまりは起動しなくなりました。
念のためサーバを再起動してみましたが状況は変わりませんでした。
イベントビュアに何か記録が残っていないかを調べてみたところ、model データベースを開くことができないとの通知がありました。このデータベースは、新規にデータベースを作成するときにテンプレートとして使用されるものだったと思います。このデータベースを構成するファイルが、指定されたパスに見つからないとのことでエラーとなっている様子。その指定されているパスはバックアップを取ったサーバで構成していたパスで通知されていました。
master データベースを復旧しておかしくなった以上、model データベースの格納先は master データベース内に記録されている可能性が高そうだったのですけど、念のためどこかで変更できる箇所はないか調べてみました。
けれど、Enterprise Manager ではそもそもサーバのプロパティを見ることが出来ないし、レジストリを見ても master データベースの位置のみが記録されているようで、それ以外の部分については手が出せない感じでした。
とりあえずそのドライブが存在していれば何か変わるかと思い、ディスクドライブをひとつ、該当するドライブ名に変更してみました。けれどただドライブを用意した程度では、素直に起動してくれる気配はありませんでした。なので DATA フォルダを作成したのですけどそれでも駄目、空の model.mdf ファイルを作成してみても駄目でした。
それならばと、C:\MSSQL7\DATA\ フォルダの中にあった model.mdf と modellog.ldf ファイルをそのまま持ってきたところ、無事起動することが出来ました。そして同一フォルダ内には TEMPDB.MDF と TEMPLOG.LDF ファイルが自動的に生成されました。この感じですと、一時利用の tempdb に関しては、バックアップを取っていなくても大丈夫そうですね。
そして接続してみると、master の復元によって sa のパスワードが変わってしまったのでその辺りを調整しないといけませんでしたけど、それ以外は問題なくアクセスすることが出来ました。
そしてデータベースの一覧を表示してみると、 master, model, tempdb は黄色で表示されていて、それ以外のデータベースは、名前はしっかりと表示されているものの、灰色での表示となっていましたので、とりあえずは無事、master については復旧できたことになりそうです。
他のデータベースを復元してみる
それでは続いて別のデータベースを復旧しようかと思ったのですけど、「データベースの復旧」 を選んでみたところ、msdb が開けなかったとしてエラーが何回か表示されました。
そのあと、復旧ウィザード自体は動いてくれたのですけどね。そういえば msdb にはバックアップの履歴などが保持されているとのことだったので、まずはこれを復旧するのがよさそうです。
msdb について、簡単に復旧できれば良いのですけど、まだバックアップの履歴がない以上、master の時とほぼ同様の条件です。またバックアップデバイスにフルバックアップを取ってくれば良いのでしょうけど、今回はそれがなかったとしてみます。実際に今回の事始の時には、バックアップデバイスは使用せずに、保守計画によってフォルダへのバックアップしかしていなかったので。
とりあえず CD-ROM が指定できなかったので、今度は msdb のフルバックアップファイルをハードディスクにコピーしてから、復元ウィザードを起動してみます。そして、「デバイスから」 の復元としてハードディスク上にコピーしたバックアップファイル (*.BAK) を指定します。
そして内容を見てみたところ、ちゃんとバックアップセットとしてデータが保存されていることが確認できました。まさにバックアップデバイスを指定したときと同じような感じです。
これは上手く行くかと思い、さっそく [OK] を押してみたところ、エラーが発生してしまいました。なんでも、シングルユーザーモードのときは master 以外のデータベースを復元することが出来ないのだとか。となれば、起動オプションにつけていた -m を消して、もう一度 SQL Server を起動しなおしてみることにします。
通常のモードで起動して改めて復旧なのですけど、そういえば DBO 専用などとしておくのが良いとのことだったので、まずはそれを行っておくことにしました。が、正常に動作していない灰色表示のデータベースについてはプロパティを表示することが出来ず、よって DBO 専用にもすることが出来ませんでした。
もっとも利用できる状態にはないわけで、これで当然のことなのかも知れないのですけどね。ですのでそのまま、master のときのように復元処理を行ってみました。
すると、またしてもエラーとなりました。今度は、デバイスまたはファイルが既に存在しているとのことでした。みたところ msdb を構成するファイルはなさそうな気がするのですけどね。
念のため master データベース内の sysdatabases テーブルを参照してみましたが、msdb を構成するファイルはやはり存在していないようです。ともあれ指示の通り、オプションの "既存のデータベース上に強制的に復元" にチェックを入れてもう一度挑戦してみることにしました。
すると今度は正常終了です。無事、msdb データベースが参照できるようになったと同時に、データベースの復元ウィザードにもしっかりとログが表示されるようになりました。
こうなれば、後の復元はとても簡単そうです。
バックアップセットの保存されているパスに注意する必要がありますけど、履歴に記録されているパスと、バックアップとが一致するように配置した上で、ウィザードの通りに復元処理を行ってみます。
今回は CD-ROM ドライブのドライブ文字を変更するだけで条件を満たすことができました。そうでない場合は、該当するドライブにバックアップファイルをコピーするなどの方法が必要になりそうです。その辺りの状態が整ったら、いよいよ復元です。
「データベースとして復元」 にて復元したいデータベースを指定して、パラメータにてそのデータベースのバックアップを選択、それ以外はとりあえずディフォルトの設定にて復元処理を開始してみました。
ところがまたエラーです。今度は、バックアップファイルはセクタ辺り 512 バイトで初期化されていて現在のデバイスは 2048 なので駄目だとのこと…。うーん、なんでそのような理由で拒否されるのか良くわからないのですけど、とりあえず DVD-R から直接復元するなとのことなのでしょうか。
なのでまたディスクを追加してパスを一致させようかとも思ったのですけど、そうやすやすとディスクを増やすなんて出来ないことも多いですよね。なのでパス情報を変更できないか調べてみることにしました。調べるといっても単純に、msdb データベース内のそれらしいテーブルを参照するだけなのですけど。
そうしてみたところ、backupmediafamily テーブルの physical_device_name という項目が、それに該当するようでした。
なのでさっそく、ここの部分のパスを今回の環境に適したものに書き換えてみることにしました。書き換えも、寮が多いとなかなか面倒ですね。VBScript などで一括してしまえば楽なのでしょうけど、今回はとりあえず一つ一つ手で変更してみました。
そしてもう一度復元処理を行ってみます。復元もとの指定がしっかりと変わっていることを確認したら、[OK] を押して復元開始。今回もデバイスが存在しているとのことだったので、オプションで上書きする指示を行いました。
そして復元を行ってみたところ、復元処理が終わったかと思われた頃に、そのデータベースの読み取りが出来ないとのエラーが表示されてしまいました。いわゆる EOF に到達してしまったとのことです。
もう一度データベースの復元ウィザードを起動してみると、最初の方のバックアップセットにはチェックが入っていないものの、最後の方のいくつかのトランザクションログが復元対象としてマークされていました。どうやらこの辺りでエラーが発生してしまったようです。
とりあえずもう一度 [OK] を押してみると、再びまた復元処理が始まりました。そしてしばらくすると、今度は正常に完了し、データベースが利用可能な状態となりました。
msdb にないバックアップも復元する
さて msdb の重要さを良く知らないままバックアップしていたせいともいうのですけど、今回、msdb に記録されているよりも先にとっておいたバックアップファイルがありました。
ですのでこれを手動で充ててみる、というのをやってみようと思います。復元ウィザードをみると、05/31 が最終トランザクションログのバックアップだったので、それ以降を順次充ててみます。
その次のバックアップは、06/03 のトランザクションログとのこと。
ですので復元ウィザードを開いて、そのファイル *_tlog_200406030500.TRN をデバイスとして指定します。そして一度内容を確認すると、バックアップセットの種類が自動的にトランザクションログとして認識されるので、そのまま [OK] を押します。 ここで異なる復元方法を選ぶとエラーとなります。
これで簡単に復元できるかと思ったら…、またしてもエラーが発生しました。以前の復元にて WITH_NORECOVERY か WITH_STANDBY が指定されていなかったとのことです。最後のステップ以外の全てのステップでこれらを指定して復元シーケンスを再起動せよ、とのことでした。
よくわからないので調べてみたところ、オプションにある次の選択肢を適切に指定してある必要があるとのことでした。
Recovery データベースは操作可能状態。別のトランザクションログの復元は不可。 NoRecovery データベースは操作不可能状態。別のトランザクションログの復元は可能。 Standby データベースは読み取り専用。別のトランザクションログの復元は可能。 以前の復元ではこの辺りを特に気にせずに "Recovery" を指定していたために、今回のエラーが出たような感じがします。きっとウィザードはこの辺りを調整してくれて、フルバックアップ以後、最後のトランザクションが適用されるまでは "NoRecovery" として、最後だけ "Recovery" としてくれていたのでしょう。
復元シーケンスを再起動せよ、というのはおそらく、もう一度復元ウィザードを使って半自動で復元せよとのことでしょうから、とりあえずもう一回それをやってみることにします。
データベースの復元にて、フルバックアップから始まるバックアップセットにチェックが入っていることを確認し、オプションにて 「既存のデータベース上に強制的に復元」 と 「データベースを操作不可状態。別のトランザクションログの復元は可能」 にチェックを入れて、改めて復元を行いました。
相変わらず一度はエラーが出ますけど、それでももう一度復元ウィザードを起動しなおして適用すれば完了です。手続きが終わっても灰色のままでびっくりしたのですけど、括弧つきの部分が （未確認） から （読み込んでいます） という表記に変わっていました。きっと、復元の途中であることを示しているのでしょう…。
そうしたらいよいよ、先ほどのようにその先の TRN ファイルを指定して復元を行ってみます。
これ以降のトランザクションログが 3 つ残っていたので、それらを全部充ててみます。ですので最初の 2 つは NoRecovery にて適用し、最後のひとつは Recovery で充てることになると思います。
それだけ注意しながら適用していくと、無事復旧が完了しました。3 回目に Recovery をつけた時点で、表示されているアイコンの色も灰色から黄色に変わってスタンバイ完了です。
バックアップファイルの利用方法 【まとめ】
これまでのお話を少しまとめてみると、とりあえずデータベース保守計画をつかって取得したバックアップファイル *.BAK は、それをそのままバックアップデバイスとして指定することが出来るようですね。なので保守計画にてバックアップをしておけば問題なさそうです。
特に master と msdb を復元できれば、その後の復元手続きがほぼ自動にて行えるようになるので、これらはすぐに復元できるよう、データベース変更のたびに master をバックアップしておくとよさそうです。
msdb の方もバックアップのたびくらいにバックアップしておくのが何かの時には楽だと思いますけど、その辺りはバックアップの頻度を考慮して調節しましょう。自分の環境だけかもしれないですけど、フルバックアップでも msdb は 8MB 程度だったので、容量の面ではさほど気にならないとは思います。もちろん、msdb にないログも面倒ながら手動で復元することが出来るので、ある程度さえあれば問題なさそうですけど。
ただし復元の際、それらはハードディスク内に置かないと Enterprise Manager は発見することが出来ないようなので注意です。 パスはウィザードにて確認できますし、msdb 内の backupmediafamily にて調整することができますけど、一応その辺りも考慮に入れてバックアップを行っておくのがよさそうです。
たとえば Windows 2000 の NTFS の場合はフォルダへドライブをマウントすることが出来ますから、必ずあるであろう C:\ にフォルダを作ってハードディスクをマウントしておくといった方法も、PC が壊れて交換したなんていうときに融通が利いて何かと助かるかもしれません。試していないのでわかりませんけど。
または USB ハードディスクのお世話になるのも良いかもしれないですね。あれなら必要なときだけ装着でき、ドライブ名を変更するのも容易ですから。
最後に、復元が終わったら、改めてその時点でのデータベースのバックアップを行っておくのがよさそうです。
これは msdb が最新ではなかった場合などにバックアップ履歴等の情報がすこし狂ったりする恐れがありそうだからです。もちろん完全に復元できたならそれでよいかもしれませんけど、せっかく直ったわけですし、気分を改める意味でも一度、ここでまたフルバックアップを取っておくとよさそうな気がしました。