ある程度パソコンを使ったことのある方なら、データが消えてしまった！、という事態の当事者になったことは少なからずあろうかと思う。また経験豊富な方なら、HDDまるごとパーになってしまうという事態に直面したこともあるだろう。筆者もまた、数知れずそうしたデータ消失事故を経験してきたし、筆者の周辺で幾多の絶叫を聞いてきた。
こうした時に、念仏のように聞こえてきたり頭をかすめるのがバックアップという言葉だ。バックアップの基本は、所有しているデータを冗長化して災害に備えるというものだ。多重化したデータ（つまりコピー）を以ってデータの消失にに備えることだとも言える。
バックアップをとるということはイコール，データの複製を作るということであり、バックアップされるべきストレージに近い容量のストレージがなければ、バックアップということ自体成立しない。かつては、フロッピーディスクにシステムやデータが全て収まって完結していた時代があり、この時代のバックアップはコピーを作ればそれで済んだ。またHDDが市民権を得てからしばらくは、MOを代表とするリムーバブルメディアはバックアップするのに十分な容量を持ち合わせており、やはりコピーを取ればそれで良かった。このためか、バックアップ＝丸ごとコピーという感覚も随分蔓延していたように思う。
ところが、現代のパソコン事情はそうした昔の事情とは随分異なっている。HDDの容量増大は甚だしく、既に数百ギガバイトの世界に突入しつつあるのだ。もはやこれを丸ごとバックアップできるメディアは事実上HDD以外にはなく、筆者の周辺でも個人として丸ごとバックアップを作っている人は稀という状態になっている。バックアップメディアとしてHDDを選択するということは、機材のコスト的には十分に考えられることだ。しかし、「丸ごとバックアップ」というのは、それに要する時間と手間を考えると、我々パソコン小市民にとっては現実解とは言い難いものであるのが現状である。
勿論、バックアップに専用のソフトウェアを使うことで、一度丸ごとコピーを取った後は更新されたデータのみをバックアップしていくということもできるだろう。しかしながら、次に問題になるのがバックアップを取る頻度である。直近のデータであるほどバックアップが必要というのもよくあることだ。
仮に1週間に一度完全バックアップを取れるようになったとしよう。しかし、死なれて困るのは1週間前のものではなく、昨日や今日生産したデータであることも少なくないのである。時間に追われているとき生産しているデータなら、消失の5分前のものこそが死なれて困るクリティカルな生産物であったりもするわけだ。
こうして考えてみると、徒らに面倒な丸ごとコピーというバックアップの方法では、その頻度を高めることが容易でないために必ずしも保護して欲しいデータが残るとは限らないように思えてくる。
我々パソコン小市民が、このような大容量バックアップ難時代を生き抜くためにはどうしたらよいか？ 具体的な方法を考える前に、まずデータの消失がどのような原因で起こるのかを眺めてみたい。「丸ごとバックアップ」が現実的でないなら、異なる原因で起こるデータ消失に対して，夫々異なる対策もあろうというものだ。
筆者が独断ではあるが、データ消失が起きる問題の所在は，「ハード層」「ソフト層」「人間層」の３層に分けられると思う。なんだかネットワークのレイヤーに似た概念ではあるが、問題がどこにあるかを認識することが対策の第一歩だ。
「ハード層」というのは、問題の所在が機械や装置であるようなものだ。具体的には、ハードディスクの故障などはこの層に属する。世の中で「ディスク・クラッシュ」という言葉は良く聞かれるところだが、ハード層に属するのはこのうちの機械的故障だけである。
ハード層において生じるデータ消失の範囲は、その装置全体に及ぶものだ。したがって、この層におけるデータ消失を保護するには、原則として丸ごとバックアップ以外にない。但し、一般にはハード層の問題によるデータ消失というのは、それほど頻度が高くないのが救いだ。なお、RAID（1とか5）というシステムは、このハード層における障害を保護してくれるものだ。
「ソフト層」での障害というのは、ソフトウェア的な不具合によって書き込まれたファイルが破壊されてしまったり、あるいは同じメディアに記録された周囲のファイルやフォルダを巻き添えにして失ってしまうというものだ。ハード層で起きる障害と比較すると、頻度が高く、悲鳴のもとであったりもする。
主にＯＳやアプリの不具合（バグ）が原因で起こるこの不具合は、突然起きる障害であって避けることが難しい上に、一度起きたらいつかまた起こるという再発性の高い障害であるから注意が必要だ。しかもその根源的な対策はＯＳやアプリのベンダによるアップデートに頼るしかないのだが、ヘタにアップデートすると別のバグが出ることもあって、必ずしも最新が最良とは限らない点が、ソフト層における障害を厄介なものにしている。
さて、「人間層」での障害というのは何だろうか。それは自らの不注意が招く事故である。例えば「誤ってデータを削除した」とか「セーブしないままアプリを終了した」とか「間違った編集の後に誤ってCtrl+Sを押してしまった」，あるいは「ファイルの所在が分からなくなって紛失してしまった」などなど、この事故の事例は枚挙に暇がない。
筆者のような注意力散漫な人間の場合、この「人間層」におけるデータ障害が最も頻度が高い。筆者の周囲でも、この類の事故を目撃することがあることから、結構頻度が高い障害の原因であるように思う。
更に、人間層の障害が起きるときと言うのは、時間的に厳しい場面であることが多く、ほんの数分前のデータの消失が致命傷ということも珍しくない。基本的に誰にも責任を問えず、自問・自責・反省して諦める場合がほとんどであるが、なかなか反省が次回に反映されないのが人間層における障害対策を難しいものにしている。
上記のようにデータの消失と言っても、その原因は様々であるし、障害が発生する頻度も影響を及ぼす範囲も様々である。データの丸ごとバックアップを高い頻度で実行することが非現実的となりつつある今日においては、それぞれの原因に適合する対策を講じることが必要になるだろう。（29.Aug, 2004）
前項で、データ障害の原因の所在が「ハード」「ソフト」「人間」の各層それぞれに在ることがご理解いただけたかと思う。もっとも、一ユーザーの立場からすれば「どうやって対策するか」ということの方が一大関心事であろう。そこで、ここでは前稿での分類を踏まえた上で、筆者が独自に一小市民として実践しているところを紹介してみたい。
まず、ハード層で起きる障害だが、残念ながらこれのバックアップを確実に取るためには本質的に「丸ごとコピー」しかない。しかしながら、更に重要なのは出来るだけ事故に遭わないようにする、という心掛けである。例え保険が掛けてあったとしても、事故に遭遇しないに越したことはないというものだ。
そのために、できるだけHDDを長持ちさせるための方法について記述があるサイト（あちらやこちらなど）などを参考にしながら、ディスクの機械的寿命を延ばすことを考えるのも大変重要なことだ。しかし，如何に延命できたとしてもやっぱりハードディスクは消耗品なのである。いずれは機械的寿命によって読み取り不能になる日がやってくると心得たほうが良い。
そこで筆者は以前に書いたように、適当な時期に満杯になって交換したくなる容量のHDDを購入時に選択することにしている。以前に書いた RAID事故の経験では、ほぼ１年中アクセスランプが点きっぱなしという条件で、HDDの機械的寿命はおよそ１年であった。この事故のときに限らず、そのシステムは大体１年に一度は障害を起こしていた（そして同時期に故障が多発した）ことから、酷使したHDDの寿命は大体そんなものだろうと思われる。
勿論、我々パソコン小市民が個人として普通に使っていればそれよりも数分の一以下の負荷とデュティである。そして筆者の経験からするとHDDは４〜５年くらい経つと雲行きが怪しくなるように思われる。したがって、筆者は命数が３〜４年、賞味期限が２年程度のＨＤＤを購入時に選択し、機械的寿命を迎える前に交換する（したくなる）ように心掛けるようにしている。
そして退役したＨＤＤには、化石のように歴史の記録者としてバックアップメディアの役を負ってもらうことにしている。つまり、退役させたＨＤＤを別な目的に使うのではなく、そのままの形で静かに余生を送ってもらうというわけだ。勿論、退役したＨＤＤ内のデータは直接接続かもしくはネットワーク経由で新世代のＨＤＤにコピーするのである。増設とはならないので一見容量を損したような気になるところだが、３〜４年経った新世代ＨＤＤの容量は十ニ分に広い筈だ。
この方法を採用している筆者の場合、フルバックアップを取るのは3年に一度程度ということになる。あくまでも丸ごとバックアップが非現実的な個人向け、というレベルだ。因みに筆者は10年近く前からこの方法を採っていて化石化したHDDも３世代に渡るが、今のところ運良く（個人用メインのＰＣでは）ハード層のトラブルに遭遇していない。そして化石化したHDDにはもちろん、現用HDDにも 1980年代からのデータが今なお生きている(*)。なお、１台目のＨＤＤは、２台目の化石化が済んだ時点から遊び用に流用していたが、流用を開始して１.５年ほどで昇天した。やはりHDDの機械的寿命と言うのはせいぜい5年程度なのだろうか。
また、サブマシンを所有する筆者の場合、化石化したHDDはサブマシンに繋いでたまに火を入れてやるようにしている。これは飽くまでもおまじないではあるのだが、化石化したHDDが生きているかどうかを確認する作業でもある。もしこれの息が絶えていたなら、筆者はその時点で現用HDDのフルバックアップを取ることだろう。
尚、言うまでもないがこの方法では全てのデータが保全されるわけではないので，完璧を期す必要がある場合にはお勧めできないので注意して欲しい。使用状況や運によってはHDDは1年程度で読み取れなくなることもある。
え、筆者のHDDが直ぐにダメになったらどうするのかって？ それは次回に示すソフト層・人間層への対処として行っているバックアップによって上澄みのデータだけが残れば良く、有象無象は捨てるという考えである。繰り返しになるが，より完全を目指す向きには筆者の方法は向いていない。筆者のように、バックアップを取る時間が惜しく（それほどに面倒臭がりで）、尚且つ大事なものだけが残って，現在進行形の作業さえ継続できればそれで良いという人にのみ向いている方法である。
続く…（3. Sep, 2004）
[訂正*] 乱丁がありましたので、訂正しました。(6. Sep, 2004） [追加] 「写真：化石化したHDDの様子」を追加。（11. Sep, 2004）
前述のようなハード層におけるデータ消失事故に対してより安全策を施すには、RAID（1 or 5）は有効な手段である。しかしながら、後述するソフト層及び人間層における事故に対しては無力であるので注意したい。すなわち、ソフトの不具合や人間の不注意によって引き起こされるデータの破壊に対して、RAIDでは破壊された後のデータも忠実にリアルタイムで複製が作られてしまうのだ。 RAIDを構築することとバックアップをとることはそもそも意味が違うので、勘違いしていると泣きを見ることがある。
さて、ハード層よりも頻発し易いソフト層や人間層での障害に対してはどうすべきだろうか。ソフト層の障害で最も多い障害は、アプリケーションエラーやハングアップによってセーブされていないデータを失ってしまうことだろうか。メインメモリは揮発性が高いのだと改めて感じるところである（本来の揮発とは違う意味で）。もちろん、これに対応するためにはこまめにセーブが基本であることは言うまでもない。
厄介なのは、ＯＳやアプリに組み込まれた種々のトラップ群だ。例えば，編集内容によっては保存した途端にアプリケーションエラーが出てセーブできなくなり、過去に保存したデータを再び開いても再セーブ不可になるという仕様の某トップシェアワープロソフトもある。あるいは、やたらと沢山の拡張子に関連付けを行った挙句、他のソフトのファイルにも関連付けてしまい，過ってそのファイルを開いただけでご丁寧にそのアプリ用の空ファイルに変換・上書きしてくれる仕様の某有名オフィスアプリもある。
こうしたアプリには自動バックアップ機能なども備わっていることがあるが、いざ障害時にはダイアログが出現し、正しく解答しないとキレイにバックアップデータを消してくれる仕様のものもある。障害時の気が動転しているところにつけこんだ、実に念入りに仕込まれたトラップだ。更に、正しく解答しても開いてみるとゴミだけという場合もある。そもそもソフト層での事故はアプリが原因なわけだから、そんなアプリの機能に頼っていては痛い目を見ることがあるのは当然だろう。
ソフト層での障害に加えて、更に頻度が高い人間層での障害も、多岐にわたっていて泣きを見やすい。ソフト層や人間層での障害は，影響が及ぶ範囲は狭いが頻発することが問題なのだ。したがって、ソフト層や人間層での障害に対しては，丸ごと力技バックアップよりも頻度が優先されるべきだ、と筆者は考える。如何に高速なHDDを使ったとしても，丸ごとコピー作戦では頻度を上げることは難しい。差分バックアップをとるにしても、「差分がどのくらいか」を算定するのに要する時間もバカにはできないだろう。
そのため、筆者はソフト層，人間層の障害に対しては心掛けと日頃の行ないで備えることにしている。その第一は、作業開始時にファイル名をつけて保存することである。これは「無題」の状態で作業していると保存の作業が最後になりがちで、こまめにセーブの鉄則が崩れ易くなるからだ。途中でソフトが止まったり，誤って窓を閉じてしまったりした時に全てが失われる可能性が高くなることを防ごうという心掛けである。また、別の日に編集のために開いたような場合には、やはり開いたときにファイル名を変えるなどして保存しておく。
第二はファイル名のつけ方だ。筆者はファイル名の先頭に日付を入れるようにしている（この方法については既に先人がおられる）。そして日付の後に「多少長くなってでもキーワードを含んだ説明」を加えておくようにしている。現代の HDD は広大で、記録されるファイルの数も膨大になりがちだ。ファイルの個数は HDD 容量にはインパクトを与えないが、人間の記憶力の限界はすぐに超える。ＰＣ関連機器の性能向上に伴って人間の記憶力まで進化するということは聞いたことがない。恐らく筆者の記憶力も数千年前の人間とそう大差あるまい。
なので、少なくとも筆者には数万あるいは数千個程度のファイルであっても、どれがどんな内容であったか全てを覚えてはいられない自信がある。ファイル検索機能なども利用するわけだが、結局のところ容易に検索できるのはファイル名に埋め込まれたテキストだけなのだ。（なお、デジカメの画像のように全てを改名するのが面倒な場合にはフォルダ名に同様のことを施す。）紛失という現実世界でも起こる障害は、ＰＣの中でも起こるものだ。
このように、日付とキーワードから成るファイル名で保存し，日が変わってファイルを編集するタイミングなどで別の名前で保存していくことでリダンダンシーが増して障害の際にも慌てずに済むようになるというわけだ。なお筆者の場合、特に切羽詰って作業をしている時などは日付の他に時刻まで付け、コーヒーブレイクなどのタイミングで冗長性を増させるように心掛けている。
このようにして生産してきたデータは、適当なタイミングで保存しておきたいものを適当に選定してリムーバブルストレージやネットワーク上のストレージなどにバックアップを作ることになる。これはハード層、ソフト層、人間層のいずれかで障害が起きた場合に備えるものだ。筆者の場合は、このタイミングでメールや住所録などの極めて長期に渡って蓄えてきたデータのバックアップも取るようにしている。
ここで大切なことは，使用しているアプリが何処にファイルを作っているかを必ずよく把握しておくことである。メールや住所録の類はアプリが勝手に決めた場所にファイルを作っているというケースも少なくない。筆者の場合は、よく使うアプリの保存先リストを簡単なテキストファイルで作成して，バックアップの際に参照するようにしている（新しいアプリを導入したら、ここに保存先を書いておく）。
こうして作っておいたバックアップは、人間層での災害が最も起き易いＰＣ更新，再インストール時にも役立つことだろう。
* もちろん、以上は筆者の個人的な心掛けである。筆者は上記の記事に対する関連／非関連を問わずデータ災害に関する一切の責任を負わない ということをご理解いただきたい。
（11. Sep, 2004）
当サイトにある記事の著作権は M.Abe に属します。
なお、当サイトの記事の転載はご遠慮ください。