ダウンロードやスキャンは、重要だと見なされない限り、基本的にゴミだよね。スマホやカメラには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つあるのは、そんなに無理なお願いじゃないよ。

それが利益に大きく影響しないなら、まあいいのかな？

法的な理由で必要かも？訴訟保留は面倒だし、追加の責任を生むこともあるから、バックアップが逆に痛手になることもあるよね。

人々がプロセスや要件を過剰に考えすぎるのも、ほんと驚きだよね。

これはSOC2監査人承認の災害復旧ポリシーの副作用だね。俺が働いてた会社も似たようなことがあった。数ヶ月かけて全チームを回って、災害復旧ポリシーがどう実施されているかを調べたんだけど（全てSOC監査人に承認されてた）、分析の結果、大規模な災害が起きた場合、会社を閉じて帰る方が、合理的な時間内に復旧するよりも簡単だってことが分かったよ。

え、プロダクションデータベース、全部？ 4日分のデータを失うってどういうこと？ それってどうなるの？ お客さんは怒らないの？ あなたの話を疑ってるわけじゃないけど、何か見落としたかもしれないね。 10億ドルの会社にとって、それは大きな影響があると思うよ。

resticの話が出たけど、resticを使ってappend-onlyで時々サーバー上でプルーニングするのはダメなの？これがresticを使ってランサムウェアの問題を避けるための推奨される方法だと思ってたんだけど。

だから、リードオンリーメディア（例えばブルーレイ）を使うか、プルが必須だ。あるいは、誰かがコメントしたように、プッシュは許可するけど古いファイルには手を出せないサーバーを使うこともできる。例えば、sshをscpコマンドのみに制限して、sshサーバーがバックアップをコピーするためのchroot環境を提供することができる。そして、サーバーはそのchrootを毎日ローテーションすることもできる。プッシュは、日々のバックアップを1つだけプッシュできる。ログインもできないし、古いバックアップを上書きすることもできない。深刻なSSHの脆弱性がない限り、ランサムウェアがサーバーを再構成して全てのssh（scpだけじゃなく）を受け入れるようにしたり、chrootボックスから抜け出すことはできないから、ランサムウェアがシステムに侵入する前のデータを破壊することはない。私のバックアップ手順は、専用サーバーにある1つのバックアップサーバーのためにそれを実行してる：scpのみを受け入れるchrootされたsshサーバーだ。もちろん、これはバックアップ手順の一部に過ぎないし、バックアップのために頼りにしている唯一のものではない。追記：リードオンリーメディアを使うこととも矛盾しないよ。

最近のランサムウェアは本当に賢いし、バックアップをプッシュすると、すべてのバックアップを暗号化したり削除したりすることもできる。これはバックアップサーバーへのアクセス設定によるね。自分は Borg と Restic を使って SSH 経由でプッシュバックアップのために追加専用のバックアップを強制してるけど、ローカルバックアップセットの最後の防衛策としてオフラインバックアップドライブのローテーションも使ってるよ。人によって違うかもね。

できるだけ早く復元できるようにテストした。 それは目的によるよね？もし家族の写真のバックアップを復元するのに6ヶ月かかっても、僕はそれでいいよ。

このコメントを見て、実際に自分が持ってる価値のあるデータについて考え直した。お気に入りだけに絞っても、写真だけで数ギガはあると思う。電話の連絡先は小さいけど、それ以外は失ってもそんなにショックじゃないかな。リカバリーキーはもっと安全なところに置くべきだけど、正直言って、自分にとって一番大事なアカウントにはリカバリーキーがないんだ。みんなは何を価値のあるデータだと思ってるの？追記：今は写真が約2TBあるんだけど（趣味の写真家の宿命だね）。

明日突然死んだら、家族に何を回復してほしい？ 数十年後に孫たちに何を見せたい？それがあなたの大事なデータだよ。 何十万ものファイルを相続する必要はないかもしれないし、望んでもいないかもしれない。 でも、数枚の重要な写真や動画、テキストがあれば十分だと思うよ。

