ハクソク

世界を動かす技術を、日本語で。

バックアップは簡単ではない

2026年9月17日原文(filipovski.net)

概要

  • バックアップの重要性と複雑さについて解説
  • データ損失のリスクと実体験による教訓の共有
  • 効率的なバックアップ戦略（スナップショット、GFSローテーション、重複排除など）の説明
  • バックアップ運用の落とし穴と実践的な注意点
  • 最終的に信頼できるツールの利用とリストアテストの重要性を強調

バックアップは単純ではない

  • データ損失 は誰にでも起こり得る現実
  • すべての写真を1つの外付けHDDに集約し、 バックアップ未実施 という失敗体験
  • 機器の故障や盗難、データの腐敗など、 多様なリスク が存在
  • バックアップの第一原則は「 重要なデータは一箇所に置かない」こと

バックアップの基本戦略

  • 単なる ミラーリング （RAID 1等）は誤操作やランサムウェアに無力
  • スナップショット方式 による時点復元の必要性
  • バックアップ頻度 （RPO: Recovery Point Objective）の設定
    • 金融機関なら30秒未満、中小企業なら24時間などケースごとの違い
  • スナップショットを ローテーション し、ストレージ消費を抑制
    • 直近は高頻度、過去は低頻度で保存する GFS（Grandfather-Father-Son）ローテーション

効率化と複雑化

  • 重複排除 （deduplication）により同一ファイルの無駄な保存を回避
    • 変更が少ないファイルは ハードリンク で参照し、ストレージと帯域を節約
  • rsnapshot のような インクリメンタルバックアップ の活用
  • ネットワーク越しのバックアップでは 帯域節約 がコスト削減に直結

運用上の課題

  • 権限問題 （例：Dockerコンテナでroot所有ファイルがバックアップできない）
  • データベース はメモリ上の情報をディスクに書き出すタイミングに注意
    • バックアップ時に DBダンプ が必要
  • メディア障害 対策として異なる種類のストレージへ複製
  • オフサイトバックアップ （クラウドや家族宅等）による災害対策

3-2-1バックアップルール

  • 3つのコピー を
  • 2種類のメディア に
  • 1つはオフサイト で保管

クラウドバックアップの現実

  • Amazon S3 等のオブジェクトストレージでは
    • メタデータ消失 や 小ファイル大量アップロードの高コスト が課題
  • tarball でまとめてメタデータ保存＆コスト削減
  • 50MBごとに分割する等の工夫が必要だが、 安全性確保は難易度高

専用ツールの活用

  • Borg や Restic のような
    • 暗号化
    • チャンク単位の重複排除
    • チェックサム
    • GFSローテーション
    • クラウド対応
    • など、 多機能なOSSツール を推奨
  • 自作バックアップ は精神的負荷が高すぎるため非推奨

リストアテストの重要性

  • 定期的なリストアテスト （半年に一度など）による信頼性確保
  • バックアップは 実際に復元できてこそ意味がある

おまけの注意点

  • バックアップの実行時刻 にも注意（2時や3時は避けるのが無難）

以上が、 バックアップ運用の現実と実践的な知見 のまとめ。信頼できるツールの活用と、リストアテストの徹底が最重要ポイント。

Hackerたちの意見

「暗号化されていて、チャンクレベルで重複排除されて、GFSローテーションされて、時点アーカイブされて、クラウドで、3-2-1バックアップソリューション」っていうのが今の新しいパスワードだよ、カンマなしでね。（誰にも言わないで！）

└

ローテーションのoを0に変えたら、安全なパスワードになるかもね。

人生でデータ損失の悲しい経験をしたのは4回ある。最初は、家の外の電柱が雷に直撃されたとき。今まで聞いた中で一番大きな音だったし、電流が電話線を通って内部のファックスモデムに流れ込み、周りのものを全部壊しちゃった。10歳の時だった。バックアップは取ってたけど、フロッピーだけで、全部はカバーできてなかった。次はOneDriveにデータを保存してたとき。彼らの「ライフタイム」に関する規約の変更があって、クライアントがダウンロードにすごく時間がかかるせいで、ほとんどのファイルを失っちゃった。3回目は、旅行中のデジカメのSDカードが壊れたとき。コントローラーチップが壊れて、カードが全く認識されなくなった。新しいソニーの128GBカードで、東芝製だったんだけど、これがよくある問題みたい。今は2枚のカードに同時に撮影してる。4回目は…バックアップをしているとき。間違ったスクリプトが元のデータを消しちゃって、新しいバックアップのために既存のバックアップも消しちゃった。以来、書き換え可能なメディアを使うのが怖くなったけど、バックアップ自体がリスクの高い作業だと思う。

