Backups, Restore & Transfers

← All guides · MANAGE & MAINTAIN

---

There are two different workflows:

Workflow	Intended use
Selected-server backup/restore	Preserve or restore files in one server's installation
Synix export/import	Transfer the main Synix data tree and, with encrypted export, portable protected credentials

Neither replaces checking where your game actually stores its worlds and saves.

Server backups

Use the backup action in Server Options, or enable Backup on Start.

1. Stop the server through Synix and let its processes exit.
2. Review the backup source, destination, estimated size, and available space.
3. Confirm the backup and wait for completion.
4. Use Open Backup Folder to locate the result.
5. Keep the archive and its integrity receipt together.

The current backup routine archives the selected server's installation folder, not only a small world-save subfolder. Large installations therefore need substantial time and storage.

Saves in AppData, Documents, another drive, or a game-owned virtual machine may be outside that coverage. Back those up separately using the game's supported method. A Dune deployment-folder ZIP must not be assumed to be a consistent backup of a running VM/database.

Location and retention

The default root is C:\Synix\BackupGames. Settings → Backups lets you choose another root and set the saved-backup limit.

Use the selected server's Open Backup Folder action rather than guessing its subfolder name.

• The backup destination must not be inside the source server folder.
• Changing the root does not automatically move or delete old archives.
• Retention removes older archives when the configured limit is exceeded during backup creation.
• Copy long-term recovery points outside the rolling-backup location if you need to preserve them.

A disk failure can destroy both a server and its backups if they are on the same disk. Keep another verified copy of important saves.

Backup failures and cleanup

A configured custom destination must be available and writable. Synix reports an error rather than silently switching to the default root.

The new archive and integrity receipt are completed before retention runs. Cleanup does not select the just-created backup, even if an older archive has a future timestamp. A locked old archive produces a warning without deleting the new backup.

An incomplete backup does not count as success. When Backup on Start or a maintenance backup was requested, failure prevents the following update/start. Manual failures are also shown in the dashboard and Minecraft Control Center.

See Workflow Safety & Recovery for the shared failure behavior.

Verify and restore

Use the backup restore workflow in Server Options where available, or Minecraft Control Center → Backups. Full-server restore entry points share the same recovery and settings-completion path.

1. Stop the server and make a separate copy of anything newer you may need.
2. Select the correct archive for the correct server.
3. Review its date, size, and integrity status.
4. Verify the archive before restoring. New Synix backups have SHA-256 receipts; older archives may be marked as legacy.
5. Read the restore confirmation. Existing installation contents may be replaced.
6. Let staged restore/recovery finish without closing Synix or unplugging storage.
7. Start the server and verify the intended world and configuration.

An integrity check detects unexpected changes relative to a receipt; it does not prove that the game saved a healthy world or that the archive came from a trusted person.

Do not extract a ZIP over a running server as a shortcut. Do not delete recovery/rollback files after an interrupted restore until you have investigated the recovery message.

Restore also refreshes Synix's settings

After activating the restored files, Synix reads the game's mapped common settings into its saved entry. This can include names, passwords, ports, worlds, and player limits where supported. It does not guess unknown keys or rewrite restored configs merely to read them.

Minecraft additionally refreshes runtime information and marks older workspace change records as replaced by the backup. They remain visible but cannot be undone against the restored files.

If settings cannot be saved, the result is partially complete: the files are restored but Synix's settings are not yet synchronized. The previous installation and recovery record are retained, and Start is blocked.

Correct the reported problem and retry Start; synchronization is retried before launch validation, updates, or startup. Reopening Synix does not discard pending recovery. Do not delete recovery files to clear the warning.

An interruption before file activation completes follows the original-folder recovery path. Read the specific message rather than manually mixing old and restored folders.

Export an entire Synix setup

Open Settings → Backups and use the transfer controls.

1. Stop servers and finish active installation, backup, and maintenance work.
2. Choose encrypted export or normal export.
3. Select a destination outside the source tree.
4. Review size, temporary-space requirements, and the estimate.
5. For encrypted export, choose a strong transfer password and store it separately.
6. Wait for the .synixbackup package to finish, then verify it.

The export packages the main C:\Synix tree. Custom server or backup folders outside that tree need separate handling. Check those paths before moving to another PC. Ordinary Windows application preferences may also need to be reviewed on the new account.

Encrypted versus normal export

Encrypted export protects package contents with a password and includes the supported portable credential-transfer workflow. On import, supported secrets can be protected for the destination Windows account.

Normal export does not encrypt the package. Game configuration files and logs inside it may expose secrets. Windows-bound encrypted Synix values do not automatically become usable by another account just because their files were copied.

For a different PC/account, use encrypted export if you need supported credentials transferred. Keep the transfer password private; do not publish the package or upload it to an issue.

Import a Synix package

1. Keep a separate backup of the destination's current Synix data.
2. Open the import/verification controls in Settings → Backups.
3. Select the intended package and supply its password if requested.
4. Verify it and review the destination and disk requirements.
5. Read overwrite/replace warnings before starting import.
6. Let staging, validation, and recovery complete.
7. Review server paths, credentials, ports, schedules, and backup locations before starting anything.

Keep the original package and old installation until you have checked the imported servers. Reconnect Satisfactory if its local identity/certificate or Windows-protected connection no longer matches.

Importing a Synix package is not the same as registering an existing server folder.

Data upgrades

Synix migrates supported older server-data formats and preserves a pre-migration copy named servers.json.before-data-v<version>.bak.

Do not repeatedly replace the active database with older copies while Synix is running. If a migration or import fails, preserve the files and use Troubleshooting & FAQs.