フォルダの構成とコマンドは、2026 年 10 月時点の Java 版と Paper、価格は 2026 年 10 月 27 日に各公式のサイトで確認したものです (米ドル、税別)。
何をバックアップするか
ワールドのフォルダの構成は、26.1 で大きく変わりました。ネザーとジ・エンドが、ワールドのフォルダの中の dimensions にまとめられ、プレイヤーのデータの場所も変わっています。Paper も 26.1 から、ネザーとジ・エンドを別のフォルダに置かなくなりました。
| 対象 | 26.1 以降 | 26.1 より |
|---|---|---|
| オーバーワールド | world/dimensions/minecraft/overworld/ | world/ |
| ネザー | world/dimensions/minecraft/the_nether/ | world_nether/DIM-1/ |
| ジ・エンド | world/dimensions/minecraft/the_end/ | world_the_end/DIM1/ |
| プレイヤー | world/players/(data、stats、advancements) | world/playerdata/ など |
| ワールドの情報 | level.dat(ひとつ前の状態は level.dat_old) | |
各ディメンションの中には、地形の region/(.mca のファイル)、エンティティの entities/、村人の仕事場などの poi/ があり、すべてを一緒にバックアップします。
Paper の公式の案内は、26.1 にワールドを更新すると元に戻せないため、更新の前のバックアップは必須だとしています。
ワールドのほかに必要なもの
- サーバーの設定:
server.properties、whitelist.json、オペレーターと BAN の一覧、Paper の設定ファイル - プラグイン: プラグインのファイルと設定のフォルダ
- データベース: MySQL などは
mysqldump --single-transactionで、サーバーを止めずに整合した状態を取る (MySQL との連動) - プロキシ:
velocity.tomlとプラグイン - 秘密の値:
forwarding.secretなど、プロキシとサーバーの間の秘密の値は、バックアップでも暗号化し、見られる人を限る
目標復旧時点 (RPO) と目標復旧時間 (RTO) を決める
バックアップの頻度と方法は、2 つの目標から決めます。
| 目標 | 意味 | 決める |
|---|---|---|
| 目標復旧時点 (RPO) | どの時点までのデータを戻せればよいか。言い換えると、どこまでのデータを失ってよいか | バックアップの頻度。1 日 1 回なら、最大で約 1 日分を失う |
| 目標復旧時間 (RTO) | 止まってから、どれだけの時間で戻せばよいか | 復元の方法と、バックアップを置く場所 |
NIST (米国国立標準技術研究所) は、目標復旧時点を「障害のあとに、データを復旧させなければならない時点」、目標復旧時間を「業務に悪い影響を与える前に、システムが復旧の段階にとどまってよい時間の長さ」と定義しています。
サーバーの種類ごとの決め方の例です。KEY SELECT が設計で使う考え方の例で、実際の値は、企画の内容とご予算に合わせて決めます。
| サーバー | 目標復旧時点の | 目標復旧時間の | 取り方の |
|---|---|---|---|
| 企画の当日 | 数分〜区切りごと | 30 分以内 | 開始の直前と区切りごとにスナップショット。すぐ戻せる場所に置く |
| 常設のサーバー | 1 日 | 数時間 | 毎日の差分のバックアップと、週ごとの別の場所への保管 |
| 練習・検証のサーバー | 1 週間 | 1 日 | 週ごとのバックアップ |
壊さずに取る
サーバーが動いている間も、ワールドのファイルは書き換えられています。書き込みの途中でコピーすると、壊れたバックアップになることがあります。
/save-off # ワールドのファイルへの書き込みを止める(変更はためておく)
/save-all flush # 今の状態をすべてディスクに書き込む(短い間、サーバーが止まる)
# ここでワールドのフォルダをコピーするか、スナップショットを取る
/save-on # 書き込みを戻す
/save-offの間も、プレイヤーのデータ、進捗、統計のファイルは書き込まれる。また、/save-offはサーバーを再起動すると元に戻る- Paper は、チャンクの書き込みを別のスレッドで行う。
save-all flushですべての書き込みが終わることを保証する公式の記載は見つからないため、確実さが必要な場合は、サーバーを止めてから取るか、書き込んだ直後にファイルシステムやディスクのスナップショットを取る - プラグインのデータとデータベースは、これらのコマンドの対象外。それぞれの方法で、同じ時刻に取る
方法と道具
| 方法 | 特徴 | 向いている |
|---|---|---|
| tar・zip | 毎回まるごと圧縮してコピーする。仕組みが単純 | 小さなワールド、企画の前後の記録 |
| rsync | 変わった部分だけを転送する。--link-dest で、変わっていないファイルを前のバックアップと共有できる | 別のサーバーへの定期のコピー |
| restic | 重複を除いた差分のバックアップ。AES-256 で暗号化し、zstd で圧縮する。S3、Backblaze B2、SFTP などに保管できる | クラウドのストレージへの毎日のバックアップ |
| BorgBackup | 重複を除いた差分のバックアップ。暗号化と圧縮に対応 | 自分で用意した保管先へのバックアップ |
| ZFS・Btrfs・LVM のスナップショット | ファイルシステムの状態を一瞬で記録する。ZFS は複数の領域を同時に記録できる | 止められないサーバーの、整合したバックアップ |
| EBS のスナップショット | AWS のディスクを、変わった部分だけ記録する。AWS は自動でバックアップしないため、自分で取る | AWS で動かしているサーバー |
| AWS Backup | バックアップの計画、古いものの移動、別のリージョンやアカウントへのコピーをまとめて管理する | AWS で多くのサーバーを動かしている場合 |
| DriveBackupV2 | Paper などのプラグイン。Google ドライブ、OneDrive、S3 互換のストレージなどに送る | 手軽に始める場合 (26.1 への対応は確認できていない) |
Btrfs のドキュメントが「スナップショットはバックアップではない」と書いているとおり、スナップショットは同じディスクの上にあります。ディスクの故障やサーバーの乗っ取りに備えて、別の場所にもコピーします。
世代の残し方と、改ざんされない保管
世代
壊れたことに後から気付いても戻せるよう、日・週・月の世代を残します。restic の例です。
# 毎日 7 世代、毎週 5 世代、毎月 12 世代を残し、それ以外を消す
restic forget --keep-daily 7 --keep-weekly 5 --keep-monthly 12 --prune
3-2-1 の原則
米国の CISA が紹介し、警視庁も案内している原則です。データを 3 つ持ち、2 種類の媒体に分け、1 つは別の場所に置きます。
ランサムウェアに備える
CISA は、ランサムウェアの多くが、届く場所にあるバックアップを探して消したり暗号化したりすると注意し、オフラインで暗号化したバックアップを持つよう勧めています。警視庁も、オフラインのバックアップや、論理的に分けた環境での保管を勧めています。
- 改ざんされない保管: Amazon S3 の Object Lock (コンプライアンスモードでは、管理者を含めて誰も消せない)、Cloudflare R2 のバケットのロック、AWS Backup の Vault Lock
- 権限を分ける: サーバーには、バックアップを書き込む権限だけを渡し、消す権限は別の安全な環境に置く
- 暗号化: バックアップは暗号化し、鍵は別に保管する
保管の費用
Amazon S3 Standard
$0.025/ GB / 月
東京のリージョン。すぐに取り出せる保管です。直近のバックアップに向いています。
S3 Glacier Instant Retrieval
$0.005/ GB / 月
すぐに取り出せる、安い保管です。最低 90 日の保管と、取り出しの料金 (1 GB あたり $0.03) がかかります。
S3 Glacier Deep Archive
$0.002/ GB / 月
もっとも安い長期の保管です。取り出しに 12 時間 (大量の取り出しは 48 時間) 以内かかり、最低 180 日の保管です。
EBS のスナップショット
$0.05/ GB / 月
東京のリージョン。変わった部分だけが料金の対象です。アーカイブ (1 GB あたり月 $0.0125) は、月ごとなどの長期の保管に向きます。
Cloudflare R2
$0.015/ GB / 月
取り出しの通信の料金がかかりません。月 10 GB まで無料です。
Backblaze B2
$6.95/ TB / 30 日
保管している量の 3 倍までは、取り出しの通信の料金がかかりません。最低の保管の期間はありません。
- 価格は各公式のサイトによります (2026 年 10 月 27 日に確認、税別)。AWS は、日本の居住者には消費税が加わります。
復元
復元を試したことのないバックアップは、戻せるかどうか分かりません。CISA も、バックアップを使えるかを定期的に試すよう勧めています。検証用のサーバーで、実際に戻す練習をします。
目標復旧時間 (RTO) に効くこと
- EBS のスナップショットから作ったディスクは、使い始めてからデータを読み込むため、しばらく遅くなる。事前に読み込みの速さを指定するか、高速の復元 (Fast Snapshot Restore、東京で 1 スナップショット・1 ゾーンあたり 1 時間 $0.90) を使う
- EBS のスナップショットのアーカイブは、戻すのに最大 72 時間かかる
- S3 Glacier Deep Archive は、取り出しに 12 時間以内 (大量の取り出しは 48 時間以内) かかる。企画の当日のバックアップは、すぐに取り出せる場所に置く
一部だけを戻す
- チャンクの単位: MCA Selector で、ワールドの中の選んだチャンクやリージョンを、書き出したり消したりできる (1.2.1 から 26.3 以降に対応)。変更する前に、必ずワールドのコピーを取る
- プレイヤーの単位: そのプレイヤーがログインしていない間に、バックアップからプレイヤーのデータ (26.1 以降は
world/players/data/の UUID のファイル) だけを戻す - データベースの単位: バイナリログを使うと、障害の直前の時点まで戻せる (MySQL との連動)
大規模なサーバーのバックアップ
サーバーの数が増え、ワールドが大きくなると、バックアップそのものがサーバーの負担になります。
- 書き込みの負担: Paper は、チャンクの書き込みを別のスレッドで行い、自動保存の量を 1 ティックあたりに制限している (
max-auto-save-chunks-per-tick、既定 24)。バックアップの読み出しが重なると、ディスクの読み書きが詰まるため、サーバーごとに時刻をずらし、スナップショットを使う - 保管の階層: 直近のものは S3 Standard、月ごとのものは Glacier など、古さで保管の場所を分ける
- 重複の除去: 毎日変わる部分は、ワールドの一部にとどまる。restic などで重複を除くと、保管の量を抑えられる
- Kubernetes: ボリュームのスナップショット (VolumeSnapshot) は、CSI のドライバーで使える。スナップショットの前に、ワールドを書き込んでおく
Hypixel は 2019 年の開発ブログで、SkyBlock の 173 万の島 (合計 40.2 GB) を、独自の圧縮した形式で保存し、1 日 2 回のバックアップを S3 に数週間保管していたと説明しています。保存の仕組みのファイルの破損が続いたため、別のデータベースに移したことも公開しています。大規模なサーバーでは、保存とバックアップの仕組みそのものを、用途に合わせて設計しています (大規模な運営の例)。
参考にした資料
- Java Edition level format (Minecraft Wiki)
- Paper 26.1 (PaperMC)
- Updating Paper (PaperMC)
- Commands/save (Minecraft Wiki)
- World configuration (PaperMC)
- Recovery Point Objective (NIST)
- Recovery Time Objective (NIST)
- 災害対策 (DR) の目標 (AWS Well-Architected)
- Removing backup snapshots (restic)
- BorgBackup
- zfs-snapshot (OpenZFS)
- Subvolumes (Btrfs)
- Amazon EBS snapshots (AWS)
- Fast snapshot restore (AWS)
- S3 Object Lock (AWS)
- Archive retrieval options (AWS)
- Bucket locks (Cloudflare R2)
- #StopRansomware Guide (CISA)
- 安全なバックアップの取得方法と注意点 (警視庁)
- MCA Selector (GitHub)
- DriveBackupV2 (GitHub)
- Dev Blog #5 (Hypixel)
バックアップの仕組みづくりは、KEY SELECT に
バックアップの対象と頻度の決定、自動化、改ざんされない保管、復元の手順と練習まで、KEY SELECT がお引き受けできます。企画の前後のバックアップと、当日の復旧の待機も可能です。
- 記事や技術資料の内容についてのご質問とサポートは、保守・サポートのご契約、またはスポットでのご契約をいただいたうえでお受けしています。無償でのサポートは行っておりません。
- 記事や技術資料の内容は、公開の時点の情報にもとづいて作成しています。内容の正確性、完全性、最新性を保証するものではなく、内容にもとづいて行った作業の結果について、弊社は責任を負いかねます。設定や変更は、ご自身の責任で、検証用の環境で確かめてから行ってください。
- 記事や技術資料の内容について、ご指摘や誤りにお気づきの点がありましたら、その他のお問い合わせからお知らせください。
- 技術資料の内容は、引用元として資料の名前と URL を明記していただければ、ご自身の動画や資料としてご利用いただけます。全文の Web サイトでの引用はご遠慮ください。