#Dedicated Server launch continues to create new worlds
1 messages · Page 1 of 1 (latest)
I have the same issue, the world works great on another PC but when I copy it to the server - the server ignores it and creates another world sometimes 2 or 3?
I suspect we missed a step(s) for the fix and it will probably be identified quickly by the Devs.
With a little clarity, I think our issue is leaning toward the folder/file structure we didn't set correctly or a corrupted database as after the patch multiple instances were launched which may have caused the last backup to be corrupted.
Update (Resolved)
As we continued to work through this process and realized the fixed work - thank you to @ebon pelican @woven axle@fierce kiln for the help. Confusion for us was around how the migration and the zip folder naming scheme worked. Sometimes I chase my tail 😕.
@digital token This should help you. I needed to put the pieces together.
Windrose Dedicated Server Save Recovery After Patch / New World Issue
Posting this in case it helps anyone else dealing with the dedicated server creating a new world after the recent patch.
One confusing part is the ZIP file name and structure. In some older backup folders, the ZIP files may not have the _0.10.0_Latest.zip ending, so at first it can look like that file name was only specific to the original person who reported the issue.
Based on the fix discussed in this thread, the newer recovery path expects the backup ZIP to be placed inside the RocksDB_v2_Backups folder structure and named like this:
<WorldID>_0.10.0_Latest.zip
Example:
DA073CF4BF864FED0A9AF81AEED341B6_0.10.0_Latest.zip
The important part is that the WorldID, the folder name, the ZIP name, and the value in ServerDescription.json all match exactly.
What seems to cause the problem
From the thread, the issue may happen when the server fails to load the existing save after the patch and then generates a new world instead.
Another major issue found was that multiple dedicated server instances were running at the same time. That can interfere with the RocksDB save database and may corrupt the save.
Before doing anything else: make sure only one Windrose dedicated server instance is running.
Disable anything that might launch a second copy, such as:
Scheduled task
Watchdog
Auto-restart script
Batch file restart loop
Server manager restart setting
This part matters. If two server instances touch the same save at the same time, the recovery may fail or the save may get corrupted again.
Before starting
Do not skip this part.
- Stop the Windrose dedicated server.
- Check Task Manager and confirm there is no Windrose server process still running.
- Disable any scheduled task, watchdog, or auto-restart script.
- Make a full backup of:
Windrose Dedicated Server\R5\Saved
Also back up:
Windrose Dedicated Server\R5\ServerDescription.json
Do not test directly against your only copy. Make a backup first, then work from the live folder only after you have a safe copy.
Correct recovery folder structure
The recovery structure should look like this:
Windrose Dedicated Server
└── R5
└── Saved
└── SaveProfiles
└── Default
└── RocksDB_v2_Backups
└── Worlds
└── <WorldID>
└── <WorldID>_0.10.0_Latest.zip
Example:
Windrose Dedicated Server\R5\Saved\SaveProfiles\Default\RocksDB_v2_Backups\Worlds\DA073CF4BF864FED0A9AF81AEED341B6\DA073CF4BF864FED0A9AF81AEED341B6_0.10.0_Latest.zip
The folder under Worlds should be the actual world ID, not the server name.
Important ZIP clarification
This part caused a lot of confusion.
The folder structure should be outside the ZIP.
The ZIP file should sit inside:
RocksDB_v2_Backups\Worlds\<WorldID>\
Do not zip the whole Worlds folder.
Do not zip the whole RocksDB_v2_Backups folder.
Do not create this structure inside the ZIP:
RocksDB_v2_Backups\Worlds\<WorldID>\...
Step-by-step recovery
1. Stop everything
Stop the server fully.
Check Task Manager and make sure there are no extra Windrose dedicated server processes running.
If you use a scheduled task, watchdog, or auto-restart batch file, turn it off for now.
2. Back up the current Saved folder
Copy this entire folder somewhere safe:
R5\Saved
This gives you a way back if the recovery attempt does not work.
3. Find the correct world ID
Your world ID should be the long folder name under the world backup folder.
Example:
DA073CF4BF864FED0A9AF81AEED341B6
This value must match everywhere.
4. Prepare the recovery folder
Inside:
R5\Saved\SaveProfiles\Default
the clean recovery structure should be:
RocksDB_v2_Backups\Worlds\<WorldID>\<WorldID>_0.10.0_Latest.zip
If there are old active folders like:
RocksDB
RocksDB_v2
move them somewhere safe or rename them temporarily before testing.
Example:
RocksDB_HOLD
RocksDB_v2_HOLD
The goal is to avoid the server trying to load a bad active database while you are trying to restore from the backup ZIP.
5. Put the backup ZIP in the correct location
The ZIP should be here:
R5\Saved\SaveProfiles\Default\RocksDB_v2_Backups\Worlds\<WorldID>\<WorldID>_0.10.0_Latest.zip
Example:
R5\Saved\SaveProfiles\Default\RocksDB_v2_Backups\Worlds\DA073CF4BF864FED0A9AF81AEED341B6\DA073CF4BF864FED0A9AF81AEED341B6_0.10.0_Latest.zip
Use a game-created backup ZIP if possible.
A manual ZIP may look correct but still fail if it was made from the wrong folder level or from a database that was already corrupted.
6. Edit ServerDescription.json
Open:
R5\ServerDescription.json
Make sure this value matches your world ID exactly:
"WorldIslandId": "DA073CF4BF864FED0A9AF81AEED341B6"
The same ID should match all three places:
WorldIslandId in ServerDescription.json
Worlds\<WorldID> folder name
<WorldID>_0.10.0_Latest.zip filename
If those do not match exactly, the server may create a new world again.
7. Launch manually one time
Do not use the scheduler, watchdog, or auto-restart script for the first test.
Launch the server manually and watch what it creates.
If it works, it should recreate/load the active RocksDB_v2 structure.
If it creates a different world ID, then it did not accept the backup.
Once the server is recovered and confirmed working, restart it manually one more time to verify it still loads the correct world.
Common mistakes that can break the fix
Wrong ZIP structure
The ZIP should not contain the full RocksDB_v2_Backups\Worlds\<WorldID> path inside it.
Wrong world ID
The world ID must match in the folder name, ZIP name, and ServerDescription.json.
Using a manually created ZIP
A manual ZIP may fail even if the folder structure looks right. The safest option is a Windrose-created backup ZIP.
Leaving the scheduler running
If the scheduler launches the server twice, it may corrupt the database again.
Leaving old active save folders in place
Old RocksDB or RocksDB_v2 folders may interfere during recovery. Move or rename them while testing.
Repeated failed launches
Do not keep relaunching over and over without checking logs. Each failed attempt can make the folder situation more confusing.
Sorry about the splits! Discord limitations...
@gritty gate ok thanks I will confirm per your instructions.
Hey guys!
First things first: you’re awesome. Seriously, thank you for sharing your knowledge here. It’s genuinely appreciated and super helpful for other community members. We really appreciate the effort you put into keeping the game and the community awesome.
Just one tiny nitpick: everything here is correct, except the part about manually compiling ZIPs. That might be a bit excessive, mainly because the files inside the ZIPs are formatted by the database in a pretty specific way, so there’s not much you can realistically edit by hand there anyway 😅
Also, we have a SaveWorkflow.md file in the root folder of the game (\R5\SaveWorkflow.md). It’s our attempt at documenting how the new “new” save system works. We’ll also add it to the Dedicated Server root folder in the next patch, so definitely give it a look!
Anyway, I mostly just wanted to stop by and say thanks for the effort you’re putting in. Let us know if you need anything! ❤️