WSL2のサーバーデータを整理する【構成管理・実データ・保管先の分離】

WSL2上のFiveMとPixelmonを例に、Ansibleの構成管理、コンテナの実データ、アーカイブの保存先を分ける構成と編集・保護のルールを整理します。

公開日
この記事の見出し 開く

編集するコードと保護するデータを分ける

WSL2上でFiveMとMinecraftのPixelmonサーバーを扱う中で、Ansibleの設定、ゲームの実データ、バックアップが混在しやすくなっていました。設定を変更するときとデータを保護するときで、対象を見分けられるようにするため、保存先を3つの役割に分けました。

この記事は2026年5月時点の構成記録です。WSL2内でDockerを動かし、Ansibleで構築手順を管理する環境を例に、何をどこへ置き、どのファイルを編集するかを整理します。Ansibleは設定や操作手順をコードで管理するツール、Docker Composeは複数のコンテナの設定をまとめる仕組みです。

3つの保存先と保護するもの

4月の移行とバックアップの作業記録では、~/pixelmon-data や ~/ansible-minecraft のようにホーム直下へ置く暫定的な配置でした。この記事の時点で、それをローカルサーバー全体の標準構成として次の3つに分けました。掲載する /home/haruuu はこの環境のパスであり、別の環境では実際のユーザーと保存先に合わせる必要があります。

/home/haruuu/
├── projects/   # IaC（Ansible / docker-compose）
├── services/   # 実データ（FiveM / Minecraft）
└── archives/   # 長期保管

projects には構成を作るためのPlaybookやテンプレート、services にはサーバーが読み書きするデータ、archives には移行元の圧縮ファイルなどを置きます。IaCは、こうした構築手順をコードとして管理する考え方です。

構成を再生成するためのコードも、保護する対象です。 作り直せるコンテナと、その作り方を記述したPlaybookは同じ扱いにしません。projects の原本と services の実データを残して初めて、環境を再構築する準備ができます。

projectsに置いた構成管理コード

/home/haruuu/projects
├── ansible-docker
│   └── docker-install.yml
├── ansible-fivem
│   ├── docker-compose.yml
│   ├── hosts
│   ├── roles
│   │   └── fivem
│   └── site.yml
├── ansible-minecraft
│   ├── backup.yml
│   ├── hosts
│   ├── roles
│   │   └── pixelmon
│   └── site.yml
└── memo.md

ansible-docker はDockerの導入、ansible-fivem はFiveMとMariaDB、ansible-minecraft はPixelmonの構築とバックアップを担当します。Playbookは実行する処理、roleは処理をまとめた単位、templateは設定ファイルのひな形です。

構築方法を変える場合は、まずPlaybookやテンプレートを修正します。生成済みのComposeファイルだけを書き換えると、次にAnsibleを実行した際にテンプレートの内容で置き換わるためです。手元で行った変更は、原本へ反映するか、一時的な変更として扱うかを区別します。

servicesに置いた実データ

/home/haruuu/services
├── fivem
│   ├── backups
│   └── data
│       ├── mysql
│       ├── server
│       └── txData
└── minecraft
    ├── backups
    └── pixelmon
        └── data
            └── server

FiveMの設定や追加リソース、管理ツールであるtxAdminのデータ、MariaDBのデータ、PixelmonのワールドやModを、この領域へ集約しました。ここでいうホスト側は、Dockerを動かしているWSL2内のLinux環境です。

Composeのbind mountは、ホスト側のディレクトリをコンテナ内のパスへ対応付けます。コンテナを作り直しても保存先を引き継げますが、コンテナからの書き込みや削除もホスト側へ反映されます。保存先を分けること自体はバックアップになりません。Docker公式のBind mountsの説明

FiveMの構成ファイルを生成する場所

FiveM側では projects/ansible-fivem にComposeファイルを生成し、同じ場所で起動する構成にしました。以下は当時の記事に掲載したAnsibleのタスク抜粋です。単体で完結するPlaybookではなく、テンプレートなどの周辺ファイルと組み合わせて使う処理です。

- name: FiveM用データディレクトリを作成する
  ansible.builtin.file:
    path: "{{ item }}"
    state: directory
    owner: haruuu
    group: haruuu
    mode: '0755'
  loop:
    - "/home/haruuu/services/fivem/data/server"
    - "/home/haruuu/services/fivem/data/txData"
    - "/home/haruuu/services/fivem/data/mysql"

- name: docker-compose.yml を配置する
  ansible.builtin.template:
    src: docker-compose.yml.j2
    dest: "/home/haruuu/projects/ansible-fivem/docker-compose.yml"
    owner: haruuu
    group: haruuu
    mode: '0644'

