Rustサーバーの再起動とは?ワイプとの違いとやり方
2026.10.16
Rustサーバーのバックアップと復元方法!拠点やBPを残す手順

- Rustの更新や設定変更の前に、友達と建てた拠点を残しておきたい
- セーブファイルだけコピーすれば、覚えたBPやプラグインの設定も戻るのか知りたい
- バックアップはあるけれど、どこへ戻せばよいかわからない
Rustのバックアップは、サーバーを保存して正常に停止したあと、使っているデータ一式を別の場所へコピーするのが基本です。
拠点が入るセーブファイルと、BPなどのプレイヤー情報は別々に保存されます。ファイルを1つだけ選ぶより、使用中のidentityフォルダを丸ごと残すほうが保存漏れを避けられます。
復元で大切なのは、バックアップで現在のデータを置き換える前に、その現在のデータも退避すること。戻す日時を間違えても、復元作業を始める前の状態へ戻れるようにしておきます。
この記事は、自分でファイルを管理できるPC版Rust専用サーバーが対象です。レンタル会社のバックアップ機能を使う場合との違いも先に分けました。
保存するフォルダ、停止の確認、復元後に見る場所まで順に進めれば、ファイルを残しただけで終わりません。拠点やBPが戻っていることを確かめてから、友達とのプレイを再開できます。
バックアップは使用中のデータ一式を停止中に保存する
ワールドだけでなく設定やプレイヤー情報も残すのが、サーバーを戻すための基本です。操作できる範囲で手順が分かれます。
| 利用している環境 | 保存の進め方 | 先に確かめること |
|---|---|---|
| 自宅PCや自分で管理するVPS | 正常停止後にファイルをコピーする | サーバーの設置先と使用中のidentity |
| ファイルを操作できるレンタルサーバー | サーバーを停止して対象フォルダを手元へ保存する | ファイルマネージャーで読める範囲と転送完了 |
| 提供元のバックアップ機能を使う | 提供元が用意した作成と復元の手順を使う | ワールド、プレイヤー情報、設定、MODが保存対象に入るか |
| 他人のサーバーへ参加しているだけ | サーバー管理者へ保存や復元を相談する | 自分にファイル管理権限があるか |
提供元のバックアップは、ファイルコピーと同じ範囲を保存するとは限りません。対象がワールドだけなら、起動設定やプラグインの保存分は別に用意する必要があります。
手動保存とバックアップは別の作業
server.saveは、進行中のサーバーデータを保存するコマンドです。別のPCや保存機器へコピーを作る命令ではありません。
Rustはセーブ時にセーブファイルのバックアップも保持します。ただし、同じサーバー内にあるコピーだけでは、保存先ごとの消失に備えられません。
この記事では、保存を済ませてからサーバーを止め、停止中の一式を手元のPCなどへコピーします。
マップの初期化と復元を混同しない
復元は、残してあるデータへ戻す操作です。ワイプはマップやBPなどを初期化する操作なので、復旧のために試すものではありません。
どの進行が消える操作なのかを先に確認するなら、RustのマップワイプとBPワイプの違いが判断に役立ちます。
手順1:保存対象のフォルダと起動設定を確認する
サーバーの表示名ではなく、起動設定のserver.identityで保存対象を特定します。名前が似た別フォルダをコピーしないよう、実際に起動している設定と照合してください。
identityとは
identityは、同じインストール先でサーバーのデータを区別するための識別名です。
起動に使っている識別名を調べる
起動用のバッチファイルやサービスの設定を開き、+server.identityの値を探します。値がfriendsなら、基本の保存対象はサーバー設置先のserver/friends/です。
レンタル会社のテンプレートを使っている場合は、そのサーバーに指定された識別名とデータの場所を合わせます。記事の例に合わせてidentityを書き換える必要はありません。
設定ファイルの場所から確認したいときは、Rustサーバーの設定方法で使っている環境の説明へ進めます。
identityフォルダを丸ごと保存対象にする
Rustの保存ファイルは、ワールドとプレイヤー情報で分かれています。
| 保存対象 | 主に残せるもの | 保存時の扱い |
|---|---|---|
server/[identity]/全体 | マップ、建築物、BP、プレイヤー関連情報、管理者設定など | 中のファイルを選別せず一式をコピー |
| 起動用ファイルやサービスの設定 | identity、マップ条件、接続に使う設定など | 元の保存場所がわかるよう別に控える |
oxide/全体 | Oxideプラグイン本体、設定、保存データなど | Oxideを使っている場合だけ追加 |
.savには建築物や設置物など、.mapには地形やモニュメントのデータが入ります。BPはplayer.blueprints系のファイルで管理されるため、.savだけを残しても一式の代わりにはなりません。
cfgフォルダやRust+関連ファイルもidentity内にあります。拡張子や番号が違うという理由で、見覚えのないファイルを除外しないでください。
データベースの付属ファイルを消さない
Rustのデータベースには、ファイル名の末尾が-walになった付属ファイルが使われます。これは、保存内容を反映するための記録です。
残っているWALもデータと一緒に扱います。データベース本体からWALを分離すると、保存済みの内容を失ったり、破損したりする危険があります。
不要そうなファイルを選んで消さない
停止後に-walが残っていても、不要な一時ファイルと判断して削除しないでください。バックアップも復元も、同じ停止時点のフォルダ一式で行います。
Oxide以外のMODや外部データベースを使うプラグインは、保存場所がこの表の外にある構成もあります。その場合は、追加した仕組みの保存先も同じ作業に含めてください。
手順2:サーバーを保存して正常に停止する
参加者へ停止することを伝え、新しい作業を終えてもらってから保存します。ファイルのコピーは、サーバーが止まったことを確かめてからです。
手動保存の完了を確かめる
Rustのサーバーコンソール、または接続済みのRCONから手動保存を実行します。RCONは、外部からサーバーへ管理コマンドを送る仕組みです。
server.saveこれはサーバーの手動保存コマンドです。ログに保存処理が出たことと、書き込みエラーが出ていないことを確認します。
保存に失敗しているときは、空き容量や保存先への書き込み権限を調べる段階です。失敗したデータで、以前の正常なバックアップを上書きしないでください。
自動再起動も止めてからコピーへ進む
普段使っている管理画面や管理ツールからサーバーを停止します。自動再起動の監視や起動ループがある構成では、停止後に勝手に起動しない状態へ切り替えてください。
管理者としてゲームに接続している場合は、F1コンソールから保存して閉じる方法もあります。
sv quitsvを付けないquitは、自分のゲームを終了する操作です。コマンドの実行先を取り違えないようにしてください。
ゲームから切断されたことだけで停止完了とは判断しません。管理画面の停止状態か、管理ツールでRustDedicatedの終了を確認します。
停止方法がまだ決まっていない場合は、Rustサーバーの停止と再起動の手順から環境に合う操作を確認できます。
手順3:別の保存先へ日時ごとにコピーする
サーバー停止中の一式を、バックアップ日時がわかる新しいフォルダへコピーします。前回分をすぐ上書きせず、戻したい日時を選べる形にしておくと復元時に比較できます。
保存した日時とサーバーの条件を残す
- サーバーの設置先とは別に、日時を含めたバックアップ用フォルダを作ります。
- 使用中のidentityフォルダ全体と起動設定をコピーします。
- Oxideを使っている場合は、同じ停止中に
oxide/全体も保存します。 - 元の設置先、identity、マップのシード値とサイズ、Rustのビルド情報をメモします。
圧縮する場合も、元のフォルダ構造を残してください。復元時に、identityの中身をどの階層へ戻すか判断しやすくなります。
起動設定やcfgには、RCONのパスワードなどの管理情報が入る構成があります。バックアップは管理者だけが読める場所に保管し、公開リンクや共有掲示板へ置かないでください。
コピーしたファイルを開けることまで確かめる
転送が終わったら、保存先のidentity内にワールド、プレイヤー情報、cfgがあるかを確認します。コピー元とコピー先でファイル数とサイズも見比べてください。
圧縮ファイルなら、別の空フォルダへ展開できることを確かめます。ファイル名が見えるだけでは、読み出せる内容まで確認したことにはなりません。
同じディスク内のコピーを作業用に残す場合も、もう1部を手元のPCや別の保存機器へ移します。コピーと内容確認が終わってから、通常の方法でサーバーを起動してください。
手順4:復元前のデータを退避してから戻す

