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

自分だけのバックアップシステムを作る – 第1部: スクリプトの前に戦略を立てる

概要

  • バックアップ の重要性と過小評価されがちな現状
  • クラウド利用時の 責任分担 とデータ保護の誤解
  • 効率的なバックアップ戦略の 設計と実践 方法
  • 全体バックアップ個別ファイルバックアップ の利点と欠点
  • 一貫性確保のための スナップショット活用 と運用指針

バックアップ:単なるコピーを超えて

  • バックアップ は多くの人に過小評価されている現状
  • 不適切な技術や「シュレディンガーのバックアップ」(テストされていないため有効か無効か不明)の蔓延
  • RAID はバックアップではないという誤解
  • クラウド利用時の「インフラは守るが、データ保護は利用者責任」の Shared Responsibility Model
  • 他社クラスタやKubernetesなどの分散システムで「バックアップ不要」と誤認されがち
  • データは一時的なものではなく、 あらゆる手段で保護 が必要
  • データは オープンな形式迅速なリストア一貫性 が必須条件
  • 実際に経験したデータ損失例:火災、洪水、地震、ランサムウェア、悪意ある破壊、管理者のミス
  • インターネット接続サーバー(ECサイト、メール)では データ整合性とサービス継続 がより重要

バックアッププラン:正しい問いかけ

  • バックアップ前に 計画 と「正しい問いかけ」が不可欠
    • どれだけのリスクを許容できるか
    • どのデータを守る必要があるか
    • データ喪失時の許容ダウンタイム
    • 利用可能なストレージ容量
  • バックアップを同一マシンに保存 するのは危険
  • USBドライブ等も 信頼性が低い
  • UPS(無停電電源装置) も万能ではない
  • 最も安全なバックアップは 物理的に離れた場所 にあるもの
    • しかし 帯域や容量制約 が発生
    • オフラインで「触れられる」バックアップも重要
  • 完全な解決策はなく、 ニーズに合った方針策定 が必要

コアな選択:ディスク全体 vs 個別ファイル

  • ディスク全体バックアップ
    • メリット
      • システム全体の 迅速な復旧
      • 仮想環境での 柔軟な運用
      • Proxmox等では 個別ファイル抽出 も可能
    • デメリット
      • 物理マシンでは ダウンタイム発生
      • 大容量化 しやすい
      • 非標準ファイルシステムでは 互換性問題
  • 個別ファイルバックアップ
    • メリット
      • tar, cp, rsync等の 標準ツール利用
      • 差分管理 や部分復旧が容易
      • 圧縮・重複排除 が柔軟
      • 稼働中でも実施可能
    • デメリット
      • シンプルなコピーでは 大容量化
      • 一貫性確保には スナップショット が必要
      • 潜在的な問題が 復旧時に判明 することも

一貫性確保:スナップショットの力

  • 「ライブ」なファイルシステムのバックアップは 一貫性欠如のリスク
  • 実例:MySQL等の 稼働中DBのファイルコピー は復旧不能
  • スナップショット で「時点」の整合性を確保
  • 代表的な手法
    • BTRFS/ZFS等のネイティブスナップショット
    • LVMスナップショット
    • DattoBD等の専用ツール
  • スナップショット自体の 安定性や運用課題 にも注意

バックアップ方式:PushかPullか

  • Push(クライアント主導)Pull(サーバ主導) の議論
  • 一般的には Pull方式 を推奨
    • セキュアな専用サーバで 一元管理
    • バックアップサーバは 外部から到達不可・堅牢化
    • クライアントが侵害されても バックアップ消失を防止
  • Push方式利用時も アクセス制限サーバ側スナップショット でリスク軽減

良いバックアップシステムの指針

  • 迅速な復旧と高い処理速度
  • 外部ストレージ への保存(ローカルスナップショットも有効)
  • セキュリティ重視 (DropboxやGoogle Drive等の汎用クラウドは避ける)
  • 効率的な容量管理 (圧縮・重複排除)
  • 最小限の追加コンポーネント で運用可能

結論と今後

  • バックアップのアプローチは 多様
  • 本シリーズでは バックアップサーバ構築や主要なソフトウェア・手法 を解説予定
  • 次回は FreeBSD で構築するバックアップサーバについて紹介

Hackerたちの意見

バックアップシステムはいらないんだ。家族4人分の25年分の写真を、各自のスマホやカメラ、ダウンロード、スキャンとかで整理する標準的な方法が欲しいだけなんだけど、まだいいの見つけてないんだよね。