- name: FiveMコンテナ(txAdmin + MariaDB)を起動する
  ansible.builtin.shell:
    cmd: docker compose up -d
  args:
    chdir: "/home/haruuu/projects/ansible-fivem"
  become: yes

ディレクトリの作成先は services、Composeの配置先と実行場所は projects になっています。FiveM側の構築方法を直す場合はAnsible側、稼働中のサーバー設定を直す場合は次のデータ側を確認します。

/home/haruuu/services/fivem/data
├── mysql
├── server
│   ├── server.cfg
│   ├── resources
│   ├── cache
│   └── 各種設計メモ
└── txData

server.cfg はサーバー設定、resources は追加リソース、txData は管理用データです。mysql はMariaDBが扱う領域として、ホスト側からファイルを直接編集しない運用にしました。

FiveMの保存先とコンテナ内の対応

以下は当時の記事に掲載したCompose定義です。DBパスワードは伏せ字で、MariaDBのホスト公開用ポートは省略した掲載用の内容です。最新の推奨構成や、そのまま起動するための手順としては扱いません。

services:
  fivem:
    image: spritsail/fivem:latest
    container_name: fivem-server
    restart: unless-stopped
    stdin_open: true
    tty: true
    ports:
      - "30120:30120/tcp"
      - "30120:30120/udp"
      - "40120:40120/tcp"
    environment:
      - TZ=Asia/Tokyo
      - NO_DEFAULT_CONFIG=1
      - NO_LICENSE_KEY=1
    volumes:
      - /home/haruuu/services/fivem/data/server:/config
      - /home/haruuu/services/fivem/data/txData:/txData
    deploy:
      resources:
        limits:
          memory: 4G
    depends_on:
      - mariadb

  mariadb:
    image: mariadb:10.6
    container_name: fivem-mariadb
    restart: unless-stopped
    environment:
      - MYSQL_ROOT_PASSWORD=<DB_ROOT_PASSWORD>
      - MYSQL_DATABASE=HaruuuCore
      - TZ=Asia/Tokyo
    # MariaDB は FiveM コンテナから Docker network 経由で接続するため、
    # 外部公開用の ports は記事例では省略しています。
    volumes:
      - /home/haruuu/services/fivem/data/mysql:/var/lib/mysql

volumes の左側がWSL2上の保存先、右側がコンテナ内の参照先です。server を /config、txData を /txData、mysql を /var/lib/mysql へ対応付けています。MariaDBへはFiveMコンテナからDockerネットワーク経由で接続します。当時の定義にあったホスト公開用のポート設定は、この掲載例では省略しています。

Pixelmonで異なるComposeの配置

Pixelmon側も構築用のテンプレートは projects に置きますが、生成したComposeファイルは実データと同じ services/minecraft/pixelmon/data/server に配置していました。

/home/haruuu/services/minecraft/pixelmon/data/server
├── docker-compose.yml
├── server.properties
├── mods
├── config
├── logs
└── world

FiveMと配置は統一されていません。起動操作の前に、どちらのComposeファイルを使うかを確認する必要があります。以下のAnsible抜粋では、data_dir を配置先と実行場所の両方に使っています。

- name: Ensure base directory exists
  ansible.builtin.file:
    path: "{{ base_dir }}"
    state: directory
    mode: '0755'

- name: Check if migration archive exists
  ansible.builtin.stat:
    path: "{{ migration_archive }}"
  register: archive_stat

- name: Extract migration data to base directory
  ansible.builtin.unarchive:
    src: "{{ migration_archive }}"
    dest: "{{ base_dir }}"
    remote_src: yes
  when: archive_stat.stat.exists

- name: Deploy docker-compose.yml from template
  ansible.builtin.template:
    src: docker-compose.yml.j2
    dest: "{{ data_dir }}/docker-compose.yml"
    mode: '0644'

- name: Start Pixelmon container via Docker Compose
  ansible.builtin.shell:
    cmd: "docker compose up -d"
    chdir: "{{ data_dir }}"
  become: yes

この構成での base_dir はPixelmonの基点、data_dir はその下の data/server、migration_archive は移行用アーカイブのパスです。変数定義やテンプレートは抜粋に含まれていないため、実際に使う値とアーカイブ内の階層を照合する必要があります。

また、この処理はアーカイブが存在すると展開へ進みます。初回の移行と通常の設定更新を区別する条件は掲載部分にないため、稼働後のデータへ古い内容を再展開しないよう、再実行前の見直しが必要です。

Pixelmonの実データをマウントする

