Star Rupture Dedicated Server: Save Persistence After Restart
A restart that appears to create a blank world is a high-risk incident, especially while the tooling is experimental. It does not prove that the save was deleted. First verify which instance, working directory, and world the process selected.
Recovery order
- Stop inviting players and do not overwrite the suspected save.
- Capture the latest server log and exact launch command.
- Check the process working directory and data path used by the current manager/package.
- List available saves in the active instance, not a similarly named template directory.
- Make a copy of every candidate before testing.
- Start the known-good copy in a private test instance and verify the base/progression.
- Point production at the correct world only through the supported manager/package workflow.
Retired universal “fix”
The previous version presented DSSettings.txt, StartNewGame=false, and SaveGameName as universal controls. The current official setup article does not document that contract, so those names must be verified in the installed build before use.
Prevent the incident
- Run the server once, stop cleanly, and record the generated data path.
- Back up before updates, imports, and configuration experiments.
- Keep the working directory explicit in the batch file or panel.
- Use one production instance per world.
- Test a restart immediately after the first successful join.
Healthy restart test
| Check | Expected evidence |
|---|---|
| Process | The intended EOS executable starts from the intended directory. |
| World | The log shows successful loading of the expected save. |
| Client | A trusted player reconnects and sees prior progress. |
| Rollback | A dated pre-restart copy remains outside the live save directory. |
For a local import, see save transfer. For settings, see configuration. If the process is healthy but joins fail, use network troubleshooting.