- バックアップの重要性はしばしば過小評価されがち
- 多くの人がクラウド依存に安住し、データ保護の責任を十分に認識していない
- バックアップ計画を立てずに単純なコピーに頼ると、高いリスクを招く
- ディスク全体または個別ファイルのバックアップ方式には、それぞれ長所と短所がある
- 信頼できるバックアップの鍵は、スナップショットの活用と外部ストレージの確保
バックアップの重要性と現実
- バックアップは、多くの人が深刻に捉えていない分野である
- 間違った方法や概念上の誤り（例: RAIDはバックアップではない）により、膨大なデータが失われてきた
- データは必ずさまざまな方法で保全されるべき重要な資産である
クラウドとバックアップに関する誤解
- クラウドにすべてのデータを預けながら、実際にデータがどのように保護されているのかを問わないことが多い
- 主要なクラウドプロバイダーも共有責任モデルを採用している
- インフラのセキュリティは提供するが、データ保護の責任は利用者が負う
- クラウド、プライベートサーバー、Kubernetesなどの環境でも、バックアップ不在のリスクは頻繁に見られる
筆者のデータ復旧経験
- データセンター火災、サーバールームの浸水、地震、ランサムウェア、悪意ある攻撃、管理者のミスなど、さまざまなデータ損失事例を経験してきた
- インターネットに接続されたサーバー（eコマース、メールなど）では、データ整合性とサービス継続性の両方が重要である
- バックアップは単なるコピーではない。特に稼働中のデータベースファイルをコピーすることは、復旧不能になる可能性を高める
バックアップ戦略策定で欠かせない質問
- 「どれだけのリスクを受け入れるのか？」「どのデータを保護すべきか？」「データ損失時に許容できるダウンタイムは？」「利用可能な保存容量は？」
- バックアップを同じマシンに置く方式は、マシン障害時には役に立たない。外部ストレージへのバックアップが安全である
- ネットワーク帯域幅、復旧速度、保存容量など、現実的な要素も考慮する必要がある
ディスク全体 vs ファイル単位のバックアップ
ディスク全体のバックアップ
- 長所
- 完全復旧が可能。システムを以前の状態へ迅速に復旧できる
- 仮想化システムと組み合わせると有用。Proxmoxなどはこの種の全体バックアップを容易にサポートする
- 一部のソリューションは、全体バックアップから個別ファイルの復旧もサポートする
- 短所
- 物理サーバーではダウンタイムが必要になる
- 容量消費が大きく、不要なデータまで保存される
- ファイルシステムの特性によっては遅かったり、互換性の問題が発生したりする
個別ファイルのバックアップ
- 長所
- システム標準ユーティリティ（tar、cp、rsyncなど）で実施できる
- 変更分だけをバックアップして、容量と転送量を削減できる
- 個別復旧、移動、圧縮、重複排除などの柔軟性を確保できる
- システム停止なしで運用できる
- 短所
- 単純コピーは多くの保存容量を必要とする
- スナップショットなしで稼働中のファイルシステムをバックアップすると、不整合やエラーが発生する可能性がある
スナップショットを活用したバックアップ
- バックアップ対象が稼働中のファイルシステムである場合、バックアップの「開始」と「終了」の間にデータが変更されるため、データ一貫性が損なわれることがある
- MySQL、ブラウザ履歴などの開かれているデータベースは、ファイルコピーだけでは復旧できない場合がある
- 一貫性のあるバックアップを保証するには、まずファイルシステムのスナップショット機能を活用しなければならない
- 代表的な方法
- ネイティブなファイルシステムスナップショット（BTRFS、ZFS対応システム）
- LVMスナップショット: 容量の無駄が生じ、スナップショット削除時にシステム停止の可能性がある
- DattoBD: ときどき安定性の問題が発生するものの、UrBackupなどと組み合わせて活用できる
バックアップ方式: Push vs Pull
- Push: バックアップ対象がサーバーに接続してデータを送る
- Pull: 中央バックアップサーバーが各サーバーに接続してバックアップを実行する
- セキュリティ面では、バックアップサーバーは外部からの接続を遮断し、必要なときだけクライアントにアクセスするPull方式の方が安全である
- 侵入やランサムウェア発生時にバックアップデータの削除を防ぐため、バックアップサーバー自体のスナップショットも別途長期間保管する
推奨バックアップシステムの主な特徴
- 即時復旧と高速処理
- 外部ストレージに保管（ただし、ローカルスナップショットは即時ロールバック用として維持）
- Google Drive、Dropboxなど商用クラウドは不使用を推奨。データは自分で保有すべき
- 圧縮、重複排除などによる効率的な容量管理
- 動作に必要な追加コンポーネントは最小限であるべき
今後の連載予定
- さまざまなバックアップシナリオと、実際に使用しているサーバー、主要な設定、各種ソフトウェアや技術を紹介する予定
- 次回はFreeBSDベースのバックアップサーバー構築方法を扱う予定
1件のコメント
Hacker Newsの意見
バックアップを必ず「プッシュ」方式で行う必要があるマシンは、自分の領域にしかアクセスできないよう制限する必要があり、さらに重要なのは、バックアップサーバー側がセキュリティのために独自のファイルシステムスナップショットを一定期間保持することです。そうすれば、ワークロードが侵害され、バックアップサーバーにアクセスして身代金目的でバックアップを消された最悪のケースでも、サーバー側にスナップショットが残ります。私が好む方法は、クライアントには新しいバックアップの書き込みだけを許可し、削除は一切できないようにすることで、削除は別手順（手動やcronなど）で処理します。この方式は rsync/ssh で
.ssh/authorized_keysの allowed command 機能を使って実現できます私は両方を使っています。バックアップは2か所に保存すべきですが、このデュアルバックアップ構成はもともと目指していたものです。バックアップ元は中継地点にプッシュし、主要なバックアップストレージがそこからプルします。中継地点は容量が小さく、スナップショットは保持しますが、主要ストレージとバックアップ元は互いにまったく認証できません。つまり、それぞれ中継地点に対してのみ認証可能で、逆方向の認証もありません。この3か所のうち1〜2か所が侵害されても、残りは安全である可能性が高いです。証明書のバックアップは完全に別管理にして、インターネット接続されたサーバーにすべて保存されることがないようにしています。本当に重要なデータは追加措置としてオフラインバックアップまで二重化しています。構造を分離したことで、実際のバックアップ検証は面倒になりますが、バックアップストレージが定期的にチェックサムを検証し、その結果を中継ホストに送り、元ホストで生成したハッシュと比較して破損イベントを検出しています。こうして、バックアップ元からバックアップスナップショットそのものを直接傷つけられない、一種の「ソフトオフライン」バックアップを実現しています
別のコンテナやバックアップ専用ユーザーを使うのも一つの方法です。systemd-nspawn を例にすると、軽量な chroot jail のように使え、内部では
rmの実行自体を禁止できます。pacman/pacstrap などで chroot を作り、systemd-nspawn や machinectl で管理します。この方式は普段の systemd と大差ない感覚で、アクセス制御、ファイルパス制限、メモリ/CPU 制限、特定 IP 帯域のみ許可、起動条件の細分化など、さまざまな制御が可能で柔軟です。BTRFS サブボリュームなども活用でき、必要なら systemd-vmspawn でシステム全体を完全分離することもできます。importctl による複製自動化も非常に便利です私は「バックアップサーバーがバックアップ対象サーバーに対して一切の権限を持たない」プル方式を好みます。稼働中サーバーが root 権限まで侵害されても、バックアップシステムには影響しません
バックアップには rclone copy を使っていて、オブジェクト削除権限のない API キーだけを使っています。rclone sync のように同期すると消してしまう可能性があるので、こちらの方が安全です
syncoid にも「クライアントはスナップショット/バックアップのコピーだけを行い、削除はバックアップサーバーが直接管理する」オプションがあればよいのですが、現状では削除権限を与える必要があるのが残念です
驚くほど多くの人がバックアップを重視していません。大小さまざまな企業で同じです。私がコンサルしている年商10億ユーロの会社でさえ、自前のバックアップがなく、データセンター事業者が不定期に行うディスクコピーだけに依存していました。復旧テストも自分たちで一度もしたことがありません。少し前にユーザーのミスで本番DBが完全に消え、最新のバックアップが4日前のものだったため、その間のトランザクションをすべて再現しなければなりませんでした。しかも、そんな事故があったのに誰もショックを受けず、何事もなかったかのように過ぎていきました
それがビジネスに本当に致命的でない限り、問題ないと思っているようです
バックアップ要件を過剰に複雑にしてしまうのも、よく見る現象です
もしかすると法的な問題が理由かもしれません。訴訟や法的保全義務のため、バックアップ自体がむしろリスク要因になることもあります
SOC 2 監査を通した災害復旧ポリシーの副作用です。私が勤めていた会社でも、全チームの災害復旧ポリシー（すべて SOC 2 承認済み）を点検しましたが、結論として、本当に大規模な事故が起きたら、正常復旧を試みるより会社を畳んで家に帰る方が早い、という結論に至りました
本番DB全体で4日分のデータ損失が本当に事実なら、顧客は怒らなかったのでしょうか。その規模の会社では現実的にものすごい打撃だと思うので、実際どう処理したのか気になります
内容の共有ありがとうございます。10年間バックアップ・災害復旧ソフトウェアを開発してきて、いつも出てくる決まり文句は「友人にはバックアップ/災害復旧ソリューションを自作しろとは勧めない」です。BCDR の構築には見落としやすい落とし穴が非常に多いです。いくつか重要な点を共有したいと思います。バックアップは「災害復旧」ではありません。本当の事故が起きたとき、数分〜数時間で即座に復旧できてこそビジネスの信頼を守れます。重要なのは復旧時間目標（RTO）と復旧時点目標（RPO）です。rsync copy のようなファイル複製だけではファイルシステムが継続的に変化するため、ポイントインタイムバックアップにはなりません。適切なポイントインタイムバックアップには「クラッシュコンシステント」または「アプリケーションコンシステント」なバックアップが必要で、後者は重要アプリケーションがディスクに状態を書き出し、バックアップ中は停止する設定です。Microsoft VSS のような機能がこの部分を提供します。rsync copy やクラッシュコンシステントバックアップを決して過信してはいけません。ストレージには常にマーフィーの法則が働くので、複数の場所へのバックアップ（3-2-1 戦略）が必須です。経験上、どんな種類のディスクもすべて故障します。NVMe SSD > SSD > HDD の順に耐久性は高いですが、例外はありません。まだ書きたいことはたくさんありますが、遅いのでここまでにします
3-2-1 の比喩は昔ながらのやり方です。今はデータの保管先が事実上無制限なので、ローカルスナップショット、リモートレプリケーション、さらに異なる方式での二重三重のバックアップがより重要です。私は zfs の基本スナップショットに加えて Borg も使っており、この組み合わせならほとんどどんな災害にも十分です
その決まり文句を聞いて、Alice in Chains のライブで似たようなことを聞いたのを思い出しました。BCDR ソリューションは企業間の信頼の象徴です。こうしたシステムは数十兆〜数百兆規模のデータを保護しており、CTO ならオープンソース方式に会社のバックアップを任せることは決してありません。企業の IT 支出は、資産価値や反ベンダーロックイン戦略に応じて段階的に増えていきます。専門家としての経験から言うと、ランサムウェア対策ではイミュータビリティ（immutability）と WORM バックアップが重要で、法令不遵守が原因で政府 IT に問題が生じた事例も数多く見てきました。BCDR ベンダーはランサムウェアを売り文句にしますが、真の不変性は複数の場所にまたがるデータ複製で証明されます。このとき 3-2-1 戦略が真価を発揮します。ほかのバックアップ原則についても意見を聞きたいです
NAS を使う場合、同一メーカー・同一モデルのハードディスクを両側で使わない方がよいです
「複数の場所へのバックアップ必須（3-2-1）」には完全に同意します。ただ、多くの個人にとっては「1」（オフサイト）が現実的に不可能で、結局バックアップサービスを使わない限り、自力でバックアップする理由がなくなってしまいます。自分の街の外で24時間コンピュータを動かして管理してくれる知人など周りにいません
「rsync copy や、ひいてはクラッシュ整合性バックアップさえ絶対に信頼してはいけない」という部分については、結局あらゆるシステム/サービスはインフラツールで再構築可能なので、DB とファイル/オブジェクトストレージだけを積極的にバックアップすればよい、という結論になります。複雑に VM 全体をバックアップするのは本当に意味がありません
すっきりした記事ですが、惜しい点があります。本当に優れたバックアップシステムとは、復旧速度と手順が明確であるべきだということです。何度も見たのは、バックアップ自体はうまくいっていると安心していたのに、いざ復旧時には一部しか戻らなかったり、数日以上かかって大きな損失が出たりするケースです。restic というツールは、ファイル単位で重複排除されたスナップショットバックアップが可能なので、ZFS のようなスナップショットファイルシステムがない場合に便利です。そして「プッシュ」バックアップ方式ではランサムウェアがバックアップまで削除できてしまうので、「プル」方式が適しています。プッシュにするなら、読み取り専用メディア（Bluray など）を使うか、少なくとも auto-snapshot/ZFS で時点復旧できるようにしておく方がよいと思います
ランサムウェアがプッシュバックアップまで削除できるとしても、サーバー権限を適切に制限していれば問題ありません。Borg と Restic は ssh で append-only を保証でき、ローカルではオフラインバックアップドライブを最後の防衛線としてローテーションしています。実際の方法は こちら を参照してください
restic の append-only モードで、定期的な pruning をサーバー内部でのみ行うなら、pull 方式を使わなくても大丈夫なのか気になります。これが restic 公式推奨のランサムウェア対策だと理解しています
「復旧速度」は本当に要件次第です。家族写真のバックアップなら、復旧に6か月かかっても私は構いません
読み取り専用メディアの代わりに、権限を制限した push サーバーも代替になります。たとえば ssh を scp のみに制限し、chroot 環境内だけにして、毎日フォルダをローテーションしてバックアップすれば、ランサムウェアでも過去データは削除できません。私のバックアップ手順も chroot + scp のみ許可した ssh サーバーで運用しており、さらに読み取り専用メディアも併用しています
私は別個のバックアップシステムが必要なのではなく、家族4人分の25年分の写真（スマホ、カメラ、ダウンロード、スキャンなど）を効率よくまとめておける標準化された方法があれば十分だと思っています。まだ満足できる方法は見つかっていません
私は NAS 上で Immich を動かしていて、メディアと Immich の DB ダンプを毎日 AWS S3 Deep Archive にバックアップしています。Immich は Google Photos 的な機能も十分備えており、デスクトップの写真やスキャンを NAS に追加しておけば Immich が自動で取り込みます。HN ユーザーならセットアップは難しくありません
「25年分の写真」は北米式のデータ単位なのかと冗談を言いつつ、実際にはバックアップシステムが必須だと指摘しています。私は syncthing を gnu/linux/windows/android でメッシュ運用し、2つの Debian VM にアーカイブを定期スナップショットし、borgbackup で二次バックアップしています。RPO は24時間ですが、その気になればもっと短くできます。ただし Apple デバイスでは syncthing がバックグラウンドで動けないため、この構成には向きません。私の場合、写真は500GB、その他の文書も数十〜数百GBありますが、diff ベースのバックアップのおかげで効率的です
ダウンロードやスキャンは、本当に重要でないならどうせ捨てるデータです。スマホやカメラは Nextcloud で同期し、バックアップは自宅ネットワーク内でのみ動かしています。その後 NAS 側で毎日バックアップとヘルスチェックを行い、最後の段階として信頼できるクラウドバックアップか、別の家に置いたドライブを使います。これで二次バックアップまで完成です
PhotoPrism や Immich のようなセルフホスト型ソリューションは、写真の重複排除や検索/タグ付けに便利です。クラウドバックアップは Backblaze B2 + Cryptomator の組み合わせで、暗号化ストレージと DIY アップロードスクリプトが使えます。TB あたり月 1 ドル程度です
私は syncthing を使っています。公式には Android 非対応ですが、フォーク版を使えばうまく動きます。加えて ente.io や self-hosted の immich で写真バックアップを勧めます。文書は paperless ngx などで別管理した方がよいです
Dirvish はぜひ一度試す価値のある軽量 rsync ラッパーで、ローテーション、増分、保持、前処理/後処理スクリプトなど優れた機能を提供します。20年以上にわたって私のデータを救ってくれました。記事で挙げられている点とも非常に相性が良いです。dirvish 公式サイト, rsync 公式サイト
私はかなり怠惰なやり方でも、ハードウェア故障や盗難の問題まで全部カバーできています。デスクトップ内部の一時保存、自宅の外付けディスク、オフサイトの外付けディスク（すべて Samsung T7 Shield）の組み合わせです。robocopy /MIR で毎日一時領域または作業後に複製し、週1回外付けにバックアップし、月1回外付けのオフサイト分を入れ替えています
タイミングが良かったので、自分の archlinux 設定とバックアップ戦略を共有します。設定/バックアップ自動化スクリプト, borg 自動化レイヤー も公開しています
私の持つ貴重なデータは 100MiB 未満なので、選んだパスだけを tar + 圧縮 + 暗号化して週2回バックアップし、数か月分だけローテーション保持しています。家の内外に置いており、点検や保守もほとんど要りません。数行の sh スクリプトだけで問題なく自動化できる無難な構成です
明日自分が突然死んだとしたら、家族や子孫が本当に復旧する価値のあるデータは何かを考え直すべきです。数十万ファイルより、核心的な写真、動画、テキストが少しあれば十分かもしれません
このコメントを見て、自分にとって本当に貴重なデータは何かを改めて考えさせられました。私の写真は圧縮しても少なくとも数 GB あり、連絡先や重要でないものは小さいですが、たいてい他のものは失っても構いません。復旧キーはもっと安全に保管すべきですが、最も重要なアカウントにはむしろ復旧キーがありません。写真だけでも 2TB 近くあります（趣味で写真を撮る者の悲哀です）
バックアップ整合性で最も難しい点は、アプリケーションデータをサービス停止なしに整合性を保ってバックアップするのが、実際ほぼ不可能だということです。ディスクスナップショットでは、その瞬間にどこかのサービスが書き込み途中の状態でスナップショットされるしかなく、復旧時に壊れた状態へ飛び込む可能性が高いです。DB ダンプはこの問題をかなり緩和しますが、しばしばサービス外からバックアップする必要があるため、クエリ実行中かもしれません。このあたりのノウハウがあれば聞きたいです
たいてい DB はこの点で堅牢なので、いつでもディスクスナップショットを取ってもバックアップとしては十分だと思います。心配なのはバッテリーなしキャッシュのような特殊な状況ですが、最近のクラウドなどではそうした構成はほとんどないので、大きな問題ではありません
DB 以外にも捕捉すべきアプリケーション状態があるかどうかで戦略は変わります（たとえばキャッシュもバックアップすべきかなど）。pg_dump/mysqldump は実際にライブ DB のスナップショットを安全に可能にしますが、やや遅く、ダンプサイズが大きくなるなどの負担があります。これを避けるために、大規模な PostgreSQL DB ではバックアップ専用の read-only replica を用意し、レプリケーションを止めてからバックアップを実行し、その後レプリケーションを再開する、という方法を経験したことがあります