How to Transfer a Windrose Save to a Dedicated Server (2026)

Windrose Save Transfer, Backups, and World Recovery

For most hosted Windrose crews, the world save matters more than the server binary. A reinstall is annoying; losing a ship progression path, a carefully built base, or a persistent crew world is the real disaster. The good news is that the official Windrose dedicated-server guide explicitly supports moving a save from a local game into the dedicated-server environment. The bad news is that many admins back up the wrong pieces. Windrose world continuity is not only about a single folder of raw world data - it also depends on a pointer field in ServerDescription.json called WorldIslandId that tells the server which world folder to mount, and an IslandId field inside each world's WorldDescription.json that must match. If you copy a world folder but forget to point the server at it, the server quietly boots a fresh default world instead. As of June 2026, the safest Windrose backup policy is to treat the dedicated-server state as a matched bundle: the active world folder under the RocksDB tree, ServerDescription.json, and the per-world WorldDescription.json.

What each file actually protects

How to move a local Windrose world to dedicated hosting

The official guide confirms save migration is supported. The safest way to do it is as a controlled cutover, not a drag-and-drop while people are still playing. If players keep joining the local host after you copy the files, you have two diverging realities and no clean truth source. Stop the local game, identify the exact world you want to preserve, copy it, point the server at it, and validate before you announce anything.

1. Freeze the world. Pick one final local save state and tell the group the world is frozen for migration.
2. Close the local game completely so the RocksDB save is no longer being written. Uploading while a process is writing is the classic way to ship a corrupted save.
3. Find your world folder. Open %LOCALAPPDATA%\R5\Saved\SaveProfiles\<Profile>\RocksDB\<GameVersion>\Worlds\ and copy the entire <WorldID> folder. Check RocksDB_v2_Backups too if the live folder looks incomplete.
4. Upload to the server. Place the folder into Windrose Dedicated Server\R5\Saved\SaveProfiles\Default\RocksDB\<GameVersion>\Worlds\ via the panel File Manager or SFTP, with the server stopped. Do not rename the folder - the database relies on the generated ID and renaming will break loading.
5. Point the server at it. Edit ServerDescription.json and set WorldIslandId to the exact copied folder name, and confirm IslandId inside that world's WorldDescription.json matches.
6. Start and validate. Boot the dedicated server and join with one client to confirm the right world loads before you give the invite code to the whole crew.

If the dedicated server keeps generating a fresh world even though WorldIslandId is set correctly, the copied save data is likely incomplete or corrupted: the server detects it, fails to mount it, and falls back to a new world. See the recovery section below.

Why Windrose backups should happen before every risky change

Early Access infrastructure changes tend to cluster around the same risky moments: patches, config edits, save imports, and operator attempts to "clean up" the server root. Windrose adds another wrinkle because the join model is metadata-driven. A server can look almost healthy while still pointing at a broken or unintended world state. That means pre-change backups are not optional ceremony. They are your rollback point when a patch lands badly, a JSON edit goes wrong, or a save import produces inconsistent results.

A good Windrose admin routine is simple:

• Back up before every update.
• Back up before every world transfer.
• Back up before every manual metadata edit.
• Back up before every attempt to "rebuild from scratch."

This may sound conservative, but backup discipline is cheaper than trying to reconstruct what changed after a bad midnight maintenance window.

Recommended backup structure

Do not dump every backup into one anonymous folder. Name Windrose snapshots so a human can restore them quickly under pressure. A structure like the following is enough:

windrose-backups/
  2026-06-12_1800_pre-hotfix/
    ServerDescription.json
    RocksDB/<GameVersion>/Worlds/<WorldID>/
      WorldDescription.json
      (RocksDB database files)
    notes.txt
  2026-06-13_0900_pre-world-import/
    ...

Your notes.txt should answer four questions in plain English:

1. Why was this backup taken?
2. What world was active?
3. What client/server version was running?
4. Did the invite code work before the backup?

Those four lines save more time than many admins realize. They let you choose the right restore point instead of guessing by timestamp alone.

How to test a Windrose backup instead of just hoping

A backup you have never restored is a theory, not a recovery plan. The best Windrose operators occasionally test restores in a non-production path or at least walk through the restore order carefully. The goal is not daily fire drills. The goal is confidence that your backup set is complete. A valid Windrose backup should let you restore the metadata, restore the save tree, boot the server, generate a fresh invite code, and confirm players land in the expected persistent world.

The restore process should look like this:

