2026 RuneScape: Dragonwilds After 1.0.1: How to Restore Dedicated Server Saves?

Jagex’s October 14, 2026 update notes for version 1.0.1 say the update includes a fix for disappearing world saves, while also warning that other save issues may remain. Do not clear the save directory or create a replacement world as your first response. Stop the server, copy the existing files, verify the client and server versions, then test recovery with a copy. A patch note is not proof that a particular dedicated-server world has been restored.

Suitable for: Dragonwilds dedicated-server owners whose world disappeared, loads incorrectly, or appears out of sync after an update.

Also suitable for: Community admins who need to distinguish world data from character progress, and operators who want a safe save-recovery check before reopening a long-running world.

Start by identifying what has actually failed

“Save is missing” can describe different problems. Treating every symptom as a missing world file risks overwriting useful data or testing the wrong fix.

• The world is absent from the list. The files may still exist, but the server may not be reading the expected save directory or file. A world-list display problem and deleted save data are not the same diagnosis.
• The world loads, but character progress looks wrong. This points to a different question from whether the world itself loads. Do not replace a world save with another file just because a character’s progress is incorrect.
• The client cannot join after an update. A client and server on different game versions, or a server update that did not complete, can look like a save failure. Confirm version state before changing save files.
• The server loads an unexpected world. The intended file may be present while the server selects another save. Check the configured world name, the contents of the save directory, and the server log together.

Keep the diagnosis narrow. A player report on Reddit describes an individual world-disappearance incident, and a separate discussion covers world-save problems. These are useful examples of reported symptoms, not evidence that every server has the same fault or that a particular recovery procedure will work.

Check what version 1.0.1 does—and does not—confirm

The patch history matters, but it does not replace a file-level check. Jagex’s version 1.0.0.8 notes describe a fix for world saves disappearing under specific conditions and say worlds that had already disappeared would need to wait for version 1.0.1. The version 1.0.1 announcement then lists a fix for disappearing world saves and notes that other save problems may still occur.

That history supports a limited conclusion: the update addressed a reported class of world-save problems. It does not confirm that a particular dedicated-server save has been found, repaired, or loaded automatically. Nor does a fix for a disappearing world establish that character progress has been restored. Check the official notes and current server version before assuming either result.

As of October 31, 2026, the official sources above are the basis for the patch claims in this guide. Jagex also mentioned SteamCMD update throttling in an official notice during October 2026; that was a report about the situation at that time, not proof that updates are currently throttled. Check the official announcement list and the server’s own update output before attributing a present-day failure to that earlier notice.

SteamCharts can help confirm that the game has recent player activity, but its player statistics do not measure save failures or search demand. Community discussions show that people have raised save and dedicated-server concerns; they do not establish how often the issue occurs.

Before touching files, preserve the original

The safest first operation is not a restore. It is making sure the current state can still be inspected after troubleshooting.

• [ ] Stop the dedicated server cleanly. Do not copy save files while the process is still writing to them.
• [ ] Copy the complete current save directory to a separate location, retaining the original directory and filenames.
• [ ] If the server host supports access to its files through a shell or remote desktop, use that access to copy the files; do not assume that the hosting service creates backups automatically.
• [ ] Record the configured world name, the client version, the server version, the time of the last update, and the exact message shown when loading or joining.
• [ ] Save relevant server logs before restarting or updating again.
• [ ] Keep the copy clearly separate from the live directory so a test launch cannot silently replace the original.

The official Dragonwilds dedicated-server guide explains save management and recommends backing up files before migration. Use that guide to locate the save directory for the current server setup instead of relying on a path copied from a different operating system, installation method, or older guide.

A backup is only useful if it preserves the state you need. Keep the untouched copy, even if an early test appears successful. If there is no separate backup location available, do not experiment by renaming, deleting, or replacing the only copy of the save.

Where is the Dragonwilds dedicated-server .sav file?

The official guide’s key selection rule is that the dedicated server reads the latest .sav file in its save directory. That makes the directory contents important: a file can exist without being the one the server loads. Follow the official guide for the current save location and file-management details, then compare what is actually on disk with the world the server is configured to open.

Check these items before starting a test:

• The save directory: Confirm that you are inspecting the directory used by the running dedicated-server installation, not a client-side save location or an old installation.
• The .sav files: List the files and their modification times. Note which one is newest, but do not assume that it belongs to the intended world without checking the world name and server log.
• The configured world: Compare the server’s current world name or launch configuration with the name expected by the community.
• The log output: Look for the world or save file the server reports loading, as well as errors that occur during startup.
• The update state: Establish whether the server completed its update before testing the save. If not, the immediate priority is to verify the installation and version, not to edit world files.