└

「今は2枚のカードに同時に撮影してる」 ここ8年くらいで素敵な変化だね（笑）。フィルム時代にDSLR革命を経験したから。5D2や7D、リベル（iシリーズ）の時代だった。8ビット420のひどいエイリアシングで、1枚のカードに録画して祈ってたよ。マジックランタンがそのSDカードで起動してたんだ！

└

「彼らの『ライフタイム』に関する規約の変更があった」 私も中国のクラウドストレージプロバイダーで似たような経験をしたことがある。データをエクスポートする便利な方法すらなかったし、クライアントはダウンロードを100KB/sに制限してた。幸運にも、いくつかのVMでクライアントを動かして並行ダウンロードできたけど… >「間違ったスクリプトが元のデータを消しちゃった」って、バックアップのワークフローが根本的に欠陥があるみたいだね…でも、バックアッププログラムがroot権限で暴走するのが怖いから、バックアップ作業はresticを使ってsystemdの制限をかけるくらいシンプルにしてる。

└

「しばらくの間、書き換え可能メディアを使うのが不安で、写真や重要な書類のバックアップにブルーレイディスクを使おうかと思ったこともあった。でも、今はブルーレイ焼きドライブを手に入れるのが難しいみたいで、ほとんどの生産が終わってるからね。次に良さそうなのは、オブジェクトストレージサービスの「オブジェクトロック」機能かな。一定期間オブジェクトを削除できなくするやつ。」

└

デジタルメディアのためには、安定したアーカイブストレージのソリューションが本当に必要だよ。今のところ、普通の人向けには市場に何もないね。

└

OneDrive… 一つの製品にこんなに多くの失敗が詰まってるとは。

└

そういえば、iCloudの写真をバックアップしてる人いる？もしそうなら、どうやってるの？

└

バックアップはあったけど、フロッピーだけで、全部をカバーしてなかったんだ。それで90年代にハードディスクがクラッシュして、BASICプログラムを全部失った時のことを思い出した。悲しそうに座ってたら、母がフロッピーの束を渡して「何か役立つものが入ってるか見てみな」って言ってくれたんだ。そしたら、全部のプログラムが入ってた！バックアップを取って、それを忘れちゃったんだよね。どうやらバックアップの難しいところは、ちゃんと管理しないといけないってことだね…

└

第4の話からは、あんまり正しい教訓を得てないと思うよ。書き換え可能なデバイスは大丈夫だけど、別のバックアップを更新してる間は、（少なくとも）1つのバックアップは完全に外しておくべき。

3つのホストのインフラのために3-2-1っぽいバックアップを設定中で、Restic + Backrestに傾いてる。すべてのホストは同じCoreOSのセットアップを使ってる（https://github.com/ebrahim37/infra-template）。コンテナボリュームは1つの中央のvolumes/フォルダに置いて、これだけバックアップすればいい感じ。こんな風に実装する予定だよ：vps1: - volumes/を24時間ごとにhomelabにバックアップするカスタムshエントリポイントのresticコンテナ homelab: - volumes/をバックアップして、プルーニング/チェックを行い、リポジトリをオフサイトに複製するbackrestコンテナ - vps1、homelab、オフサイトからバックアップを保存するrest-serverコンテナ オフサイト: - volumes/を24時間ごとにhomelabにバックアップするresticコンテナ - homelabからのバックアップのコピーを保存するrest-serverコンテナ ただし、データベースのバックアップには注意が必要で、コンテナを停止してボリューム/データベースデータをバックアップするか、pg dumpなどを使う必要がある。重複排除はいいね、過去1年の各週のスナップショットを、すごいストレージコストなしで持てるから。

Hacker Newsで議論の続きを見る