だから、バックアップには rclone sync じゃなくて rclone copy を使ってるんだ。オブジェクトを削除する権限なしで API キーを使うからね。

自分は「プル」派だから、あんまり心配してないよ。バックアップするサーバーはバックアップサーバーへの権限を持ってないべきだね。もし攻撃者がライブサーバーをルート権限で侵入できたとしても、バックアップシステムに自動的にアクセスできるわけじゃないから。

もう一つできることは、コンテナや特定のバックアップユーザーを実行することだね。systemd-nspawn を使うと、かなり軽量な chroot「監獄」を作れるし、その中にいる人が rm コマンドを実行できないようにできるよ。 pacman -S arch-install-scripts # このパッケージが必要（Debian の場合は debootstrap が必要） pacstrap -c /mnt/backups/TestSpawn base # chroot を作成 systemd-nspawn -D /mnt/backups/TestSpawn # ログイン passwd # ルートパスワードを設定。必要なことをしてから exit sudo ln -s /mnt/backups/TestSpawn /var/lib/machines/TestSpawn sudo machinectl start TestSpawn # おめでとう、machinectl で制御できるようになったよ 設定は通常の systemd のものと同じように機能するから、アクセス制御を制限したり、ファイルパスを制限したり、特定の時間にだけサービスを起動したり、ポートをリッスンしているときにアクティブにしたり、192.168.1.0/24（または 100.64.0.0/10）からのみアクセスできるようにしたり、メモリや CPU 使用量を制限したり、好きなようにできるよ。（自分は BTRFS サブボリュームも使うのが好き）本当にやりたいなら、systemd-vmspawn でフル VM を使うこともできるよ。さらに良いのは、importctl を使って複製できることだね。

僕の好みの解決策は、クライアントが新しいバックアップを書き込むだけで、削除はしないこと。 syncoidにこの機能を追加してほしいな。 スナップショットだけをバックアップサーバーにコピーしてほしい。 その後、サーバーが古いスナップショットを削除する感じで。 現在は削除権限が必要なんだよね。

それと、NASを持ってるなら、同じタイプのハードドライブを両方に使わない方がいいよ。

ハハ、その引用には笑っちゃった。Alice in Chainsのパフォーマンスを思い出したよ、似たような引用が出てきたから。BCDRソリューションについてだけど、B2B企業間の信頼も売ってるんだ。これらのソリューションは、数十億、いや数兆ドルのデータを保護していて、まともなCTOならオープンソースのバックアップと復旧のアプローチを許可することはないよ。これは主にバックアップが非常に高い可用性を必要とするからだね。スナップショットリストをスクロールするのは、システム管理者としてやらなきゃいけない中で最も面倒な作業の一つだよ。これらのソリューションは大抵は肥大化していて、ユーザースペースを侵害してるけど、最終的には企業の評判が彼らに製品を売らせるんだ。ProxmoxがBroadcomの影響を受けていることには敬意を表するけど、B2B市場に浸透できない理由について長々と語れるけど、結局はシンプルな公式に帰結するんだ（教育的ではなく、むしろ数年の現場経験からのものだけど）: > 企業のIT支出は評価額に応じて線形に増加し、ある閾値を超えると特定の範囲で指数関数的に増加し、ベンダーニュートラルでロックイン対策に投資するにつれて多項式的に成長するけど、この成長は考慮されたコスト最適化の支出策が導入されると鈍化するかもしれない。 - ランサムウェア保護: 不変性とWORM（書き込み一回読み取り多回）バックアップは、スナップショットベースのバックアップ戦略の重要な要素だよ。俺の経験では、政府のITシステムでの不遵守から法的問題が発生したことがある。BCDRベンダーが「ランサムウェア」を売上を上げるためのバズワードとして使うことが多いけど、真の不変性は、複数の場所でのデータの耐久性と可用性に依存しているんだ。ここで3-2-1バックアップ戦略が本当にその価値を証明するんだ。もっとバックアップの原則についての意見を聞きたいな！