1. Stop the dedicated server cleanly.
2. Archive the currently broken state before overwriting anything.
3. Copy back ServerDescription.json and WorldDescription.json from the chosen snapshot.
4. Restore the matching save profile data.
5. Start the server and wait for metadata regeneration to settle.
6. Test the new invite code using one client.
7. Only then invite the broader group back in.

If you restore only the world data but leave newer metadata in place, you can create an inconsistent state that looks like partial corruption even though the actual problem is mismatch between descriptive files and save content.

How to recover after a bad patch or mistaken config edit

When Windrose receives a hotfix, many admins jump straight into reinstalling or manually editing files. That is often the wrong first move. If the server was healthy before the change, the fastest route back is usually a controlled rollback to the last known good snapshot. Start with the simplest question: "When did this stop working?" If the answer is "right after the patch" or "right after I edited JSON," you already have a good candidate backup. Restore that state, retest, and only then decide whether you need a binary refresh or a deeper rebuild.

World recovery is easiest when you preserve both the broken state and the last good state. Never overwrite the current files without archiving them first. Even a failed state can contain clues, and sometimes you will want to compare the old and new metadata to understand why the server stopped mounting the correct world.

Recovering a corrupted Windrose save

Windrose has a built-in recovery hook. ServerDescription.json exposes AutoLoadLatestBackupIfHasBroken: when set to true, the server tries to restore broken save files from the latest copy in RocksDB_v2_Backups on boot. That can save your evening - but it can also work against you, because a successful auto-restore quietly replaces your live state with an older backup. Some operators set it to false on purpose so a deliberate manual edit is never silently rolled back. Decide which behavior you want before a crisis, not during one.

If a world will not load and the auto-restore does not bring it back, work in this order, archiving everything before you delete anything:

1. Stop the server and take a full copy of the entire SaveProfiles\Default tree so the broken state is preserved.
2. Try the auto-backup first. Confirm AutoLoadLatestBackupIfHasBroken is true and restart; let the server attempt to mount a copy from RocksDB_v2_Backups.
3. If that fails, restore a known-good world folder from your own external snapshot into RocksDB\<GameVersion>\Worlds\, then re-point WorldIslandId at it.
4. As a last resort, community guidance is to remove the generated RocksDB_v2 and RocksDB_v2_Backups folders and keep only RocksDB, so the game rebuilds its working copies from the surviving database - but do this only after you have archived the broken state, since it is destructive.

The recurring lesson from corrupted-save reports: the auto-backup folder is a convenience, not a real backup strategy. It lives on the same disk, in the same deployment, and a bad import or disk problem can damage it alongside the live save. Your own off-server snapshots are what actually recover a world.

How often should you back up a live Windrose world?

There is no single perfect interval, because backup frequency depends on how active the crew is and how painful lost progress would be. But Windrose is exactly the kind of game where long play sessions create meaningful persistent changes. If a crew spends an evening building, sailing, or progressing together, losing eight or twelve hours of world history will feel severe. For active hosted crews, a practical baseline is:

• Daily backups for moderately active worlds
• Extra pre-maintenance backups before updates or imports
• On-demand backups before known high-risk admin work

Hosts with very active groups may choose more frequent snapshots, but even then the real key is retention discipline. Keep several restore points instead of one rolling overwrite. A corrupt or incomplete backup is useless if it replaced your only good snapshot.

How to avoid restoring the wrong world

Windrose server operators often underestimate how easy it is to confuse similar snapshots. If you are running different crews, testing imports, or maintaining both a launch-week world and a post-hotfix world, vague naming becomes dangerous. Keep each world's history obvious. Use crew names, dates, or deployment IDs. Make it impossible to restore the wrong snapshot by accident. The best backup system is the one that still makes sense when you are tired, rushed, and getting pinged by players.

What not to do during backup and recovery

• Do not copy live files while the server is still writing to them if you can avoid it.
• Do not keep only the world database while ignoring the JSON metadata files.
• Do not perform a restore and then let the whole group test at once before you validate the result yourself.
• Do not assume a reinstallation is safer than a restore. Reinstalls without preserved world state are often more destructive.
• Do not treat restore notes as optional. Humans forget details faster than files do.

Sources

Save paths, the WorldIslandId / IslandId matching rule, the RocksDB_v2_Backups auto-backup tree, and the AutoLoadLatestBackupIfHasBroken recovery flag are documented in the official Windrose Dedicated Server Guide. The Windrose application is Steam app 3041230.