悪戦苦闘

データを消す、というのに、これだけ手間取るとは思わなかった。

職場でちょっとした情報管理者のようなことをしていて、つい１週間ほど前にデータのバックアップをスケジュールで自動的に取れるように作業した。これまでは定期的にハードディスクを繋いでコピーを取る、いうことにしていたのだが、バックアップの間隔がどうしても長くなるからだ。

単純な仕組みではあるが、危険回避のためもあって、サーバを２本立ててそれぞれに違う種類の共有データを置き、アクセスが分散するようにしてある。
スケジューリングするには、バックアップ用に常時繋いでおける別立てのハードディスクが２ついる、と思ったからあきらめていたのだが、「なんだＡのデータをＢに、ＢのデータはＡに、それぞれバックアップすりゃいいじやないか」と思ったのがサーバー間のリモートバックアップをしてみようと思ったきっかけである。
…結局これが冒頭の悲嘆のため息を呼んだ。

リモートバックアップは、バックアップするフォルダを指定できず、ディスク全部をバックアップしてしまう。それをあまり深く意識していなかったのだが、今振り返れば、それはきわめて重要なポイントだった。
一晩クロスバックアップすると、「行き」のバックアップでＡのデータがＢへコピーされてＢのデータは（Ａ＋Ｂ）となる。「帰り」のバックアップでは、（Ａ＋Ｂ）となったＢのデータがＡへコピーバックされてくる（！）。つまりＡはたった一晩で｛Ａ＋（Ａ＋Ｂ）｝と約３倍のデータに膨れ上がるのだ。放置すると、次の晩にはそれが入れ子構造になって、データ量がそのさらに３倍…。

…週末に作業したために、３晩を経たサーバはバックアップデータでパンク寸前…。「まさか」と気がついて月曜にすぐチェックして止めたために、運用に支障を来すような事態に至らなくてよかったが、自分のアホさ加減に呆れてしまった。

ちょっと考えればわかることだが、バックアップの流れをＡからＢ（つまり（Ａ＋Ｂ））にして、それを外付けの１台のハードディスクにコピー、という一方向にバックアップの流れをそろえれば、ハードディスク１台できれいにスケジュールバックアップができるのだった。
ＡからＢは「毎回上書き」、Ｂから外付けでは「履歴○回」とすれば、パンクもせず、履歴も取れる。

あーあ、じゃあ早速そうするか、と作業しようとしたら、次は「初期化せずに、運用しながら、２００ギガ以上のデータを消す」というのが、大変に時間のかかる作業であることを思い知らされることになった。
まずは「エラー1148」や「ファイルを消去できません」のアラート連発。最初は、データの数の多さや、まれに混じっている「ファイル名のやたら長いファイル」のせいかと、一つ一つ探し出しては消していたが、さっぱり埒があかない。
そのうち、どうもそれが主要な問題でないことがわかってきた。

スムーズに消せない最大の原因は、入れ子でバックアップが繰り返されたことによる異様に深い「階層」だと気がついた。
「エクスプローラー」で一番下の階層まで行って巨大なフォルダを「切り取り」、上の階層に「貼り付けて」やれば、どんな中身だろうと消去作業が始められるのだ。ただし、相当に時間はかかる。１フォルダの消去に１時間、なんてのはざらである。
それでも古いＯＳ（たとえばWindows2000）では、消去できる階層の深さも対象ファイル数も余裕がなくてエラーになることがある。結果的に、職場の人たちには申し訳ないが、接続している中で一番新しくてスペックの高いXpマシンを、消去作業に専従させることになってしまった。

仕事の合間にまめにやっても、数日はこの作業だけでかかりそうである。
いい勉強にはなったけれど…、間抜けな失敗が、時間的には高くついてしまった。

[fin]