不適切な MOD アップデートの後、Minecraft の世界が破損します。デプロイが失敗すると、Discord ボット データベースが失われます。 VPS はオンラインですが、実際に必要なファイルはオンラインではありません。稼働時間だけではデータは保存されないため、説明したサーバーのバックアップが重要なのはまさにこのためです。
バックアップは、後で復元できるサーバー データの単なる使用可能なコピーです。約束ではありません。テストしたことのないスナップショットではありません。先月ダウンロードするつもりだったフォルダーではありません。実際のバックアップを使用すると、何か障害が発生した後にファイル、データベース、構成、場合によってはシステム全体を回復できます。
小規模コミュニティ、ボット開発者、ゲーム サーバー管理者にとって、バックアップは企業専用の機能ではありません。これらは、人的エラー、アップデートの失敗、アカウントのハッキング、ディスクの問題、不正なプラグイン、誤った削除などの通常の問題に対する基本的な保護です。プロジェクトが年中無休で実行される場合、バックアップも同様に確実に実行されるはずです。
サーバーバックアップを簡単に説明: バックアップには実際に何が含まれるのか
ほとんどの人は、バックアップとはすべてをコピーすることだと考えています。それが真実である場合もありますが、多くの場合、それは無駄です。適切なバックアップには、失うと困るデータと、サービスを迅速に復旧するために必要な部分が含まれます。
ゲーム サーバーでは、これは通常、ワールド データ、プレーヤー データ、構成ファイル、プラグイン フォルダー、カスタム アセットを意味します。 Discord ボットでは、ソース コード、環境構成、アップロードされたアセット、特にデータベースを意味します。VPS 上で これには、Web サイト ファイル、データベース、システム構成、SSL ファイル、スケジュールされたジョブ、展開スクリプトが含まれる場合があります。
重要な考え方はシンプルです。最初から再構築するのに時間や費用がかかり、ダウンタイムが発生する場合は、おそらくバックアップ計画に含まれるでしょう。
これは、すべてのバックアップにオペレーティング システム全体を含める必要があるという意味ではありません。完全なサーバー イメージは便利ですが、サイズが大きく、保存に時間がかかるため、すべての復元シナリオで必ずしも必要になるわけではありません。マシン全体のロールバックではなく、1 つのデータベース テーブルを戻す必要がある場合があります。ここで、バックアップの種類が重要になります。
ほとんどのユーザーが知っておく必要がある 3 つのバックアップ タイプ
完全バックアップでは、範囲内のすべてがコピーされます。これは最も理解しやすく、復元も簡単ですが、最も多くのストレージを使用し、作成に時間がかかる場合があります。
増分バックアップでは、あらゆる種類の最後のバックアップ以降に変更された内容のみが保存されます。これは効率的かつ高速であるため、頻繁なバックアップ スケジュールに最適です。トレードオフは復元の複雑さです。チェーン内の 1 つのリンクが欠落しているか破損している場合、回復が困難になる可能性があります。
差分バックアップでは、最後の完全バックアップ以降に変更された内容がすべて保存されます。真ん中に座っています。復元は増分バックアップよりも簡単ですが、次の完全バックアップでサイクルがリセットされるまで、時間の経過とともにストレージ使用量が増加します。
ほとんどの小規模な展開の場合、最適な設定は、1 つを永久に選択することではありません。それらを組み合わせているのです。速度、ストレージ、回復時間のバランスをとるため、毎週の完全バックアップと毎日の増分バックアップが一般的です。
サーバーのバックアップでは保護できないもの
バックアップは回復に役立ちます。これらは、セキュリティ、監視、メンテナンスに代わるものではありません。
サーバーが侵害され、攻撃者がバックアップも削除した場合、計画は失敗します。ランサムウェアが運用データと接続されたバックアップ ストレージの両方を暗号化する場合、計画は失敗します。バックアップはあっても復元をテストしたことがない場合、それが機能するかどうかはわかりません。
これが、スマート セットアップが本番環境とバックアップ ストレージを分離し、複数のバージョンを保持する理由です。現在のバックアップが 1 つあるほうが、何もないよりはマシです。復元ポイントは 1 つよりも複数の方が優れています。オフラインまたは分離されたコピーの方がさらに優れています。
ダウンタイムの多くは、インシデント中ではなく、インシデント後に発生します。技術的な欠陥が問題の 1 つです。遅くて混乱した復元プロセスの方が大きな問題です。
サーバーをバックアップする頻度はどれくらいですか?
それは、データがどれだけ変更されるか、そしてその数時間のデータが失われることがどれほど苦痛であるかによって異なります。
週に 1 回変更される小規模な個人プロジェクトを実行する場合は、毎日のバックアップで十分な場合があります。アクティブなイベントを主催する場合 マインクラフトサーバー、プレイヤーの進行状況は毎分変化する可能性があります。 Discord ボットがチケット、経済データ、ログ、ユーザー設定を 1 日中書き込む場合、6 時間の損失でも大きな問題になる可能性があります。
より良い質問は、「どれくらいのデータを失っても許容できるか?」ということです。たとえそれをそう呼ぶことはなかったとしても、それが回復ポイントの目標です。
答えが 1 日である場合は、少なくとも毎日バックアップしてください。答えが 1 時間である場合、毎日のバックアップでは十分ではありません。アクティブな環境では、多くの管理者は、頻繁なデータベース バックアップ、毎日のアプリケーション バックアップ、毎週の完全なシステム バックアップという階層化されたアプローチを使用します。
定着率についても考える必要があります。最新のバックアップのみを保持するのは危険です。破損が 3 日前から始まり、今になって初めて気づいた場合は、最新のバックアップにすでに問題が含まれている可能性があります。複数のバージョンを保持すると、クリーンなデータを回復する余地が得られます。
ゲームサーバー、ボット、VPSユーザー向けにサーバーバックアップをわかりやすく解説
ゲームサーバーの場合、一貫性が重要です。ワールドがアクティブに保存しているときにライブ ファイルをコピーすると、復元が失敗する可能性があります。一部のプラットフォームやスクリプトはこれを適切に処理しますが、一般的なルールは単純です。つまり、書きかけのデータをキャプチャしない方法でバックアップを作成することです。アクティビティが低い時間帯にスケジュールされたバックアップが役に立ちます。
のために Discord ボット、多くの場合、データベースはボット コードよりも価値があります。コードは通常、バージョン管理内に存在するか、再デプロイできます。ユーザーが生成したデータはできません。ボットがモデレーション履歴、平準化データ、チケット、サーバー設定を保存している場合は、まずデータベースのバックアップを優先してください。
VPS ユーザーにとって最大の間違いは、プロバイダーがすべてを自動的に処理すると想定していることです。スナップショットや管理されたバックアップを提供するホストもあれば、提供しないホストもあり、インフラストラクチャ レベルの障害のみをカバーするホストもあります。それは便利ですが、自分自身の間違いを防ぐことはできないかもしれません。アプリ ファイルを削除したり、データベースを上書きしたりしても、インフラストラクチャの冗長性によって魔法のようにプロジェクトが復元されるわけではありません。
そのため、実際にどのような種類のバックアップがあるかを確認する価値があります。ファイル レベル、データベース レベル、スナップショット ベース、またはフル イメージ バックアップです。名前は復元結果ほど重要ではありません。
優れたバックアップ戦略とは実際どのようなものなのか
優れたバックアップ戦略は、設計上退屈なものです。スケジュールに従って実行され、データを別の場所に保存し、複数の復元ポイントを保持し、緊急事態が発生する前にテストされます。
多くのユーザーにとって、実用的なバージョンは次のようになります。手動バックアップではなく自動バックアップ、少なくとも 1 つのオフサーバー コピー、遅延した問題を検出するのに十分な長さの保持期間、定期的な復元テストです。サービスが収益を生み出すものである場合、またはコミュニティに不可欠なサービスである場合は、失敗したバックアップが見逃されないように監視とアラートを追加します。
特にバックアップに個人データ、トークン、またはシークレットを含む構成が含まれている場合は、圧縮と暗号化も重要です。バックアップが小さいと、保存や移動が簡単になります。ストレージが公開または転送される場合、暗号化されたバックアップの方が安全です。
それでも、トレードオフはあります。バックアップの頻度が高くなると、ストレージの使用量と I/O が増加します。保存期間が長くなるとコストも高くなります。フルイメージバックアップは便利ですが、小規模なインシデントの場合は、ファイルレベルのリストアの方が速いことがよくあります。正しいセットアップとは、印象的なサウンドではなく、一貫して維持できるセットアップです。
復元テストはほとんどの人がスキップする部分です
バックアップは復元することでのみ証明されます。
ここでは、シンプルなセットアップが複雑なセットアップに勝ります。復元プロセスに 10 ページのメモが必要な場合、1 つの不足しているスクリプトに依存している場合、またはプレッシャーの下でしか覚えていない手動修正が必要な場合、回復は予想よりも遅くなります。
テスト復元では、いくつかの基本的な質問に答える必要があります。最新のバックアップを復元できますか?古いバージョンを復元できますか?どのくらいかかりますか？復元後、アプリまたはサーバーは実際に正しく起動しますか?権限、設定、データベース接続はそのままですか?
これを適切に行うためにエンタープライズ ツールは必要ありません。再現性が必要です。バックアップが自動化され、復元が実践されていれば、小規模なチームや個人の開発者であっても、信頼性の高いプロセスを構築できます。
パフォーマンスを重視したホスティング環境では、これはさらに重要です。迅速な展開は素晴らしいです。迅速な回復により、ユーザーは長い間問題に気づかなくなります。これが、ACLClouds のようなプロバイダーが単なる仕様ではなく実用的なインフラストラクチャ機能に重点を置く理由の 1 つです。
実際のダウンタイムを引き起こす一般的なバックアップミス
最初の間違いは、同じサーバーにバックアップすることです。ディスクに障害が発生すると、本番データとバックアップ データの両方が一緒に失われる可能性があります。
2 つ目は、手動バックアップに依存する方法です。手動ジョブはスキップされます。彼らは遅れます。これらはアップデートの直前に忘れられてしまいますが、それがまさに最も必要なときです。
3 つ目はデータベースを無視することです。ファイルをコピーして、それがすべてをカバーしていると思い込み、アプリの状態が最初から SQL 内に存在していたことに気づくことがよくあります。
4 つ目は、保持またはストレージの制限を決してチェックしないことです。スペースが不足したり、古いバージョンがあまりにも積極的に削除されたりすると、バックアップが静かに失敗する可能性があります。
5 つ目は、スナップショットと完全な保護を混同することです。スナップショットは便利ですが、それ自体が必ずしも完全なバックアップ戦略であるとは限りません。それらは計画全体ではなく、計画の一部である場合もあります。
最も安全な考え方はシンプルです。障害はいつかは起こると想定し、迅速かつ予測可能に回復することです。
バックアップは魅力的なインフラストラクチャではありません。サーバーの立ち上げがうまくいったら、誰もそれを見せびらかしません。しかし、プラグインが世界を破壊したり、デプロイによって設定が消去されたり、午前 2 時 13 分にデータベース テーブルが消失したりした場合、バックアップが簡単な修正と完全な再構築の違いになります。それらを自動的に保ち、別々に保ち、必要なときに確実に復元できるようにします。