ダウンロードやスキャンは、重要だと見なされない限り、基本的にゴミだよね。スマホやカメラにはNextcloudを設定して、自動的に自宅ネットワークに同期させるのがいいよ。その後、別のディスクに夜間バックアップを取って、終了後に健康チェックをするのがオススメ。そうすれば、信頼できるクラウドホストを選ぶか、他のサーバーに別のドライブを置いて、2つ目のバックアップの場所を確保すれば完璧だよ。

syncthingを使ってるよ…それが目的にはすごく良い。Androidは公式にはサポートされてないけど、フォーク版があって、ちゃんと動くよ。写真のバックアップにはente.ioやimmich(自己ホスト版もあり)と組み合わせるのもいいかも。ドキュメント(PDFやTIFFみたいな)と写真は分けて考えた方がいいと思う。paperless ngxもあるしね。

最近、Nextcloudが家族の写真をNASに「集める」のに十分だってわかった。それに、NASはresticを使ってクラウドに暗号化バックアップをしてるよ。

ente.ioをチェックしてみて!めっちゃいいよ!

俺も苦戦中。俺の場合は、1台のMacでBackblazeを使ってる。全部そのマシンにダンプしてる。念のために外付けドライブのバックアップも取ってるよ。

Immich を動かしてる NAS かな?

自分は Immich を使った NAS を試してて、メディアと Immich の DB ダンプを毎日 AWS S3 Deep Archive にバックアップしてるよ。Android と iOS のアプリもあって、Google フォトの機能セットも十分にあって満足してる。デスクトップに写真やスキャンを同じ NAS に保存して、Immich がそれを拾ってるか確認できるし(その後、バックアップスクリプトが Immich にインポートされたらキャッチするよ)。HN ユーザーにとっては、設定はかなり簡単だよ。

「25年分の写真」って、北米のデータの測り方なの?前に聞いたことなかったな。bambaxが言ってた通り、バックアップシステムは絶対必要だよ。まだ気づいてないだけなんだ。デバイス間でデータを共有する方法も欲しいよね。何を探求しているのか、選んだベンダーによる制約もあるから、具体的なアドバイスは難しいけど。ちなみに、俺はgnu/linux、Microsoft Windows、Androidでsyncthingを使って、いくつかのコレクションをメッシュ状に管理してる。2つの専用アーカイブターゲット(小さいメモリ・大きいストレージのDebian VM)に戻して、定期的にborgbackupでスナップショットを取ってる。これでバックアップとアーカイブができるんだ。俺のRPOは24時間だけど、もっと短くすることもできるよ。Appleのスマホやタブレットが関わると、この方法は使えないと思う。デバイスでバックグラウンドタスク(syncthing)を実行できないからね。(俺は約500GBの写真と、10GBから200GBのドキュメントや雑多なファイルのコレクションを持ってるけど、これらは大きな変化がないから、ほとんどインクリメンタルな差分で済むから、差分ベースのバックアップシステムにはかなり優しいよ。)

PhotoPrismやImmichは、重複排除を処理して、家族の写真に対して良い検索やタグ付けを提供する、しっかりした自己ホスティングのオプションだよ。クラウドなら、Backblaze B2 + Cryptomatorで、約$1/TB/月で暗号化されたストレージが手に入るし、アップロード用のDIYスクリプトも使えるよ。

まだいいものは見つけてない。 pCloudを何年も使ってるけど、問題はないよ。 それに、外付けの「遅い」ストレージドライブも今はかなり安いから、人生の大事な画像や文書がかかってるなら、第三のバックアップとして使うのもアリだよね。 大事な写真や文書は複数の場所にコピーを持っておくのがベストだよ。 家は洪水や火事に遭うこともあるし、コンピュータやストレージも故障することがあるからね。 過度に心配する必要はないけど、大事なもののコピーが2つあるのは、そんなに無理なお願いじゃないよ。

人々がバックアップについて全然気にしないって、ほんと驚きだよね。個人だけじゃなくて、大企業もそうなんだ。年商約10億ユーロの会社にコンサルしてるんだけど、彼らは自分たちでバックアップを取ってないんだ。データセンターのオペレーターがランダムに作るディスクコピーに頼ってるけど、それも自分たちでテストしてない。最近、ユーザーエラーで本番データベースが壊れちゃったんだ。最新の「バックアップ」は4日前のものだった。それで、その4日間に行われた全取引を再生しなきゃいけなかった。マジでクレイジーだよ。でも一番クレイジーなのは、誰もその事件にショックを受けてなかったこと。「いつも通りのビジネス」って感じみたい。

Hacker Newsで議論の続きを見る