Skip to main content

Tune Valheim automatic world backups and save intervals

Valheim has its own world-save and automatic-backup settings in addition to the backups you create in the CloudExa panel. Use this guide to choose native retention and check that the expected files appear. You need startup-setting access, visibility of the configured save directory and enough disk space to retain the copies.

Understand the two schedules

Iron Gate documents -saveinterval in seconds and separate automatic-backup options: -backups, -backupshort and -backuplong. The backup count covers a short-interval copy and subsequent long-interval copies. These settings control Valheim’s native files; they do not change your panel backup allowance.

Record the current values before changing them. Also record the active world name and save-directory override, if present. A correct interval with the wrong directory in view can look like a failed backup, so find the files the running instance actually updates.

Choose a retention budget

  1. Inspect the size of the current world files and existing native backup files in the file manager. Leave space for growth and temporary writes.
  2. Decide how much recent progress the group can accept losing. Choose a save interval with that aim, while leaving room for the server to finish each save.
  3. Pick short and long backup intervals for the periods you want to cover. For example, a short copy can help with a recent mistake while longer-spaced copies cover an older problem.
  4. Schedule a restart, stop the server and preserve the current world with a completed independent backup.
  5. Edit only the native backup fields or supported startup arguments. Keep their units in seconds and retain the same world and save directory.
  6. Start the server and check for parsing, write or storage errors.

Verify files over time

Record a timestamp after a normal save, then inspect the world directory after the selected intervals have elapsed. Check both names and modification times. A file that predates your change does not prove the new schedule ran. Expect the retention pattern to develop over time rather than appear as a full history at the first startup.

Download one completed native backup for inspection, keeping its paired world metadata where applicable. Do not rename a running world’s files to test restoration. Use a separate test environment if you want to prove that a copy loads.

Keep a separate recovery path

Native copies share the server’s storage and quota. They help with a bad in-game event but do not replace an independent backup of the service. Keep a panel backup or downloaded copy before a major update and check the backup job’s completion status.

If disk use rises faster than expected, revert to the recorded retention settings and inspect the actual backup sizes. Download any recovery points you need before deleting surplus copies. Ask support to check unexplained growth rather than removing files whose role you cannot identify. Never delete the active world to make room for its backups.

Official references

No comments to display