復元より先に現在の一式を残します。バックアップの日時を間違えたり、復元後に問題が見つかったりしたときの戻り先になるためです。
戻す日時と互換性を確認する
復元すると、ゲームの進行はバックアップを保存した時点へ戻ります。そのあとに建てた拠点や集めた物資が残る操作ではないことを、参加者にも伝えてください。
バックアップを取ったサーバーと、戻す先のidentity、マップ条件、Rustのビルド情報を照合します。更新や強制ワイプを跨ぐ場合は、古いデータをそのまま読めるとは限りません。
強制ワイプをファイル名変更で回避しない
強制ワイプでは保存形式の番号が変わり、古いセーブが使われなくなります。古い.savの番号を変えて読み込ませる方法は危険です。
強制ワイプを跨いだバックアップは、保存形式の互換性を前提に扱います。互換性が合わないデータを、名前だけ変えて本番へ戻さないでください。
現在のフォルダを残して空の場所へ復元する
- サーバーを保存して正常に停止し、自動再起動も止めます。
- 現在のidentity、起動設定、使用中のMODデータを復元前の日時付きフォルダへコピーします。
- 退避した内容を確認したあと、復元対象の元フォルダをサーバーの設置先の外へ移動します。
- 選んだバックアップを、元と同じ場所・同じidentity名になるようコピーします。
- 起動設定とMODデータも、そのバックアップと対応する状態へそろえます。
古いバックアップを現在のフォルダへ混ぜると、新旧のデータが残る原因になります。元フォルダを退避し、空いた場所へ一式を戻す形にしてください。
たとえば元がserver/friends/なら、復元後もその直下に.savやcfgがある状態です。server/friends/friends/のように同じフォルダを二重にしないよう確認します。
手順5:起動とゲーム内の状態を照合する
復元の完了は、サーバーが起動したことだけでは決まりません。バックアップを取った日時のワールドやプレイヤー情報へ戻ったかを確認してから、参加者へ再開を知らせます。
管理者が先に入って確認する
通常の起動手順でサーバーを起動します。ログのServer startup completeは起動完了の目印です。
| 確認するもの | 成功の見分け方 |
|---|---|
| マップ | 保存したときと同じ地形や拠点の位置である |
| 建築物と設置物 | バックアップ時点で存在したものが残っている |
| プレイヤー情報 | 対象プレイヤーのBPなどが保存時点に戻っている |
| 管理者と設定 | 管理権限やサーバー設定が意図した状態である |
| 使用中のプラグイン | 読み込みエラーがなく、設定と保存データが対応している |
管理者のアカウントだけで、全員のBPまで確認したつもりにならないことも大切です。必要な参加者にも保存時点の情報と照合してもらってください。
確認が終わるまでは、復元前に退避したデータと元のバックアップを残します。
戻らないときは停止して原因を分ける
違うワールドや初期状態が表示されたら、そのまま遊び続けずに停止します。ファイルを繰り返し上書きする前に、症状に合う場所を調べてください。
| 症状 | 最初に調べる場所 |
|---|---|
| 新しいマップになった | 起動中のidentity、復元した階層、マップ条件 |
| 拠点は戻ったがBPが違う | プレイヤー情報も同じバックアップ一式から戻したか |
| プラグインの設定やデータがない | identityとは別にoxide/を復元したか |
| ファイルの読み込みでエラーが出る | コピー完了、所有者や権限、バックアップとゲームの互換性 |
| コピー中にデータが変わった | 自動再起動や別の管理ツールがサーバーを起動していないか |
復元前へ戻すときも、サーバーを止めてから操作します。復元後の一式を別に退避し、最初に残した復元前データを元の場所へ戻してください。
まとめ:バックアップは戻せる状態まで確かめよう
Rustのバックアップでは、使用中のidentityを特定し、保存と正常停止を済ませてから一式をコピーします。Oxideを使っているなら、別の場所にあるプラグインとデータも保存対象です。
- 日時の違うバックアップを残し、1部はサーバーとは別の保存先へ置く
- 復元前のデータを退避してから、選んだ日時の一式を戻す
- 起動後に拠点、BP、設定を照合してから参加者を戻す
次の更新前にも同じ手順で保存しておけば、変更に失敗したときに戻すデータと場所が決まっています。復旧のあとに設定や運用も整えるなら、Rustサーバーの目的別ガイドから必要な作業へ進めます。









