個人バックアップにResticとBackblaze B2を選んだ

個人バックアップにResticを選ぶ

対象はBazzite Linuxをインストールした個人PCのHOMEである。Linuxで動き、再取得できるデータだけを除外でき、削除から独立したsnapshotを保持できることを要件にした。また、retention、整合性検査、restoreを自分で確認でき、保存先を特定のサービスへ固定しないことも求めた。

Resticは、ファイルを暗号化されたsnapshotとしてrepositoryへ保存するCLIバックアップツールである。重複排除に対応し、local filesystem、SFTP、S3-compatible object storageなどを保存先にできる。

既製サービスとの比較

料金は1TBを保存するために必要な契約月額へ揃えた。固定容量やunlimitedのplanは従量課金ではないため、1TBだけ使った場合も表の契約額を支払う。

Service契約月額契約容量Linux保持
Restic + Backblaze B2$6.95従量対応自分で設定
Backblaze Computer Backup$9.00unlimited非対応30日、1年も選択可能
Dropbox Plus$11.992TBsync clientは対応30日
IDrive Personal$11.995TB対応サービス側で管理

Dropbox Plusは2TBをすべて使えば約2.40/TB/月に相当する。すでに契約していて空き容量があれば追加費用はない。一方、Dropboxの同期対象で起きた削除はcloudにも反映され、復旧可能期間はversion historyに依存する。

Backblaze Computer BackupはWindowsとmacOS向けで、Linuxには対応しない。Resticでは対象、schedule、retention、検査、通知を自分で構築する必要があるが、それぞれを自分の条件に合わせられる。

出典: Backblaze Computer BackupDropbox PlusDropbox version historyIDrive

保存先にBackblaze B2を選ぶ

料金は2026年8月25日時点。1TBを30日保存し、待ち時間なしで取得を開始できるhotまたはstandard tierを比較した。request、transaction、restore時のnetwork egressは含めていない。

ServiceTier・region1TB・30日の保存料金主な注意点
Backblaze B2Pay-As-You-Go$6.9510GB無料、egressに無料枠あり
WasabiPay As You Go$7.991TB最低課金、90日最低保存
Cloudflare R2Standard$15.00egress無料、operation課金
Azure Blob StorageHot LRS、Japan East$20.00transactionとdata transferが別料金
Google Cloud StorageStandard、Tokyo約$21.42operationとdata transferが別料金
Amazon S3Standard、Tokyo$25.00requestとdata transferが別料金

B2とWasabiは公開TB単価を使用した。R2、Azure、S3は1TBを1,000GBとして、Google Cloudは約931.32GiBとして換算した。providerごとに課金単位や無料枠が異なるため概算である。

Glacierなどのarchive tierは安価だが、最低保存期間、retrieval fee、取り出し待ち時間がある。障害時にすぐrestoreを始められることを優先すると、この比較ではB2の保存料金が最も低かった。

出典: B2WasabiR2AzureGoogle CloudS3

初回snapshotでB2へ追加されたデータは約141.6GBだった。30日分は、無料枠を無視すると約0.91になる。その後のsnapshot、API transaction、為替、税は含まない。

ResticからはB2のS3-compatible APIを使用した。設定方法はBackblaze公式の連携手順にある。

消えたら戻せるかで対象を決める

文書、写真、ソースコード、未commitの変更、アプリケーション状態、ゲームのセーブデータ、Steamのuserdata、Wine・Protonのcompatdataなどを保存対象にした。

SteamやHeroic Games Launcherのゲーム本体、Flatpak本体、Podmanのimageとoverlay、開発ツールのcache、node_modules.venv、Rustのtargetなど、取得元や設定から再作成できるものは除外した。

exclude patternは縮小したdirectory treeを一時repositoryへbackupし、snapshot内のpathを照合してから本番へ適用した。

日常的に動かす仕組みを作る

Resticのwrapper、exclude、systemd user unit、host別scheduleをchezmoiで管理した。B2のcredentialとrepository passwordは暗号化して管理し、repositoryの初期化は誤作成を避けるため手動にした。

操作Schedule内容
backup毎日03:00未実行分を補完
maintenance毎週日曜05:00retentionを適用して不要なsnapshotを削除
check毎月1日07:00metadata全体とdata 5%を検査

保持数はdaily 7、weekly 5、monthly 12、yearly 3とした。各処理の失敗はjournalとdesktop notificationへ出す。

実装はdotfilesで公開している。

復旧できることを確認する

初回snapshotでは約104万file、論理サイズ約222.5GBが対象となり、B2へ約141.6GBが追加された。

  • snapshot内に必要なpathがあることを確認した
  • repository metadata全体とdata 5%のcheckに成功した
  • 代表fileを一時directoryへrestoreし、元fileとbyte単位で一致することを確認した
  • backup、maintenance、checkのtimerが有効であることを確認した

5% checkは全dataを一巡する保証はない。毎月すべてをdownloadする負担を避けながら、保存データの一部を継続的に読み取るための設定である。

記事で明示する制約

  • 稼働中databaseはfilesystem backupだけで論理整合性を保証できない
  • repository passwordとB2 credentialを別の安全な場所から復旧できる必要がある
  • macOSとWindows向けの定期実行は未実装