Rust Server Automatic Wipe: A Tested Windows Workflow

A Rust server automatic wipe should run only after a task confirms the exact PC server identity, a stopped process, a verified recovery copy, and an approved file list. Windows Task Scheduler starts a command; it does not know whether that command is safe. This guide lays out a Windows task contract you can test on a disposable identity before you schedule a live reset.

If you would rather manage a Rust server through a game panel, Game Hosting’s Rust PC plans include a game-specific panel, a wipe tool for map resets (with an optional blueprint wipe), and 3 free backup slots. That panel wipe is a manual control; it is not a promise of recurring custom wipe scripts. If your requirement is an unattended recurring task, ask any host which checks its scheduler performs and how it handles a missed or failed run.

Choose the reset policy before scheduling it#

Start by writing down what “wipe” means for this server: a map reset, a blueprint reset, or a full reset. They are different operations. Rust wipe schedules explained covers choosing a calendar and reset type; Rust Server Data Management helps classify a change as a reset, backup, restore, or migration.

Facepunch’s wipetimer settings and PrintWipe output describe the configured wipe time and countdown. The official wipe-timer reference does not describe a job that stops the server or removes files. A timer display is not a file-wipe executor.

Before building a job, record:

• The intended reset type, date, time zone, and whether a missed run should be skipped.
• The Rust PC server build and the one server.identity the job is allowed to touch.
• The files that should change and the data that must stay outside the reset.
• Who will inspect the result and decide when players can reconnect.

Keep the policy with the task definition. A calendar event or wipetimer output is not sufficient authorization to delete data.

Pin the task to one identity and a versioned manifest#

Rust uses server.identity to select the server’s data folder. Facepunch documents .map as terrain and monument data, .sav as world and entity state, and player.blueprints as blueprint data in its server file reference. These roles help you inventory files; they are not a universal deletion recipe.

Use an absolute server root and derive one expected identity path from an allowlist. Before any write, the job should compare the resolved identity path with that expected path and record the executable, identity, build, reset type, and operation ID. If any value is missing or different, stop with an error. Never accept a folder name from an untrusted task argument.

Maintain an exact manifest for the build and reset you tested. Do not use broad patterns such as *.db, *.sav, or * to decide what to remove. Filenames can change with Rust updates, and companions can contain data the selected reset should retain. Rebuild and review the manifest after a game update or identity-layout change. For a file inventory, see Rust Server Save Files.

The disposable Windows test for this guide used Rust Dedicated build 25681086, protocol 2634.289.1. Its map operation archived exactly two generated entries, a .map and a .sav; the new identity then generated a map and reached Server startup complete. The names included a build-specific suffix. This observation supports testing an exact manifest for that build only. It does not prove that deleting those files preserves player blueprints, and you should not copy the test filenames into another build’s task.

Make dry run the default#

The first task action should report its target without changing it. A useful dry-run log shows the absolute identity path, build, operation ID, manifest entries, backup destination, and stop-state check. It should fail when the identity is not on the allowlist, a manifest entry is absent, a path escapes the expected server root, or the destination is the live directory.

Keep mutation behind an explicit apply mode. Before enabling it, test these failure cases on a disposable copy:

1. Change the identity to an unapproved name. The task should refuse before opening a file for writing.
2. Change one byte in the recovery copy. A size or SHA-256 manifest check should fail.
3. Create the operation lock or repeat a completed operation ID. The task should refuse the second run.
4. Start the allowlisted Rust process. The task should detect that exact process and stop without moving files.

In the isolated run for this article, each refusal left the map file unchanged. The active-process check returned a refusal and did not write an operation receipt. Those results apply to the test harness and identity, not to a third-party panel.

Require a stopped server and a restore-verified copy#

A destructive job must not race a server that is still saving. This Windows example refuses while the target Rust process is running; it does not issue a shutdown command or prove that a service manager finished saving. Use the server’s supported stop path, wait for the process to exit, and only then allow the file operation. If your panel or service cannot give you a reliable stopped-state check, do not schedule the deletion through this workflow.

