6 ポイント 投稿者 GN⁺ 2025-03-18 | 1件のコメント | WhatsAppで共有
  • デジタル保存 (Digital Preservation) の専門家である David Rosenthal の発表内容の要約

バックアップ (Backup) とアーカイブ (Archival) の違い

  • バックアップ は、災害発生時に直近の状態へ復旧するために必要
    • バックアップデータの有効寿命は、最後のバックアップから復旧までの時間によって決まる
    • バックアップデータの保存媒体の寿命は重要ではない
  • デジタル保存の分野で20年近く働いた後の、私の 4つの重要システムのバックアップ方法
    • メールおよびWebサーバー: Raspberry Pi に週次フルバックアップと日次増分バックアップを実施 → 週次バックアップを DVD-R に保存
    • デスクトップPC: 外付けハードドライブに夜間フルバックアップを実施 → 定期的に3台のハードドライブへローテーション保存
    • iPhone: Mac Air に毎日バックアップ → Time Machine を通じて SSD に定期バックアップ
    • オフサイト保管: 毎週 DVD-R、SSD、およびハードドライブを外部の場所に保管
  • アーカイブ データとは何か?
    • 時間の経過とともに、データはストレージ階層の下位へ移っていく
    • アーカイブデータ = 運用ストレージで維持コストを負担できないデータ
    • アーカイブストレージシステムの主な目標は コスト削減 であり、アクセス速度の遅延を受け入れる

アーカイブ保存媒体の現実

  • メディアでは「永久に保存可能なストレージ」について誇張が多い
  • 研究から生まれた新しい保存技術が市場で大規模に使われる可能性は低い
  • アーカイブ専用媒体は市場需要が低く、商業的に成功しにくい
    • 例: LTOテープ は保存媒体市場全体の1%未満を占める
    • 2023年の OD-3 (1TB 光ディスク) は市場不足により中止された

保存媒体の導入時期の問題

  • 新しい保存技術が市場に導入されるまでには長い時間がかかる
  • HAMRハードドライブ: 研究開始から26年後に導入された
  • シリカおよびDNAストレージ: 何十年も研究されているが、商用化までは少なくとも5年以上必要

保存媒体の経済性の問題

  • 保存媒体そのものより ストレージシステムのインフラコスト のほうがはるかに重要
    • テープやディスクなどの保存媒体コストは、総コストに占める比重が低い
    • データセンター規模で運用してはじめてコストを削減できる
    • アーカイブストレージは小規模運用では経済性が低い

クラウドストレージとロックイン (Lock-in) の問題

  • クラウドサービスのアーカイブ保存コストは、長期的には非常に高い
  • Amazon Glacier: 長期保管ではコスト削減が可能だが、データ復旧コストが高い
    • 保存コスト: $10,900/年
    • 復旧コスト: $49,550 (1PB基準)
    • 総コスト: $60,950
    • ロックイン期間: 50.0か月
  • Google Archive: 保存および復旧コストが高い → 長期保管には非効率的
    • 保存コスト: $13,200/年
    • 復旧コスト: $210,810 (1PB基準)
    • 総コスト: $224,510
    • ロックイン期間: 175.6か月
  • Microsoft Archive: 保管コストは低いが、データ復旧コストが高い
    • 保存コスト: $22,000/年
    • 復旧コスト: $40,100 (1PB基準)
    • 総コスト: $62,200
    • ロックイン期間: 20.0か月
  • ロックイン問題: データ復旧コストが高いため、データ移動が難しくなる
  • Amazon Glacier は保存コストが最も安く、復旧コストも比較的低い

Project Silica (マイクロソフトのシリカプロジェクト)

  • シリカ: 超高密度データ保存媒体
    • フェムト秒レーザーでシリカプラッターにデータを保存
    • 保存密度が高く、物理的安定性に優れる
  • コスト問題: フェムト秒レーザーのコストが高い → 大量生産による価格低下に期待
  • 読み書きの分離 → セキュリティ強化およびデータ完全性の保証
  • 読み出し速度の問題: 応答時間は15時間と予想 → 大規模システムでのみ効率的

データ復旧の問題

  • アーカイブで重要なのは データ復旧 の可能性
  • マイクロソフトはスバールバル諸島にフィルムベースのオープンソースコードを保存
    • 災害後の復旧可能性 は低い
    • 遠隔地であり悪天候のためアクセスが難しい

