A useful recovery copy must contain the checkpoint you intended to save and the extra files needed to resume your session. A completed archive job proves neither. Make a named save, stop writes, preserve the relevant data, then rehearse loading that copy away from the live instance.
The commands below assume the native Ubuntu installation from our server setup guide: satisfactory.service, user/group satisfactory, HOME /home/satisfactory, install directory /home/satisfactory/server. This is a PC, unmodded example. Confirm these values with systemctl cat and systemctl show before using it; container mounts, Windows service accounts and a different HOME change the locations.
Know what the backup must recover#
Keep a short inventory with the archive: game branch/build, session, named checkpoint, save time, service account, effective HOME, install directory and startup options. Record a visible in-game landmark and known storage contents so restoration can be distinguished from merely loading a similar factory.
| Data | Example location | Recovery decision |
|---|---|---|
| World checkpoints | SaveGames/server | Preserve several generations, not just the latest file. |
| PC blueprint library | SaveGames/blueprints/<session> | Preserve separately from the world. |
| Server identity/settings | SaveGames/ServerSettings.PORT.sav | Keep private; choose deliberately whether to reuse on another host. |
| Installation INI settings | server/FactoryGame/Saved/Config/LinuxServer | Compare against the destination build before restoring. |
| Unit, startup arguments, custom certificates and mod inventory if applicable | Deployment-specific | Record and preserve separately; the example archive does not capture them. |
The table's SaveGames root is /home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames only for this service environment. The server file reference separates persistent state from installation files. Inspect actual files rather than assuming that a panel path named backups contains them all.
PC blueprint modules and metadata are .sbp and .sbpcfg files. A world-only rollback does not restore a deleted library. The separate server settings file also contains access and identity information. Treat archives as private administration data, not downloadable public attachments.
Create a stopped-state archive#
Ask players to pause, create a manual save with a unique checkpoint name and wait for completion. Record the current session and selected file in Server Manager. Do not rely on disconnect or shutdown to provide the final save: the service documentation explicitly separates saving from graceful exit.
Inspect the unit before your maintenance window: it must already use KillSignal=SIGINT for graceful shutdown. Stop the service and inspect the result:
sudo systemctl stop satisfactory.service
sudo systemctl show satisfactory.service \
-p ActiveState -p SubState -p MainPID -p Result
sudo journalctl -u satisfactory.service -n 80 --no-pager
Continue only after a clean shutdown, with no surviving game process or writer to these paths. A failed stop or forced timeout requires investigation. Then run this guarded block only after confirming both source directories exist:
(
set -e
test "$(sudo systemctl show satisfactory.service -p ActiveState --value)" = inactive
test "$(sudo systemctl show satisfactory.service -p MainPID --value)" = 0
test "$(sudo systemctl show satisfactory.service -p Result --value)" = success
sudo test -d /home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server
sudo test -d /home/satisfactory/server/FactoryGame/Saved/Config/LinuxServer
sudo install -d -m 700 /var/backups/satisfactory
satisfactory_archive="/var/backups/satisfactory/state-$(date -u +%Y%m%dT%H%M%S%NZ).tar.gz"
sudo sh -c 'umask 077; exec tar -czf "$1" -C /home/satisfactory \
.config/Epic/FactoryGame/Saved/SaveGames \
server/FactoryGame/Saved/Config/LinuxServer' sh "$satisfactory_archive"
sudo tar -tzf "$satisfactory_archive"
sudo sha256sum "$satisfactory_archive"
)
This archives the complete SaveGames tree, including any blueprint and identity files present, plus the example installation's INI directory. It does not include arbitrary custom certificate paths or systemd units. For a custom layout, inventory symlink targets and external storage separately: this tar command does not follow symlinks. Missing directories, failed reads or a nonzero command stop the block; inspect the problem instead of distributing a partial archive. The block leaves the game stopped. After successful inspection, start it deliberately with sudo systemctl start satisfactory.service, check the journal and verify a client reconnects.
The GNU tar manual documents creation and listing; listing confirms readable members, not that the factory can run. A SHA-256 digest identifies the bytes copied. Save it separately and compare the downloaded archive's digest on another machine.
Keep a copy outside the server#
Transfer the archive over authenticated SSH/SFTP to independent storage. Do not make a public web directory readable just to simplify downloading. Retain multiple dated copies: a successful job after an accidental deletion can faithfully preserve the wrong state. Choose the schedule by how much playtime you are willing to repeat, and take an extra generation before updates or migration.
An archive on the same VPS is convenient for quick rollback but shares its failure domain. Keep an off-machine copy and its inventory; occasionally fetch an older generation and compare its digest. Do not delete the last known usable copy because a new file has appeared.
Restore into staging before touching the live factory#
Choose the checkpoint by session, date and recorded landmark. First preserve the current live state, even if it is broken: it may contain recoverable progress. On a compatible game build, use a separate instance/account with separate storage and no shared mounts or public player access for the rehearsal. Avoid allowing that instance to update automatically into a different build during the check.
Extract your own archive into a new private staging directory, not /home/satisfactory. Inspect its contents there. For a world-only recovery, bring the chosen .sav to the target through Manage Saves, or stop the destination before copying to its verified save directory. Our save migration guide covers ownership and session selection. Restore the matching blueprint directory separately while stopped. For full-instance recovery, compare the saved INI settings and restore only those appropriate to the new installation.
Decide explicitly whether to reuse server identity settings. Copying passwords, certificates and automatic-session selection to a different endpoint can create access surprises. Keep a new host's own identity unless reproducing the old one is an intentional part of recovery. Do not delete ServerSettings to fix a missing world without first preserving it.
Join, check the named landmark and library, make a new save, then perform a graceful restart and rejoin. Confirm that the intended session returns and further saves are writable. Record the tested archive, game build and observed checkpoint. Only that exercise establishes recovery evidence; an active process, successful upload or intact hash does not.
If the wrong factory loads, check the selected session and startup selection before replacing files again. Missing saves call for path/owner checks; a load rejection calls for build compatibility and logs; a missing blueprint library calls for its session directory and reload. Return to the preserved live state if needed, rather than repeatedly overwriting it with uncertain copies.
