最終更新時刻：2008年10月10日(金) 23時50分

CNET Japanからのお知らせ

CNET Japanでブログを書こう
ベンチャーの最新動向を読み解く
Googleのブラウザ戦略とは？
フジサンケイビジネスアイと連動中

トップ » ブログ » 江島健太郎 / Kenn's Clairvoyance » バックアップのすすめ

江島健太郎 / Kenn's Clairvoyance

バックアップのすすめ

公開日時：: 2004/05/24 20:54
著者：: kenn

トラックバック(2)

コメント(10)

ブックマーク(-)

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

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

■データ破損に至る経緯

私事で恐縮だが、最近自宅の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 編集部の見解・意向を示すものではありません。

ログインしてコメントするこのエントリを評価する

運営事務局に問題を報告この記事についてブログを書く（ブロガー専用）

このエントリーへのコメント

タカさん

データそのもののコピーはできませんね。iTunesの設定でライブラリ保存フォルダをLINKSTATION内にした状態でRipすれば、問題なくiTunesが31文字以内にファイル名をtruncateしてくれてるのですが。。。あとからコピーするのは難しいのかも知れません。（まだちゃんと検討してませんが、ファイル名を詰める作業はTigerのAutomatorとかで自動化できるかも）

それから、LinkStationの場合、いったんMac専用で共有フォルダを作ってそこをマスターにしたら、そのフォルダを決してWin/Mac兼用にしないことをオススメします。いきなり全てのファイル名がMac上で化けます。（Win上では読めるし、動作もするんですけどね。これも、詳しく追ってはいませんが）

ちなみに私自身は諸事情あってLogitecのLHD-160LANに移行中ですが、こちらは上記のWin/Mac問題がない分、もっと制約が厳しいようで（特にファイル名に日本語が含まれるもの）、移行には悪戦苦闘しています。

kenn on 2005/06/08

江島さん、質問です。

この記事を読んで、LINKSTATIONを購入し、MacからiTunesの音楽データをコピーしようとしたのですが、ファイル名の長さでひっかかってエラーになってしまいました。なんとかしてLINKSTATIONのほうにデータを移行する手段って、ないですかね。
ちなみにデータそのものをコピーするやり方だけじゃなくて、iTunes上にmp3/aacファイルをドラッグして、iTunesの「ライブラリへコピー/整理」機能を使ってみてもダメでした。

タカ on 2005/06/05

すぐ他人に責任転嫁するのはよくない。
結局のところ実績のない製品を使った機器選定のミスが大きいのでは？
あとCDを処分してしまった段階で違法性の高いMP3ファイルを50Gも所有している点が。。。
笑わせてもらいました。

またCD買ってください。くれぐれもNetで集めないようにね！

hogehoge on 2004/05/28

てんちょです。

いやー，江島さん，ご愁傷様です。
まぁネタになったと思って...っていう気持ちにはなれませんよね。

私も先日会社のマシンでホームがあるドライブが見れなくなってしまいました。なんとかドライブまでは認識していたので，チェックディスクをかけて，大量の不良セクタを検出しながら，最終的には，見事復旧しました。

やはり日ごろの行いが...ってことはないですね。

ちなみにバックアップは自分の頭の中以外には取っていませんでした。それって...

てんちょ on 2004/05/28

Mac OS XおよびMac OS 9で、ネットワークマウントしたボリューム先にiTunesなどのライブラリを置く使用法について「実績の少ない」と表現することには同感です。
ただ、その場合はプロトコルとしてのafpovertcpは無関係です。
(もっともafpovertcpを使用する場面が、Apple社OSしか存在しないので、文意としては伝わらなくはないですが)
i-nodeまで破壊できてしまうのはファイルサーバーのOSおよびファイルシステムのチューニングの問題が大きいと想像しています。
この場合もプロトコルとしてのafpovertcpは無関係です。

「AFP over TCP/IPだけが悪い」と受け取られかねない表現は疑問です。

otsune on 2004/05/28

KAIさん

MacOS Xからはユーザプロセス境界での安定性は格段に向上しましたね。（かといって論理障害はそれとは全く関係ないというのが今回の教訓ですが）

