VirtualBoxで自宅サーバーを運用する【初期構成とバックアップの記録】

Linuxサーバーの運用を手元で試す

Linux上でサービスを継続して動かすため、WindowsのPCにVirtualBoxを入れ、その仮想マシン上にRocky LinuxとPixelmonサーバーを用意しました。PixelmonはMinecraftに追加して使うModです。ゲームサーバーを題材に、ファイル管理、起動、バックアップ、監視を試すことが目的でした。

この記事では、2026年4月に用意した初期構成と、当時のバックアップスクリプトを整理します。OSのインストール手順ではなく、自宅サーバーを動かし始めた段階で何を用意し、どこに見直しが必要だったかを記録します。

VirtualBox上に用意した構成

Windowsが普段の作業環境で、その中にVirtualBoxの仮想マシンを作り、Rocky Linux上でサーバーを動かす構成です。当時の記録ではOSをRocky Linux 9.4としています。

外部公開はせず、LAN内で使う方針でした。VirtualBoxの構成画面では、次の設定を確認できます。

これらはこの仮想マシンに設定した値です。必要スペックや実際の使用量を示したものではありません。また、LAN内で使うという運用方針と、通信を制限する設定の確認は分けて扱います。ここにはファイアウォールやルーターの設定記録までは含めていません。

画面には実行中の仮想マシンと「スナップショット2」が表示されています。環境を試しながら管理するためにVirtualBoxを選びましたが、この画像はスナップショットからの復元を試した結果ではありません。

配置したModと起動ログを確認する

サーバーにはPixelmonに加え、ModernFix、FerriteCore、AI-Improvements、JourneyMap、Waystones、Chunk-Pregeneratorなどを配置しました。軽量化や使い勝手の改善を目的に追加した構成ですが、Modごとの効果を比較測定した記録はありません。

ファイル一覧にはPixelmon 9.3.14のjarがあり、起動ログにはMinecraft 1.21.1、NeoForge 21.1.220、Pixelmon 9.3.14が表示されています。ファイルの配置だけでなく、起動時に読み込まれる構成も確認するための記録です。

この画面に残っているのは起動途中のログです。起動完了を示す Done やクライアントの接続結果は写っていないため、ここからすべてのModが正常に動いたとは判断しません。運用時には、ファイル配置、起動完了、実際の接続をそれぞれ確認する必要があります。

当時のバックアップスクリプト

ワールドの保存先を /opt/minecraft/server/world、バックアップの保存先を /opt/minecraft/backup として、次の backup.sh を用意しました。ログや一部のファイルを削除したあと、ワールドを日時付きの圧縮ファイルにまとめ、古いバックアップを削除する内容です。

以下は当時の実装です。削除処理を含み、失敗時の制御も不足しているため、そのまま使う手順としては扱いません。

#!/bin/bash

# --- 設定 ---
DATE=$(date +%Y%m%d-%H%M)
BACKUP_DIR="/opt/minecraft/backup"
SERVER_DIR="/opt/minecraft/server"
WORLD_DIR="${SERVER_DIR}/world"

# --- 1. バックアップ前のお掃除 (軽量化) ---
find ${SERVER_DIR}/logs/ -name "*.log.gz" -mtime +7 -delete
rm -rf ${SERVER_DIR}/crash-reports/*
rm -f ${WORLD_DIR}/*.bak
rm -f ${WORLD_DIR}/level.dat_old
rm -rf ${WORLD_DIR}/EliteRaidAllies.bak

# --- 2. バックアップ実行 ---
tar czf $BACKUP_DIR/world-$DATE.tar.gz $WORLD_DIR

# --- 3. 世代管理 ---
find $BACKUP_DIR -type f -name "world-*.tar.gz" -mtime +7 -delete

このスクリプトが圧縮する対象は world ディレクトリです。Modやサーバーの設定ファイルまで一式保存する内容ではありません。定期実行には crontab を使って毎日深夜4:00に取得する方針でしたが（当時の記事の記述）、登録内容や実行結果の記録は残っていません。

バックアップで見直す点

まず見直したいのは、保存が成功する前に削除を行う順序です。古いログだけでなく、level.dat_old や .bak も先に削除しています。何を復旧用として残すかを決めてから、削除対象を絞る必要があります。

また、スクリプトにはサーバーの停止や、保存処理とバックアップのタイミングを合わせる手順がありません。圧縮の終了状態も確認せず、その後に古いバックアップの削除へ進む構成です。圧縮ファイルができることと、そこから復元できることは分けて確認する必要があります。

この処理を再利用する場合の見直し点は、次のとおりです。これは当時実施できた結果ではなく、掲載したコードから整理した改善方針です。

1. ワールドに加え、復旧に必要な設定やModも保存対象として整理します。
2. 保存先の空き容量と書き込み権限を確認し、データの更新を止めた状態でバックアップを作成します。
3. 作成処理の成功とアーカイブの内容を確認してから、保存期間を過ぎたバックアップを削除します。
4. 別の場所へ復元し、サーバーの起動とワールドの読み込みを確認します。

バックアップを同じ仮想マシン内に置くだけでは、仮想ディスク自体を失った場合に一緒に失われます。保存処理の見直しとあわせて、仮想マシンの外にもコピーを残すことが課題です。

起動管理と監視の役割を分ける

当時は、起動管理にsystemd、コンソール操作にtmux、リソース監視にbtopを使う構成として記録していました。役割を分けると、次のようになります。

この記事にはサービス定義や自動起動の試験結果は残っていません。先ほどの起動ログも、tmuxやbtopの動作を示す画面ではありません。運用を再現できる記録にするには、サーバーの起動コマンドだけでなく、サービスの設定と再起動後の確認結果も残す必要がありました。

初期構成から次に見直すこと

この構成では、仮想マシンのリソース設定、Modの配置、サーバー起動時のログ、バックアップ用コードを記録しました。一方、継続運用には、起動完了や接続の確認に加え、自動起動とバックアップからの復元まで確認する必要があります。

Windows上のほかの作業とサーバーを併用するため、次の見直しではPC全体のメモリ使用量も確認対象にしました。VirtualBoxの割り当て値だけで負荷や無駄を判断せず、実際の使用状況と管理方法を比べるため、WSL2も移行先の候補として検討しました。