Drafts

@cm3 の草稿置場 / 少々Wikiっぽく使っているので中身は適宜追記修正されます。

データバックアップの体制をどうデザインしたらよいのか

以下は、「だれか、もうちょっとこういうことを体系化して考えている人はいないのか」という悲鳴のような駄文です。


大規模なバックアップだと、テープが信頼性高くて速いとか、そういう話もあるけど、個人でテープでデータをバックアップするというのは初期投資が大きすぎてあまり選択肢にならなかったりする。そういう話はデータのバックアップは複数必要en)こういうところに書かれていたりするけど、あまり論文では見ない(当然と言えば当然?)。iPRESだと、実務者もいるので、テープからのデータの救出の実務的な論文 とかはある(あんまりちゃんと読んでないけど)。

3-2-1ルールとかはググるとたくさんヒットするくらい有名だけど、特に由来とか知らないし、学術的な背景があるとは思えない。そもそも長期保存ネタ全般そうだけど、直接「長期保存できること」を指標にすると実験が長期にわたるし、技術面以外の要素が大きすぎて、論文化しにくい。3-2-1ルールはEcological Informatics - Data Management and Knowledge Discovery | Friedrich Recknagel | Springer の 6.2.10 Protect Your Data とかで言及されてたりするし、他にもData Management とか見てると、研究データ共有の文脈で出てくる Data Management Plan とかと絡んでバックアップのことが書かれてたりするので、教条的dogmaticになりがちではあるが、"Data Management" というのはデータバックアップを考えるための現代(←ウェブ的には20年前は古代なので…)的な一つのキーワードだと思う。ビジネスの文脈でも「多くの人がバックアップは成熟市場だと考えているが、バックアップにとどまらず、データマネジメントにシフトすることで大きな成長が見込める」 という口上が見られたりもする。そして、その観点から、

バックアップ要件として考えるべき点には、大きく8つのポイントがあるという。具体的には、「場所」「対象」「データ量」「管理性」「災害対策」「データ保護」「セキュリティ対策」「データの再利用性」。

くらいの要素分解は可能だろう(「本当のDX」を実現するために必要なデータマネジメント、データバックアップの在り方とは:“2025年の崖”に向けたデータ管理環境の整備を - @IT)。ぜーんぜんMECEじゃないので要素分解と呼ぶのも躊躇はあるけど。3-2-1を守っていても、チェックする頻度が低ければ危ないのだけれど(いつの間にか壊れているということが起こる)そういう話は「管理性」の詳細化になるだろうか。

内省的に考えて、そういう体系を立てることは前述のように教条的になりがちで弊害も多い。そこで、失敗学的なアプローチで過去の様々な事件(例:「33自治体のデータがIaaSから消失」、日本電子計算がシステム障害の詳細明かす | 日経クロステック(xTECH)レンタルサーバーで「大規模障害」 重要データが消失、企業に衝撃走る: J-CAST ニュース【全文表示】GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット - Publickey)、ファーストサーバ障害、深刻化する大規模「データ消失」  :日本経済新聞)を体系的に蓄積・整理して、知見を得る、くらいは必要かもしれない。もしくはもう一歩踏み込んで、インタビューや調査をやって、失敗を丁寧に記述するところから始める。


あと、ディレクトリの構成も難しい。アーカイブとバックアップの切り分け として、利用頻度が低いものをアーカイブ、使っているものはバックアップと分けることで、バックアップの頻度やアーカイブのメンテナンスの頻度を最適化できるのだけど、利用頻度と意味的構造はもちろん異なる。プロジェクトAとプロジェクトBそれぞれに、アーカイブ部分とバックアップ部分が生じる。じゃあ、分ければいいじゃないかと思うだろうが、プロジェクトAのbinとdocsにもアーカイブとバックアップが生じる。では、すべてのディレクトリに.archiveディレクトリを作ってそれをアーカイブとする?ディレクトリごとアーカイブするときは、バックアップフォルダに空のディレクトリが生じる。まあ、そのくらいは許容するとして、ディレクトリツリーの構造を変更したときに整合性をどうやって取る?…そう単純ではない。

個人的に、いまのところ手元では、プロジェクトごとに

  • project.cloud 利用頻度高。プロジェクト管理のメイン(Dropbox, PCメイン=PCサブ, NASで保存)
  • project.local 利用頻度高。Dropboxに入れるにはサイズが大きい、ファイル数が多い、ローカルに依存が大きいもの。(それぞれのPCごとに内容が異なるので、ポータブルHDDとNASにPCの名前のサブディレクトリを切って保存。ファイルがデカかろうと基本的にはコピーするが、場合によっては common というディレクトリ以下に共通のものを入れたりはしている)
  • project.archive 利用頻度低。なるべく構造をフラットにしている。(ポータブルHDDとNASとPCサブに保存)

の3つに分けて、

  • PCメイン
  • PCサブ
  • NAS
  • ポータブルHDD
  • Dropbox

のうち最低3つにバックアップされるようにしている*1。そして、この3種類の構造を project.cloud にドキュメンテーションとしてちゃんと書くという形。ドキュメンテーションの際は OAIS も少しは意識しているが、どのレイヤーでどのようにOAISを取り入れるかも難しいと思ってる。

その他参考:

*1:2014-02-08からそういう運用にしていた。これ本格的に考え始めたのは、2013年に会議論文だした研究のデータの一部が吹き飛んで、復活できず、かなり人力でゴリゴリ頑張る系の仕事だったので、ジャーナル化を断念したからだったと思う…