services:
  pixelmon:
    image: itzg/minecraft-server
    container_name: pixelmon-server
    ports:
      - "25577:25565"
    environment:
      EULA: "TRUE"
      TYPE: "NEOFORGE"
      VERSION: "1.21.1"
      MEMORY: "6G"
      ENABLE_ROLLING_LOGS: "true"
    volumes:
      - "/home/haruuu/services/minecraft/pixelmon/data/server:/data"
    restart: unless-stopped

この定義では data/server 全体をコンテナ内の /data へ対応付けています。ワールドだけでなく、Mod、設定、ログも同じ保存先に含まれます。ここにあるComposeファイルも、データ一式のバックアップに含まれる配置です。

掲載したイメージ名やバージョンは当時の定義です。この記事は保存先の整理を扱っており、現在のイメージでの起動や互換性を再検証したものではありません。

バックアップと長期保管を分ける

Pixelmonは services/minecraft/backups、FiveMは services/fivem/backups をバックアップ先にしました。archives は移行元データなどの長期保管先です。名前を分けるだけで自動保存されるわけではなく、作成手順と保存対象を別に決める必要があります。

Pixelmon側の掲載コードでは、停止、圧縮、再開、古いバックアップの検索を行っています。

- name: Create backup directory
  ansible.builtin.file:
    path: "{{ ansible_env.HOME }}/services/minecraft/backups"
    state: directory
    mode: '0755'

- name: Stop Pixelmon container safely
  ansible.builtin.shell:
    cmd: "docker compose stop"
    chdir: "{{ data_dir }}"
  become: yes

- name: Compress Pixelmon server data
  ansible.builtin.shell:
    cmd: "tar -czf {{ ansible_env.HOME }}/services/minecraft/backups/pixelmon_backup_{{ timestamp.stdout }}.tar.gz -C {{ base_dir }}/data server"

- name: Restart Pixelmon container
  ansible.builtin.shell:
    cmd: "docker compose start"
    chdir: "{{ data_dir }}"
  become: yes

- name: Find backups older than 7 days
  ansible.builtin.find:
    paths: "{{ ansible_env.HOME }}/services/minecraft/backups"
    patterns: "pixelmon_backup_*.tar.gz"
    age: "7d"

この抜粋に含まれる find は条件に合うファイルを検索する処理で、削除処理ではありません。日次実行の設定も含まれていません。Ansible公式のfindモジュール（条件に合うファイルの検索）の説明

timestamp.stdout は日時を取得した別タスクの結果を使う記述です。また、ansible_env.HOME が指すユーザーと、実際の保存先が一致しているかも確認が必要です。停止後の圧縮で失敗すると再開タスクまで進まない構成なので、失敗時の再開方法も準備する必要があります。

FiveMはMariaDBを含めてコンテナを停止し、手動で取得する方針でした。この記事にはバックアップからの復元結果までは含めていません。保管したファイルを別の場所へ戻し、必要なデータを読み込めることまで確認するのが次の工程です。

同じWSL2環境内の backups や archives だけでは、その環境自体を失った場合に備えられません。構成コードと実データの保護には、環境の外へ残すコピーも必要です。

編集前と再構築前に確認すること

当時は通常ユーザーでコードや設定を編集し、Docker操作には sudo を使っていました。FiveMとPixelmonは同時起動しない運用で、自動的な排他制御は用意していませんでした。

この配置で作業する際は、次の順序で対象を確認します。以下は構成から整理した確認手順であり、実行結果の記録ではありません。

  1. 構築方法の変更か、サーバーの実データの変更かを判断します。
  2. Playbook・テンプレートの原本と、生成先のComposeファイルを確認します。
  3. Composeの volumes で、保護したいディレクトリがマウントされているかを確認します。
  4. データを変更・移動する前にバックアップを確保し、所有者と書き込み権限も確認します。
  5. 再構築後は、起動状態だけでなく、元のワールドや設定を読み込んでいることを確認します。

この整理の目的は、削除してよい領域を大まかに決めることではありません。構成の原本、稼働中のデータ、保管したコピーの役割を区別し、変更や復旧で必要になるものを見落とさないようにすることです。

見出しへ戻る 開く

関連記事

この記事とあわせて確認しやすい技術ログです。

AnsibleでPixelmonサーバーをバックアップする【エラー修正とアーカイブ作成の記録】

関連する検証ログ

AnsibleでPixelmonサーバーをバックアップする【エラー修正とアーカイブ作成の記録】

2026/4/28

Pixelmonの23GBデータをWSL2へ移行する【パス修正とDockerでの起動確認】

あわせて読む記事

Pixelmonの23GBデータをWSL2へ移行する【パス修正とDockerでの起動確認】

2026/4/20

すべての記事を見る