きんさん

CDは別に売って金をもらうのが目的ではなくて処分したかっただけなので、タダで利権団体が廃品回収してくれるのならそれでもよかったんですけどね。たまたま中古CDだと回収業者がトラックで来てくれて重たい大量の荷物を持って行ってくれたからで、純粋に利便性の問題です。いずれにせよ肝心のデータは失われたわけで踏んだり蹴ったりですが。。。（涙）

otsuneさん

仰るとおり、まぁ正確に言えばafpの問題というよりは実装の問題ですね（ただ、普通プロトコルが枯れているというときは典型的な実装も含意しますし、use-case robustnessもひとつの指標です）。今回で言えばNetatalkとMacOS XのAFPクライアント、およびその上位にあるiTunesとFinderの実装の質とそれらの相性と言えます。個人的にクサいと思っているのは強制終了時にinode上に排他ロックが残ってしまったのではないかという説です。しかもext2...悪条件重なりすぎですね。

nyarさん

実はリトライも結構クサいと思っています。サーバ側の状態とクライアント側の状態が同期しなくなった場合（サーバ側では排他ロック取得に成功したがクライアントにAckパケットが届かなかったとか）など、境界条件近辺では例えばDuplicateのハンドリングとか暗黙のワークアラウンドをやらないといけなかったりするのですが、こういう類は非常に再現性が低いので後回しにされがち。。。

そういえばライブラリ更新の途中からiTunesがCPU利用率100%まで振り切ってしまってたので、スピンロックなどのお寒い実装やってる可能性も若干疑われます。

このへん、真実をご存じの方にはぜひご教授いただきたく。。。

kenn on 2004/05/27

データロストご愁傷様です。
バックアップの重要性と、ミラーリングの落とし穴についての解説、大いに参考になりました。
さて、いくらLinkStationがアプライアンス化された商品とはいえ、今回のような負荷はおすすめできません。
大きなファイルの逐次転送では特に怪しさを感じませんでしたが、
例えば1MB以下の大量のファイル(総容量1～2GB)を100Base-Txで連続転送すると、転送レートが時折ストンと
下がるようです。device busy様の例外もバンバン出ます。大抵はリトライでカバーされますが...
また、同様の条件でフォルダごと上書きコピーしたり更新させると、フリーズに近い症状が度々出ます。
スイッチングHUBを間に入れたら軽減した記憶があります。因果関係は詰めてませんが。
W98SEのDOS窓でXCOPY32コマンドを試すと、OSの限界より先に、様々な限界を体感できると思います。
エクスプローラでは何度もフリーズ・スタックしましたが、要因が多すぎ絞り込みは無駄とあきらめました。
AirMacがExtremeでなければ起こらなかった悲劇かもしれません。
iBookのバックアップには、FireWireの外部HDDをFAT32でお使いになられてはいかがでしょう。
Windowsでもファイル開けますし。

nyar on 2004/05/26

>実績の少ないプロトコル（AFP over TCP/IP）の限界を試すような使い方は避ける

ですが、これはFUDがすぎると思います。
afpovertcpは十分に実績があるプロトコルです。
この事例で扱われているデータ転送量以上にパフォーマンスが出ています。

問題があるとすればLinkStationのnetatalkの設定だと思います。
「筆者にとっては実績の少ない」という限定的な意味に訂正してみてはどうでしょうか?

otsune on 2004/05/26

うるさいようですが、iTunesにCDを取り込んで、iTunesから、そのデータを削除しないで、売っちゃあいけません。フェアユースに反している可能性が...

きん on 2004/05/25

お悔やみ申し上げます。

いつも楽しく読ませて頂いておりますが、人ごととは言え、アップルユーザーに異変が起きているのでしょうか？

いえ、と言いますのも、昔から爆弾マークに慣れたマックユーザーは、デイリーバックアップどころか、アプリケーションの自動バックアップさえこまめに設定していたと思うのですが。

ということは最近はマックの製品は落ちる心配がなくなったということでしょうか。それはそれで良いことなのでしょうが・・・。　KAI

KAI on 2004/05/25