Windrose Save Transfer, Backups, and World Recovery Guide

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 save transfer from a local game into the dedicated-server environment. The bad news is that many admins still back up the wrong pieces. Windrose world continuity is not only about a single folder full of raw world data. It also depends on the metadata files that tell the server which world it should expose and how the current server identity is bound to that world. If you only copy the raw save storage and ignore the descriptive JSON files, recovery can become messy fast. As of April 15, 2026, the safest Windrose backup policy is to treat the dedicated-server state as a small bundle: ServerDescription.json, WorldDescription.json, and the corresponding world save tree under R5/Saved/SaveProfiles/Default/.

What each file actually protects

How to move a local Windrose world to dedicated hosting

The official guide already confirms that save migration is supported. Operationally, the safest way to do it is as a controlled cutover, not a casual drag-and-drop while people are still playing. Start by freezing the original world. If players continue joining the local host after you copy the files, you now have two diverging realities and no clean truth source. Stop the local game, identify the exact world you want to preserve, and capture that state in one shot. Then move both the world save and the related metadata into the dedicated-server environment before your first hosted boot.

1. Pick one final local save state and tell the group that the world is frozen for migration.
2. Close the local game completely so the save is not still being written.
3. Copy the world data to the dedicated-server save location.
4. Copy or rebuild the matching metadata files so the dedicated server mounts the intended world.
5. Start the dedicated server and validate the invite code with one user before declaring the migration finished.

If you skip that validation step and simply announce the new code to the whole crew, you risk discovering too late that the hosted server is running a default or stale world instead of the expected one.

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-04-15_1800_pre-hotfix/
    ServerDescription.json
    WorldDescription.json
    SaveProfiles/
    notes.txt
  2026-04-16_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.

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

• Official Windrose Dedicated Server Guide
• Windrose Steam store page