Windrose Troubleshooting

Windrose Server Keeps Generating a New World

Your Windrose server loads an empty world and WorldIslandId changes back after every restart. Find out why editing the ID never fixes it, and how to restore the world you meant to load.

Last updated: August 31, 2026

4.9

735+ Satisfied Customers

You point WorldIslandId at your world, restart, and land in an empty world. You check the config and the ID has changed to something you have never seen. You set it back, restart, and it happens again.

Editing that field will never fix this. Here is what is actually happening and how to get your world back.

What the Server Is Doing

Windrose does not load worlds from the folder most guides point at. On every startup it:

  1. Scans R5/Saved/SaveProfiles/Default/RocksDB_v2_Backups/Worlds/ for world folders
  2. Reads each world’s <world-id>_<version>_Latest.zip archive
  3. Extracts each archive over the matching folder in RocksDB_v2/<version>/Worlds/
  4. Loads the world named by WorldIslandId

RocksDB_v2 is a working copy that gets rebuilt from those archives on every boot. The archives in RocksDB_v2_Backups are the real save.

If step 2 finds no archive for the ID in WorldIslandId, the server treats that world as nonexistent. It generates a fresh one and writes the new world’s ID into ServerDescription.json. That is the ID you keep seeing appear.

The two most common ways to end up here:

  • You uploaded a raw world folder into RocksDB_v2/. It was discarded on the next boot because there was no archive to restore it from.
  • A world folder under RocksDB_v2_Backups/Worlds/ was deleted or renamed. Cleaning up “extra” worlds does this.

Step 1: Confirm It From the Log

Open R5/Saved/Logs/R5.log in File Manager, or download it over SFTP, and look at the most recent startup.

A failing boot looks like this:

UR5CoopIslandCollection::Init      ... Worlds count: 0
UR5CoopRootDocumentBackup::RestoreBackup   R5BLIsland[53962375...] ... Latest requested
R5BLIslandCntr::CreateIsland   Island was created. Id 065174E68FFD45EE548F03A5AF01FC37

CreateIsland Island was created. means the server gave up looking and generated a world. The ID on that line is the one that will appear in ServerDescription.json after shutdown.

A healthy boot names your world instead:

UR5CoopRootDocument::RestoreDocument  R5BLIsland[9BFA361CEA044A08919986B7F32066A8] ... bIsOk true

bIsOk true means the archive was found, unpacked, and verified. If you see this line with your world’s ID, the world loaded and any problem you have is a different one.

Step 2: Find Out Whether the World Still Exists

Stop the server first. Then, in File Manager, open:

R5/Saved/SaveProfiles/Default/RocksDB_v2_Backups/Worlds/

Each folder here is named with a 32-character hex world ID and should contain a file named <world-id>_<version>_Latest.zip.

Three outcomes:

Your world’s folder is here and contains a _Latest.zip. The archive exists, so the problem is the pointer or the filename. Skip to Step 4.

Your world’s folder is here but has no _Latest.zip inside. The server cannot restore a world without its archive. Treat this as a missing world and go to Step 3.

Your world’s folder is not here at all. Go to Step 3.

If you are not sure which folder is which, open a _Latest.zip and read AdditionalRecordFiles/WorldDescription.json. The WorldName field gives the in-game name.

Step 3: Restore the World From a Copy

You need a _Latest.zip for the world. In order of preference:

From your PC. If the world started as a singleplayer save, the original is still there. Press Win + R, paste %LOCALAPPDATA%\R5\Saved\SaveProfiles\, open your profile folder, then RocksDB_v2_Backups\Worlds\.

From a WinterNode backup. WinterNode takes full server backups every 12 hours. Restore one from before the world went missing and pull the archive out of it. See Backing Up Your Windrose Server.

From an older Windrose archive. A world folder often holds dated archives alongside the _Latest.zip. An older one costs you some progress but is better than nothing. Copy it, rename the copy to end in _Latest.zip, and keep the world ID and version at the front of the name unchanged.

Once you have the file, put it on the server at:

R5/Saved/SaveProfiles/Default/RocksDB_v2_Backups/Worlds/<world-id>/<world-id>_<version>_Latest.zip

Full upload instructions, including SFTP, are in How to Upload an Existing World to Your Windrose Server.

Step 4: Check the IDs Match

Windrose matches your world ID in three places, and all three have to agree exactly, including case:

  1. The folder name under RocksDB_v2_Backups/Worlds/
  2. The ID at the front of the _Latest.zip filename
  3. WorldIslandId in R5/ServerDescription.json

Common mistakes:

  • The ZIP was extracted after upload. The server wants the archive intact, not its contents.
  • The folder or file was renamed to something readable like MyWorld. Windrose relies on the generated hex IDs and cannot match a renamed folder.
  • The ID was retyped rather than copied, and a character is wrong or the wrong case.
  • The upload was interrupted. Compare the file size against the copy on your PC. A truncated ZIP fails the same way as a missing one.

Step 5: Set WorldIslandId With the Server Stopped

This is the part people get caught by twice.

The server maintains ServerDescription.json itself and rewrites WorldIslandId whenever it loads or creates a world. An edit made while the server is running can be overwritten, so the change looks like it saved and then vanishes.

  1. Confirm the server is fully Offline in the Game Control Panel, not just stopping

  2. In File Manager, open R5/ServerDescription.json

  3. Set WorldIslandId to your world’s 32-character hex ID, copied from the folder name:

    "WorldIslandId": "9BFA361CEA044A08919986B7F32066A8"
  4. Click Save, then Start the server

Step 6: Verify

Give the server a minute to come up, then check R5/Saved/Logs/R5.log for:

UR5CoopRootDocument::RestoreDocument  R5BLIsland[9BFA361CEA044A08919986B7F32066A8] ... bIsOk true

Then restart the server once more and reopen ServerDescription.json. If WorldIslandId still holds your ID after that restart, the world is restoring properly and it will keep doing so.

If the ID changed again, the server still cannot read your archive. Go back to Step 4 and check the filename and the upload size, then confirm the archive is in RocksDB_v2_Backups and not RocksDB_v2.

Avoiding This Next Time

  • Treat RocksDB_v2_Backups/Worlds/ as the only real save. Never delete anything in it.
  • Ignore RocksDB_v2/. It is rebuilt on every boot, so editing it has no effect.
  • Stop the server before editing ServerDescription.json, every time.
  • Back up the archives and ServerDescription.json together before any world change. See Backing Up Your Windrose Server.

Frequently Asked Questions

Because the server cannot find the world that ID refers to. On startup Windrose restores each world from its _Latest.zip archive under RocksDB_v2_Backups/Worlds/. If no archive matches WorldIslandId, the server generates a new world and writes that new world's ID into ServerDescription.json. The reverting ID is a symptom of the missing archive, so editing the field again will never fix it.

Not necessarily. The server generating a new world does not delete your old one. Check R5/Saved/SaveProfiles/Default/RocksDB_v2_Backups/Worlds/ for other world folders, and check the original copy on your PC under %LOCALAPPDATA%\R5\Saved\SaveProfiles\. A world is only lost for good if its _Latest.zip archive was deleted.

No. RocksDB_v2 is a working copy that Windrose rebuilds from the backups tree on every startup. Anything you place there by hand is overwritten on the next boot. The archive has to go into RocksDB_v2_Backups.

You edited it while the server was running. The server maintains ServerDescription.json itself and rewrites WorldIslandId whenever it loads or creates a world, so it can overwrite a change made against a running server. Stop the server, wait for it to go fully offline, then edit.