Do not remove an older .sav simply because the guide says the server reads the latest one. An older file may be useful as a recovery candidate, but deciding that requires a copy-based test. Keep the originals unchanged until you know which file the server selected and whether it loads the right world.

Handle character-progress symptoms without replacing world data

A world that loads with unexpected character progress needs a separate check from a world that does not appear. The distinction matters because replacing a world save will not necessarily correct an individual character’s state, and it may discard a newer version of the world.

First, write down what is wrong in terms that can be verified: which character appears affected, what progress or inventory is unexpected, whether other players see the same result, and whether the issue began immediately after a patch or server restart. Compare the client and server versions, then review the relevant official update notes for a fix that specifically matches the reported behavior.

The available official 1.0.1 notes confirm a fix for disappearing world saves and warn that other save problems may remain. They do not justify treating every character-progress problem as fixed. If the character remains damaged or out of sync, preserve the original files and collect the server log, version information, and a short sequence of steps that reproduces the issue. Do not use an unverified community command or copy a world save over character-related data.

If a proposed fix requires changing files, apply it to a separate copy first. If the test does not produce the expected character state, stop and retain both the untouched original and the failed test copy. That gives the admin a clear record to compare or provide when seeking support, without turning an uncertain diagnosis into permanent data loss.

Use this decision path before attempting recovery

Use the branch that matches the evidence. If the evidence does not distinguish the branches, pause rather than choosing the most destructive action.

• If the world is missing from the list but the save files remain: verify the official save directory, the configured world name, and which .sav the server selects. Test the suspected file on a copy.
• If the expected world loads but character progress is wrong: keep the world files intact, check client and server versions, and investigate the character symptom separately.
• If the server and client versions differ or the update log shows an incomplete update: finish verifying the update state before evaluating save integrity.
• If the expected files are absent from the server directory: stop before creating a replacement world. Check other known copies or backups and preserve the current directory for comparison.
• If the evidence is inconclusive: leave the original untouched, retain logs, and do not reopen the live world with an untested replacement.

This is the main decision rule: choose a copy-based test when the candidate save exists; return to version and file-location checks when it does not; do not overwrite the original while the failure is still uncertain.

Validate a recovery on a copy before reopening the live world

A plausible file is not a verified recovery. The test needs to establish that the server loads the intended world, that players see the expected state, and that the result survives a clean restart.

• Create a test copy. Duplicate the preserved candidate save and use that copy for the recovery attempt.
• Confirm the test target. Make sure the test server points to the copied files and cannot write into the live save directory.
• Start the server and inspect its log. Check that it selects the expected .sav and does not report a load error.
• Connect with a test account or a designated admin. Confirm that the intended world appears and that its visible state matches what the community expects.
• Check character progress separately. Confirm that the relevant character state is correct; a successful world load alone does not prove character data is correct.
• Restart the test server cleanly. Start it again and repeat the world and progress checks. A result that only appears before a restart is not enough to approve a live cutover.
• Document the selected file and outcome. Record which copy was tested, which server version loaded it, and what was verified.

Only schedule the live change after the copy behaves as expected and the recovery path is clear. Keep the original directory until the live world has been checked. If the test fails, stop the test server, preserve its logs and files, and return to diagnosis rather than repeatedly trying unverified edits.

Make the live cutover only when the evidence agrees

Use a written handover record so the operator doing the change does not have to reconstruct the diagnosis from memory. Include the known-good copy, the file selected by the server, the server version used for validation, the test result after restart, and the rollback location.

After a successful cutover, keep the previous copy until the community has confirmed that the world and relevant character progress are intact. A migration or host change is a separate operation from recovery; move only the verified files, and keep a recoverable copy outside the active server directory.

For a server that runs for a community over the long term, this incident is also a reason to document where Dragonwilds world saves live, how they are copied, and who checks a restore before updates or migrations. Do not infer backup or recovery service from the fact that a server is dedicated. When assessing a host, verify its actual storage, operating-system, and access details from the current SFP Cloud product information, and plan for the operator to manage and validate the game files. For questions about the available access methods and service details, consult SFP Cloud’s help information.

If the current environment is a shared VPS or cloud instance, another tenant’s resource use, instance-level limits, or restricted access to server files may complicate predictable long-term operation. A dedicated AMD physical server can be a better fit when the priority is exclusive compute and direct control of the server environment—but it still does not automatically back up or restore Dragonwilds saves. If that trade-off matters, compare SFP Cloud’s current product details before changing hosts; keep the recovery plan and verified save copy under the operator’s control.