お使いのブラウザは最新版ではありません。最新のブラウザでご覧ください。

CNET Japan ブログ

バックアップのすすめ

2004/05/24 20:54
  • このエントリーをはてなブックマークに追加

皆さんは、ハードディスクのデータをマメにバックアップしているでしょうか?

個人で手軽に使えるパソコンの登場以来、常に言われ続けてきたことでありながら守られないバックアップという常識、この重要性について個人的に痛感することがあったのでエントリしてみます。

■データ破損に至る経緯

私事で恐縮だが、最近自宅のLAN環境でかなり大規模なデータの破損事故に見舞われた。

経緯はこうである。

我が家ではLAN環境内にWindowsとMacOS Xが混在しており、ネットワーク接続のストレージであるBuffalo社のLinkStationを共通のファイルサーバとして使っていた。

Buffalo : LinkStation

LinkStationは内部的にはLinux+Samba+Netatalkで動いているらしく、NetBIOSとAFPの両プロトコルに対応している。このため、WindowsからはNetBIOSで公開されている共有フォルダを、MacからはAFPで公開されている共有フォルダをそれぞれ独立して設定して使用していた。(MacOS XはSMB経由などでもアクセスできるが、ファイル名が化けるなど諸々の問題があるためAFPに頼らざるを得なかった)

iBookのHDD容量が絶対的に少ないこともあり、iTunesの音楽データが格納されるマスターライブラリとしてファイルサーバ上の共有フォルダを指定するようにし、iBookの起動時にその共有フォルダが自動マウントされるようにして使っていた。

All About Japan : MacOSで起動時に共有フォルダを自動マウント

これはこれで大変快適な環境で、AirMac ExtremeによるIEEE802.11g接続でもネットワーク越しとは感じさせない性能が出ていた。

ところが、悲劇はやってきた。

ゴールデンウィークあたりのある日のこと、いつものように「ソフトウェア・アップデート(Apple製ソフトウェアの自動更新)」を実行し、iTunes 4.5やiPod Updateなどをインストールした。そして何気なくiTunes 4.5を起動してみると、「ライブラリの更新」が始まった。私のiTunesのライブラリは5000曲近くあったので、この更新作業自体にものすごく時間がかかるようで、15分ほど待ってもプログレスバーは数%しか進まない。しかしキャンセルもできなかったので、不安もあったが仕方なくiTunesを強制終了した。

すると、その直後からAFPで共有フォルダに接続できなくなってしまったのである。

この時には出かける用事があったため、これ以上の調査はできないと思いLinkStationの機能である「ディスクチェック」をWeb管理ツールから実行しておこうと考えた。ディスクチェックには数時間かかるため、帰宅する頃には処理が終わっているだろうと考えたのである。(このディスクチェックにはfsckの自動修復オプションがついているような記述があるのがほんの少し気になりながら。。。)

ところが帰宅してみると、今度は共有フォルダはおろか、Web管理ツールにさえアクセスできなくなっているではないか。このあたりからさすがに本気で心配になってきた。何と言っても、ここ10年来に溜めた50GBにおよぶデータをLinkStation上に移したばかりである。そして、iTunesにAACフォーマットで読み込み済みのCDはあらかた中古で売り払ってしまった。渡米のため、なるべく引っ越しの荷物を減らして身軽にしようと考えてのことであった。ちょうどバックアップ方法をこれから考えようというところだったので、タイミング的には最悪だ。

焦りを感じつつクロスケーブルでLinkStationとマシンを直結してPingしてみると、レスポンスが返ってくる。つまり、LinkStationのOS部分は無事のようだ。ということは、HTTP/SMB/AFPの各サーバが落ちているだけでデータ本体は生きているだろう、と読んだ。

一応Buffaloの修理センターに本体を送ってみると、案の定、確かに故障だがデータの復旧には一切関知できないとの杓子定規なお答え。何も手をつけず送り返してもらい、そのまま今度はデータ復旧を専門に行う業者に送って調査してもらった。

そして、今日になって事前調査の結果が来た。

お預かりしましたHDDを検証したところ、原因はわかりませんが、inode tableが消去されていました。よって、この部分を手作業にてファイルの再構築を試みましたが、結果的に復旧が不可能でした。このような場合は、海外の工場に依頼するという形になります。復旧までのお見積金額及び納期:HDDの総容量が160GBですので、復旧に成功した場合、復旧費用は470,000円(納品メディア・宅配費別)となり、復旧できない場合は、復旧費用はいただきません。納期は、ファイル管理形式が特殊な為、1ヶ月程度かかります。また、今回の場合は、フォルダ名及びファイル名の復旧は不可能となりますので、その点もご了承下さい。

クラクラ。。。目眩を感じた。過去からのデータが溜まっていたりOSごとのファイル名で保存されている環境では、ファイル名や最終更新日時などの属性情報がなくなるのは致命的だ。よりによってinodeが破壊されているとは。。。

というわけで、とりあえずディスクは送り返してもらい、遠い未来に何とか自力で物理レベルから修復することを夢見て保管するが、データ量と手間暇を考えると現実的にはほぼ絶望的な状況になってしまったのである。

■教訓:バックアップはデイリーで

データの冗長化による保全を考える場合、よく引き合いに出されるのがバックアップとミラーリングだが、重要度で言えばバックアップの方がはるかに重要だということを痛感した。

ミラーリングはシステムを止めないための機構だが、バックアップはデータの紛失に対する備えである。ミラーリングでは物理障害を救えるが、誤操作などによるアプリケーションレベルの論理障害には全く役に立たない。データの意味的な破損には何の効力もないのだ。

今回の件で言えば、同じサイズのHDDに毎日決まった時刻にデイリー・バックアップするようにしておけば前日の状態に戻すことが簡単にできたということである。しかも、ここまでデータサイズが肥大化するとHDD以外のバックアップメディアは現実的ではないし(サーバならテープという選択肢もあろうが)、差分でコピーできなくては現実的ではない。反対にデイリーよりも短い周期でバックアップすると、ミラーと同じような問題(壊れたデータをコピーしてしまうこと)を抱えてしまう可能性が高くなる。

考えうる最悪の結末を迎え、何事も基本が大事だと深く深く反省した今日この頃である。。。

そのほかにも、いくつか教訓。こうして列挙してみれば、やはり常識的なことばかり。

  • 実績の少ないアップデートはすぐに当てない
  • 実績の少ないプロトコル(AFP over TCP/IP)の限界を試すような使い方は避ける
  • メーカーがテストしなさそうな使い方(iTunesのライブラリをサーバ上に置く)は避ける
  • ディスクの修復(fsckなど)は更なる破損に繋がる可能性を考えて安易に行わない

iTunes
iTunes 4

今回の件は下記の問題と合併症を起こしていた可能性が高いが、これとて今や真相は闇の中。

iPod用アップデータに不具合--アップル、原因を調査中

今回の件で敢えて犯人を挙げるとすれば、iTunesの起動と同時に強制的にデータを更新開始しキャンセルさえできないという、大量データを更新するシチュエーションと待ち時間に対する配慮が欠けていたアップルであることには間違いない。今ではiPodに10,000曲入るのだから、このぐらいのデータ量でテストはしたはずだと思いたいが。。。

♪ Harem Scarem / Saviors Never Cry

※このエントリは CNET Japan ブロガーにより投稿されたものです。朝日インタラクティブ および CNET Japan 編集部の見解・意向を示すものではありません。
運営事務局に問題を報告

最新ブログエントリー

個人情報保護方針
利用規約
訂正
広告について
運営会社