Create the recovery copy from the stopped identity in a different location. Verify its expected files and hashes before the task can proceed. Separately rehearse restoring that copy with a compatible build into an isolated identity and confirm the server loads it. A successful copy command is not a restore test.

The local test run restored a stopped full-identity copy on build 25681086; the disposable server logged Spawning 315 entities from save and completed startup. The test identity had no player blueprint rows and no player with a known blueprint was available. Treat that as a backup-format check only, not proof of player-data retention. Do not promise a map-only or blueprint reset until an ordinary player’s before-and-after state has been checked on the exact operation you intend to automate.

Configure Task Scheduler to skip unsafe retries#

Register the task under the account that can read the server files and recovery destination. Use a fully qualified executable path; the initial test registration with a non-resolvable pwsh.exe failed with 0x80070002. Re-registering the harmless task with the full Windows PowerShell path returned LastTaskResult=0.

For a destructive task, set If the task is already running to Do not start a new instance (IgnoreNew). Keep catch-up disabled unless you have designed and tested a safe missed-run policy. Microsoft documents that StartWhenAvailable defaults to false and that eligible missed tasks can be queued when it is enabled. A missed wipe should normally be logged and reviewed; blindly catching up can reset the wrong cycle. See Microsoft’s multiple-instance settings and StartWhenAvailable behavior.

Scheduler settings are only a second line of defense. The task itself still needs an exclusive lock, a unique operation ID, and a durable completion receipt. Keep logs outside the server identity. Record the planned local time and time zone, the actual UTC start and end, the build, every preflight result, the exact archived paths, and the final exit code. Test what happens if Windows is asleep, the account is logged out, the backup destination is full, or the task is interrupted. The harmless missed-trigger test for this guide created its marker with StartWhenAvailable; it did not test a destructive catch-up or a daylight-saving transition.

Reopen only after a human acceptance check#

After the scheduled task finishes, do not automatically announce a successful wipe just because Task Scheduler reports 0. Review the operation receipt and logs, confirm the new world starts on the intended build, and inspect the server in-game before reopening it. If your policy expects existing blueprints or player state to remain, verify that with a normal player account. This run had no such account, so it makes no retention claim.

If any precondition fails, leave the server stopped, preserve the recovery copy and logs, and use the manual recovery procedure. Do not rerun an operation with the same or a new ID until you know which step completed. A receipt should distinguish “not started,” “files archived,” “server started,” and “accepted by an operator.”

Frequently asked questions#

Does wipetimer automatically execute a file wipe?

No. Facepunch documents it as a timer and countdown. Your task runner must separately stop the server, check the recovery copy, and perform the approved file operation.

What should happen if a scheduled backup fails?

The wipe should refuse to start. Preserve the error, keep the server data in place, and fix or restore-test the backup path before scheduling another run.

How do I prevent a scheduler retry from wiping twice?

Use an exclusive operation lock and a durable receipt keyed to a unique operation ID. Configure Task Scheduler not to launch a parallel instance, and make a completed operation refuse a duplicate ID.

Sources and test scope#

Facepunch documents the timer and identity-file roles in the official references linked above. Microsoft documents task account and scheduling behavior in its task scheduler documentation. The hands-on evidence here is a local, disposable Windows Task Scheduler and Rust Dedicated test on build 25681086; it does not verify a managed-host panel, a production service shutdown, daylight-saving behavior, or player blueprint retention.

Quick answers

Does the Rust wipe timer execute a file wipe?

No. Facepunch documents the timer and countdown; a separate task must check the stopped server, recovery copy and approved file operation.

What should a scheduled wipe do if its backup fails?

It should stop before changing server files, preserve the error and leave the identity available for recovery.

How can I prevent a scheduler retry from wiping twice?

Use a non-overlapping task setting, an exclusive operation lock and a durable completion receipt keyed to one operation ID.