ここで言及すべき点として、コンピュータや携帯電話向けに開発されている主要な Linux ディストリビューションである Manjaro の、Discourse ベースのフォーラムが壊滅的な障害に見舞われました。アップデートの不手際によりすべてのアップロードデータが失われ、その他のデータも消失したため、最終的には大規模な Discourse フォーラムをゼロから再構築することを決断したようです。単なる情報提供の投稿ですが、少なくとも meta* コミュニティに知らせておくことは興味深いことです。詳細が不足していることについては申し訳ありません。おそらく、彼らのフォーラムで議論を続ける価値があるかもしれません。![]()
それはひどいですね。しかし、もし /var/discourse/shared のすべてを失ってしまったなら、彼らはもうどうしようもありません。
バックアップを S3 にプッシュするのは良い考えです。Backblaze には無料で最大 10GB までアップロードでき、それ以降もまだ安価です。
はい、S3(または S3 互換)の自動バックアップアップロードを設定したいでしょう。デフォルトでは週 1 回です。
その影響を警告するダッシュボードを表示し、手動で閉じる必要があるのは価値があるでしょうか?
インストールがサーバー外への自動バックアップ送信に設定されていないようです。
基本的な災害復旧(DR)や本番リリースのプロセスを理解していないサイトが増えているようです。ステージングコピーでのテストを面倒がって行わない人もいることは理解できますが、復元できるものがないサイト所有者に対しては、私たちも何もできません。
たしかに、Web ブラウザから定期的にバックアップを手動でダウンロードすることもできますし、お好みのローカルバックアップスクリプトを実行させるなどの方法もあります。
ただし、S3 サポートが「S3 互換」になり、さまざまなサービスに対応できるようになったことで(@falco さん、ありがとうございます!)、自動バックアップが Amazon に縛られることはなくなりましたので、状況は少し改善されています。
クラウドに関するこの種の議論は、フラットインストールがどれほど脆弱であるかを人々が忘れさせてしまうと思います。
$5 の VPS であれ、$500 のインフラであれ、あるいは $5000 であれ、関係ありません。サーバー外へのバックアップを送信しておらず、理想的には画像の保存に S3 を使用していない場合、すべてが /var/discourse/shared に存在し、すべて失われる可能性があります。
データが複数のデバイスに分散されている必要があることを知らない人たちに、それを教えることは難しいと思います。OS を開発している人がデータを単一のデバイスしか持たず、何かしらの方法で修復できると想定している可能性に気づくまでには、私自身もかなり時間がかかりました。しかし、誰も私に尋ねてくれませんでした。![]()
私の今後のタスクリストには、自動化されたインストールに Backblaze のサポートを追加することが含まれています。小規模なサイトの場合、10GB までのバックアップを無料で保持することができます。
問題は、まだすべての画像(アバターなど)が S3 を介して保存されていないことです。