複数の場所にバックアップを持つこと（3-2-1バックアップ！）は重要だよね。 そうだね、ほとんどの個人のサイバーユーザーにとって、その「1」はバックアップサービスにお金を払わないとほぼ達成できないよね。 それなら、なんで自分でやる必要があるの？そのサービスのロールバックバックアップやスナップショットアプリを使えばいいじゃん。 世界中に僕と違う街に住んでる人なんていないし（竜巻や洪水、山火事の時にその「1」は保護にならないし）、24時間コンピュータを動かしてメンテナンスを頼むなんて無理だよ。

"rsyncコピー"やクラッシュ整合性のあるバックアップを信頼してはいけない。 これが、データベースやファイル/オブジェクトストレージだけをバックアップすればいいという秘密の知識に導いてくれる。 他のすべては、あなたのプロビジョニングツールから再作成できる、または再作成しなければならない。 ITの人たちがドラゴンのように貯め込んでいるVeeamのVMバックアップは、価値がないよ。

3-2-1のアナロジーは古いね。今はクラウドサーバーがあるから、データを置く場所に無限の柔軟性がある。少なくともローカルにファイルシステムのスナップショットを持っておいて、手動ミスがあったときに簡単に復元できるようにしておく。実装Aを使ってリモートにコピーして、そこでスナップショットも取る。実装Bを使って別の場所にも同じ量をコピーして、そこでもスナップショットを取る。そうすれば、耐久性があるだけじゃなくて、バックアッププロセスの実装バグも軽減できる。zfsはこれにとって神の恵みで、私はBorgをセカンダリ実装として使ってるけど、ほとんどの災害には十分みたい。

一般的に言えば、データベースはこれに対して耐性があるから、ディスクのスナップショットをいつでも取るのがバックアップとして十分だよ。ただし、バッテリーのバックアップがないコントローラー上のディスクキャッシュを使っている場合は、データベースにフラッシュされた内容について嘘をつくことになるから、「電源障害」（つまり、ライブスナップショット）で不整合が生じる可能性がある。だけど、特にクラウドでは、これが問題になることはほとんどないはず。

アプリケーションの状態がデータベースの外に他の場所に保存されているかどうかは不明だね。それはキャッシュみたいなものを指してるの？（そうじゃないことを願うけど。）pg_dumpやmysqldumpは、ライブデータベースを安全にスナップショットする問題を解決するけど、何らかの形でバルクやオーバーヘッドが発生する可能性があるよ。 でも、全体的に文書化されていて理解されてることだよね。 大きなPostgreSQLデータベースの場合、バックアップ専用の読み取り専用レプリカを使うこともあるよ：レプリケーションを一時停止して、そのバックアップインスタンスに対してダンプを実行する（その時間がどれくらいかかるか、どんなゴミが残るかはあまり気にしない）そして、レプリケーションを再開する感じ。

Pythonとborgを使って災害復旧システムを作ったよ。51のブロックデバイスをSANでスナップショットして、そのスナップショットから71のファイルシステムをバックアップするんだ。全データセットはS3に同期される。もちろん、オフサイトで結果をテストしたこともあるよ。全く異なるブロックストレージにファイルシステムを復旧してVMをブートすることができたから、必要なら機能する自信はあるけど、復旧の自動化が複雑で不完全だから、あまり早くはないかも。これを共有することはできないけど、もしそんなことを考えているなら可能だし、結果は非常に低コストだよ。Borgは本当に素晴らしい。

すべての外付けディスクはSamsung T7 Shield で、少なくとも異なるロットを使うか、できれば異なるモデルを使うようにしてね。同じロットや同じモデルは、同時に故障する傾向があるから（特にデータを復元する必要があって、ディスクが重い負荷にさらされているときに）。