ConoHaのMODサーバー運用・メンテ術｜バックアップと復旧

MODサーバーの長期運用では、バックアップを自動(Minecraft Managerとイメージ保存)と手動(worldフォルダのコピー)の2系統で持ちます。 MODの更新は、バックアップを取ったあと1つずつ行い、更新ごとに起動を確認します。 サーバーが落ちたときは、状態確認、ログ確認、再起動、直前の変更を戻す、バックアップ復元の順で進めます。

バックアップは事故の前にしか作れない

MODサーバーで最も取り返しがつかない事故は、長時間遊んだワールドのデータが壊れて戻らないことです。 バックアップは事故が起きてからでは作れません。先に習慣として組み込んでおきます。

筆者は自作MODを含む大型MODサーバー(Forge 1.20.1)をConoHa上で長期運用しています。 この記事では、その運用で固まった壊さないための習慣と、壊れたときの手順をまとめます。

バックアップの二段構え

バックアップは性質の違う2系統を持ちます。片方が使えないときに、もう片方で戻せます。

1つ目はConoHa側の機能です。 Minecraft Managerの自動バックアップは、スケジュールを設定して自動で取得し、保持数も1〜14で変更できます(2026-08-26時点・公式機能一覧)。 有効にしておけば、何もしなくても戻れる地点が積み上がります。

コントロールパネルのイメージ保存では、MODやJava環境まで含めたサーバーまるごとの控えを取れます。 大きな変更の節目に向いています。

2つ目は手動のworldフォルダコピーです。 サーバーを停止するか、コンソールで書き込みを止めてからコピーします。

say バックアップを取ります
save-all flush
save-off

書き込みを止めた状態で、SSHからワールドデータを固めます(例)。

tar czf ~/backup/world_20260826.tar.gz -C /path/to/server world

終わったら save-on で書き込みを再開します。 固めたファイルは、定期的にローカルPCにもダウンロードします。 VPS内だけに置いたバックアップは、ディスク障害や誤操作で本体と一緒に消える可能性があります。

MOD更新の手順

長期運用でサーバーが壊れる原因の代表は、MODの更新と追加です。 手順を固定しておくと、事故の確率と復旧の手間が両方減ります。

1. バックアップを取る(上の手順。更新前に必ず)
2. 旧バージョンのjarを退避する。削除せず mods_old フォルダ等へ移動
3. 1つだけ更新して起動する。依存MOD(前提ライブラリ)の要求バージョンも確認
4. ログを確認する。起動できても logs/latest.log にエラーや警告が出ていないか見る
5. ゲーム内で動作確認してから次のMODへ進む

筆者は運用初期に複数のMODをまとめて更新し、サーバーが起動しなくなりました。 原因のMODを切り分けるのに丸一日かかりました。 1つずつ更新していれば、直前に触ったMODを疑うだけで済みます。

サーバーが落ちたときの復旧手順

落ちたときは、原因を考える前に次の5ステップを順番どおりに進めます。

STEP1: サーバーの状態を確認する

ConoHaのコントロールパネルで、VPS自体が起動しているかを見ます。 CPU・メモリ・ディスクの使用状況に異常がないかも確認します(リソース使用状況はManagerで見られます)。 VPSは動いていてMinecraftのプロセスだけ落ちているのか、VPSごと落ちているのかで対処が変わります。

STEP2: ログを確認する

logs/latest.log の末尾と crash-reports/ の最新ファイルを見ます。

• java.lang.OutOfMemoryError → メモリ不足。メモリ割当の見直しへ
• 特定MODの名前を出して落ちている → そのMODと依存関係を疑う
• ディスクフルの書き込みエラー → df -h で空きを確認(後述)

STEP3: 再起動する

原因が読み取れなくても、まず再起動して復帰するか試します。 復帰すればプレイヤーを待たせずに済みます。 ただし、ログで見つけた原因は放置しないでください。同じ落ち方が再発します。

STEP4: 直前の変更を戻す

再起動で直らない場合、直近に追加・更新したMODや設定変更を巻き戻します。 「MOD更新の手順」で旧jarを退避してあれば、戻す作業は数分で終わります。

STEP5: バックアップから復元する

ワールドデータ自体が壊れた場合の最終手段です。 自動バックアップまたは手動バックアップから、直近の正常な世代へ戻します。 二段構えにしておけば、失うのは最後のバックアップ以降のプレイ分だけです。

落ちてはいないが重い場合はMODサーバーが重い時の対処法を参照してください。 サーバーは動いているのに入れない場合はサーバーに入れない時のチェックリストに切り分け手順があります。

ディスク容量の管理

ConoHa for GAMEのSSDは100GBです(2026-08-26時点)。 長期運用では、次の3種類のデータが少しずつディスクを埋めます。

原因	中身	対処
ワールドデータ	探索で増えたチャンク	増えるのは正常。他を削る
バックアップ世代	自動+手動の累積	保持数を絞る・古い手動分を削除
ログ類	logs/ の圧縮ログ、crash-reports/	古いものは削除してよい

現状の把握は次の2コマンドで足ります。

df -h
du -sh /path/to/server/*

筆者の運用では、探索好きのメンバーが1人いるだけでワールドデータが想定より速く増えました。 そこにバックアップの保持数を多めにした設定が重なると、ある日ディスクが満杯になり、サーバーが書き込みに失敗します。 月1回 df -h を実行する習慣があれば、この事故はほぼ防げます。

長期運用で役に立っている習慣

最後に、数値化しにくいものの役に立っている習慣を挙げます。いずれも筆者の経験則です。

• 変更は1つずつ。MODも設定も同時に2つ触らない
• 節目でイメージ保存。動いている構成に戻れる地点を作ってから大きな変更をする
• MOD一覧とバージョンをメモしておく。復旧時に正常だった構成をすぐ確認できます
• 自動再起動スケジュールを設定する。Managerの機能で定期再起動を仕込めます(2026-08-26時点・公式機能一覧)。長時間稼働で重くなった状態を翌朝に持ち越しません

この運用を始めてから、筆者のサーバーは落ちても戻れる前提で気楽にMODを試せる場所になりました。 バックアップの設定は今日の作業だけで終わります。 まだの人は、Managerの自動バックアップだけでも先に有効にしておくことを勧めます。

次に読む:

• MODサーバーが重い時の対処法
• サーバーに入れない時のチェックリスト
• ConoHaのプラン選びと料金の仕組み