7 Days to Die Random Generated World Missing After Move

Protect every version before repair

1. 1Shut down the process and confirm 7DaysToDieServer.exe has exited.
2. 2Copy the unexpected current save, generated-world folders, active XML, and log to a quarantine directory.
3. 3Do not rename, merge, or delete either the source backup or current generated map while identifying the pair.

Identify the original world identity

• Read the active XML's save name, world name, game-world selection, and SaveGameFolder.
• Check the last known-good startup log for the generated world loaded by that save.
• Match backup timestamps and folder contents; do not pair a recent save with an unrelated older generated map.
• Confirm that the destination service still launches the same owner-named XML.

Restore the pair while stopped

1. 1Restore the complete save tree to the path selected by SaveGameFolder.
2. 2Restore the exact user-generated map directory under the destination GeneratedWorlds root.
3. 3Correct absolute paths in a copied XML only when the destination truly differs; preserve save and world names.
4. 4Keep permissions and compatible mods from the same recovery point with the world.

Verify without overwriting the backup

Start privately and inspect the log before joining. Verify terrain, a known base, player progress, and world time. Run saveworld, issue native shutdown, restart again, and repeat a small verification. That second load proves the restored identity persists.

Why a save-only backup is incomplete

Stock maps ship with the game, but random generated terrain is user data outside the ordinary save. Future backup jobs must capture the XML, save, generated world, permissions, and mods after the native process exits, then test a copy-based restore.

Distinguish a matching name from a matching generated map

Two folders can carry a familiar world label without containing the same generated terrain. Use the last known-good startup log, folder timestamps, file sizes, and the XML's world/save identity to establish provenance. If the provider export includes several generated worlds, keep each untouched until one can be paired with the save on a private recovery copy.

Do not combine chunks or copy selected files between generated maps to make a base appear. That can produce terrain seams, misplaced points of interest, or a world that opens once and fails later. If no same-snapshot pair exists, preserve every candidate and test complete pairs from newest to oldest; record which pair loads, saves, shuts down, and survives a second start before declaring recovery successful.

Rank recovery candidates without rewriting them

Build an inventory before the first recovery launch. For each candidate save, record its save name, last write time, size, XML selector, and the generated-world folder named by the last corresponding startup log. For each generated map, record its folder name, creation/write window, size, and whether its files predate the last known-good session. A same-name folder with a timestamp from the failed move ranks below a complete pair captured while the source server was stopped.

Test candidates as read-only source copies in descending confidence: a documented same-snapshot pair first, then the last native backup with its matching map, then older complete pairs. Place each trial in a new recovery root and point a copied XML at that root. Never launch the archival source in place, and never let a failed trial donate individual map files to the next one. That discipline preserves the evidence needed if the newest candidate has already been altered.

Use explicit stop conditions during recovery

Quarantine every stopped trial with its log instead of deleting it. A failed load can still prove which selector, path, or generated map is wrong. If no complete pair reaches a recognizable world, report the backup boundary honestly and retain all sources for specialist analysis; improvising a hybrid map can make a partial recovery unrecoverable.

• Stop if the startup log names a different save, generated world, or SaveGameFolder than the trial manifest.
• Stop if terrain, points of interest, or a known base occupy the wrong coordinates; do not save merely because the server accepts a connection.
• Stop if required mods or permissions from that checkpoint are absent and their loss could remove world-owned data.
• Stop if a clean shutdown writes outside the isolated recovery root; the service is still selecting another path.

Pass a world-specific verification matrix

A credible restore proves more than the login screen. Check terrain shape at multiple known locations, at least one player-built base, a distinctive point of interest, player inventory/progression, permissions, world time, and any required mod-owned objects. Then run saveworld, use the native shutdown path, confirm the process exits, and verify that the expected save files—not the archive—changed inside the trial root.

Restart from the same launch definition and repeat a smaller join check with the same character. Keep the accepted pair's manifest, XML checksum, log, generated-map inventory, and post-restart result beside a new stopped backup. Future backup jobs should capture the full save and GeneratedWorlds roots in one coordinated checkpoint so their provenance does not have to be reconstructed after the next move.