バックアップと更新

サーバーは、構築したあとの運用で、安全と安定が決まります。撮影や企画の素材になるワールドは、壊れたら作り直せません。
この資料では、バックアップ、更新への追従、Mod とプラグインの確認、障害と企画の当日への備えを説明します。

コマンドと設定は、2026 年 10 月時点の Java 版と Paper によります。

ワールドのバックアップ

何をどの頻度で取るか、目標復旧時点 (RPO) と目標復旧時間 (RTO) の決め方、道具、改ざんされない保管、復元、大規模なサーバーのバックアップは、バックアップの取り方で詳しく説明しています。ここでは要点をまとめます。

撮影や企画の前後と、決まった時刻に、ワールドのバックアップを取ります。ワールドの書き込みの途中に取ると、ファイルが壊れることがあるため、自動の保存を一時的に止めてから取ります。

/save-off          # 自動の保存を止める
/save-all flush    # 今の状態をすべてディスクに書き込む
# ここでワールドのフォルダを複製する
/save-on           # 自動の保存を戻す
  • 保管の場所: サーバーとは別の場所 (別のストレージ、クラウドのストレージ、別の拠点) に置く。同じディスクに置いたバックアップは、ディスクの故障や、サーバーの乗っ取りでまとめて失われる
  • 世代: 1 つだけでなく、数日分、数週間分の世代を残す。壊れたことに後から気付いても戻せる
  • データベース: 権限やインベントリを MySQL などに保存している場合は、ワールドと同じ時点のデータベースのバックアップも取る (MySQL との連動)
  • 復元の確認: バックアップから実際に戻せるかを、検証用のサーバーで定期的に試す
  • 撮影の区切り: 企画の回ごとのワールドは、撮影の前の状態と後の状態を残しておくと、撮り直しや、続きの企画に使える

更新への追従

Minecraft の更新では、サーバーのソフトウェア、プロキシ、プラグイン、Mod、Geyser が、それぞれ新しいバージョンに対応するのを待つ必要があります。どれも有志の開発のため、対応の時期はそろいません。

  • すぐには上げない: Minecraft の新しいバージョンが出ても、使っているすべてのソフトウェアが対応するまで待つ
  • セキュリティの修正は早く: サーバーのソフトウェアの同じバージョンの中の修正 (ビルドの更新) は、悪用できる不具合の修正を含むことがあるため、早めに反映する
  • 検証用のサーバー: 更新は、本番と同じ構成の検証用のサーバーで、プラグインと Mod の動きを確かめてから反映する
  • 戻せるように: 更新の前にバックアップを取る。Paper の 1.21.4 以降のように、Spigot に戻せない変更もあるため、更新の内容を確かめる
  • Java のバージョン: 26.1 から Java 25 が必要になったように、Java も合わせて上げることがある

Mod とプラグインの安全の確認

2023 年 6 月には、配布サイトの作者のアカウントが乗っ取られ、人気の Mod とプラグインの更新にマルウェアが仕込まれる事案 (fractureiser) が起きています。サーバーに入れるプラグインも、参加する方の PC に入る Mod も、同じように確認します。

  • 一覧: 使っているプラグイン、Mod、そのバージョン、入手元を一覧にする
  • 入手元: Modrinth、Hangar (PaperMC の配布サイト)、SpigotMC、CurseForge、作者の GitHub など、作者が公開している場所からだけ入れる
  • 最新のバージョン: 不具合や脆弱性の修正を取り込むため、できるだけ最新のバージョンを使う。ただし、最新のバージョンは、Minecraft のバージョン、Mod の基盤、前提の Mod、ほかの Mod やプラグインとの互換性に問題が出ることがある。対応するバージョンと変更の内容を確かめ、検証用のサーバーで互換性を確かめてから上げる
  • 更新の確認: 自動で更新せず、更新の内容と時期に不自然な点がないかを確かめてから反映する
  • 使わないものは外す: 使っていないプラグインは、不具合や脆弱性の入口になるため外す

参加する方の PC を守る方法は、Mod とクライアントの安全で説明しています。

監視と障害への備え

  • 監視: TPS と MSPT、メモリ、プレイヤーの数、サーバーが動いているかを記録し、異常があれば運営スタッフに通知する (管理画面とダッシュボード)
  • 自動の再起動: サーバーが落ちたときに再起動する仕組みを用意する。Spigot と Paper は、ティックが 60 秒止まると、Watchdog がサーバーを止め、設定があれば再起動のスクリプトを実行する
  • ログ: 誰がいつ参加し、どのコマンドを実行したかを残す。Velocity も、参加と移動の記録を残せる
  • 障害の手順: 障害のときの連絡先、確認の順番、参加する方への告知の方法を決めておく

企画の当日の体制

撮影や配信の企画は、決まった時間に大勢が一度に参加します。当日に慌てないよう、事前に次のことを決めておきます。

  • 事前の確認: 本番と同じ人数に近い状態で試し、TPS と MSPT、通信の量を確かめる
  • 待機: 当日は、決めた時間帯に運営スタッフが待機し、すぐに対応できるようにする
  • 事前のバックアップ: 開始の直前にバックアップを取り、問題が起きたらすぐに戻せるようにする
  • 連絡: 出演者と運営スタッフの連絡の方法を決める。参加する方からの「入れない」という問い合わせの受け方も決める
  • 終わったあと: ワールドとデータベースのバックアップを取り、計測の記録から、次の企画で直すことを洗い出す

参考にした資料

サーバーの保守運用は、KEY SELECT に

バックアップ、更新の検証と反映、Mod とプラグインの確認、監視と障害の対応を、継続してお引き受けできます。企画の当日の待機も可能です。

  • 記事や技術資料の内容についてのご質問とサポートは、保守・サポートのご契約、またはスポットでのご契約をいただいたうえでお受けしています。無償でのサポートは行っておりません。
  • 記事や技術資料の内容は、公開の時点の情報にもとづいて作成しています。内容の正確性、完全性、最新性を保証するものではなく、内容にもとづいて行った作業の結果について、弊社は責任を負いかねます。設定や変更は、ご自身の責任で、検証用の環境で確かめてから行ってください。
  • 記事や技術資料の内容について、ご指摘や誤りにお気づきの点がありましたら、その他のお問い合わせからお知らせください。
  • 技術資料の内容は、引用元として資料の名前と URL を明記していただければ、ご自身の動画や資料としてご利用いただけます。全文の Web サイトでの引用はご遠慮ください。

ご相談・お問い合わせ

内容が固まっていない段階からご相談いただけます。各分野のプロフェッショナルがご対応いたします。ご相談・お見積もりは無料です。