LOCKSSシステム (Lots Of Copies Keep Stuff Safe)

  • 低コストの保存媒体に多数のコピーを保管 → データ安全性を強化
  • バックアップと復旧は高価なシステムではなく、多数の複製によって保証される
  • コスト効率が重要 → 高価な保存媒体より安価な保存システムを好む

結論

  • アーカイブストレージの核心は 技術 ではなく 経済性
    • アーカイブ専用媒体は経済的に非効率
    • クラウドサービスは復旧コストが高く、ロックイン問題が発生する
  • 大規模データセンター で運用してこそ、長期保存コストを削減できる
  • Project Silica はアーカイブストレージ技術の中で最も有望だが、商用化には時間が必要

1件のコメント

 
GN⁺ 2025-03-18
Hacker Newsの意見
  • AI、量子コンピューティング、6K画面、M2 NVMe、数十億台のネットワーク機器がある一方で、一般的なデータはディスク故障、SSDの不安定さ、ビット腐敗などにより、せいぜい5年程度しか持たない可能性がある
    • これを乗り越えるには、JBOD、RAID、NASを継続的に維持するか、M-Disc Blu-rayに焼くか、クラウドに任せるか、その両方を行う必要がある
    • 単純な3-2-1バックアップ戦略が運よく機能することもあるが、大規模なデータアーカイブは依然として難しい
  • 「数百年」という問題について考えてきたが、確実に機能しそうな方法は次のとおり
    • 素材に刻む、または型押しする(石板、エジソン・シリンダー、シェラック78回転盤、レコード、ボイジャーのゴールデンレコードなど)
    • 紙にインクで印刷する、またはパンチする(本、カード、テープ)
    • 写真、マイクロフィッシュ/マイクロフィルム(GitHub Arctic Code Vault)、リソグラフィー
  • 最近、アーカイブ等級のマイクロフィルムを「印刷」する方法を調べたが、いくつか選択肢はあるものの、大半はマイクロフィルムをスキャンしてデジタルコピーを作るものだった
    • 個人的な経験では、2年生のときに描いた鉛筆画のほうが、デジタル資料より何百年も長く残る可能性が高い
  • 企業規模では、コスト計算が個人規模とは異なることがある
    • Linear Tape-Openは、ペタバイト単位で保存しなければならない場合には安価な保存媒体である
    • ドライブのコストで400TB分のハードドライブを買える
    • 大量生産されたハードドライブのほうが、LTOテープより信頼性が高いと思う
    • 個人的にはテープの体験はあまり良くなかった
  • 「スヴァールバル諸島で1969年の夏に地質調査をした」というメモが、著者についてもっと知りたくさせ、その経歴は非常に興味深い
  • クラウドストレージをバックアップに使うときは、Object Lockを有効にするのを忘れてはいけない
    • オフライン保存ほど良くはないが、R/Wメディアよりはるかに良い
    • 会社ではresticを使ってB2にバックアップしており、毎回重複排除バックアップを実行している
  • 3-2-1バックアップ戦略を使っている
    • データの3つのコピーを2種類の異なるメディアに保存し、1つのコピーはオフサイトに保管する
    • 重要なデータはSSDにミラーリングし、Blu-rayのコピーを複数保管している
    • Blu-rayを使う理由は、1859年のキャリントン・イベントのような地磁気嵐から守るため
  • テープアーカイブがもっと手軽に利用できればよいのにと思う
    • ニッチ市場で主に企業向けのため、ドライブは数千ドルからで、容量を減らすと現代のSSDより少ない
  • 記事はいろいろな話題を扱っており、単一の結論を出しにくい
    • Backblaze CTOの引用で締めくくられている: 「故障を前提にし、最も安い部品を買え」
    • 大企業には向いているが、個人や小規模企業には向いていない
    • 個人的には、安価な外付けハードドライブにバックアップし、M-DISC Blu-rayにアーカイブ保存している
  • 1991年からファイルを保管しており、さまざまな形式へ移行してきた
    • 3-2-1バックアップ戦略を使い、すべてのファイルを年2回チェックサムで検証している
    • スクリプトを使えば、毎週いくつかのコマンドで簡単に処理できる
  • LOCKSSについて意見を求める
    • LOCKSSは、データは最近確認されていなければ実際には存在しない、という考え方を真剣に受け止めているようだ