Skip to main content

Back up a Don't Starve Together cluster as one checkpoint

Back up a Don't Starve Together forest and caves cluster together. Players can move between shards, so a copy of only the forest directory may omit state needed for a coherent recovery. Arrange a short stopped interval for both processes and preserve the shared configuration alongside the shard data.

Map the live cluster before copying

Klei defines the active storage path through the startup options for persistent storage, configuration directory, cluster and shard. Record those effective values for both processes. The usual names Master and Caves help describe a layout, but a hosting template may place the cluster elsewhere or use custom names. Find the live files before choosing what your panel backup should include.

Check which directories the backup feature actually covers. If the shards live in separate services, a backup action on one service may not include the other. Ask support for a paired checkpoint method when your available controls cannot cover the full cluster. Keep token-containing configuration private when you download or share an archive.

Capture a single maintenance checkpoint

  1. Tell players the planned pause and ask them to leave. Record the game build, mod set, cluster identity and time. Keep notes of representative player state in the forest and caves for later verification.
  2. Stop both shards through their supported panel controls and wait for each process to exit. Do not copy one shard while players continue changing the other.
  3. Create the complete cluster archive or the documented paired archives. Include the shared settings and the relevant shard data. Label separate files as one checkpoint with the same date and maintenance reference.
  4. Wait for each backup job to finish. Record completion status and size, then retain an off-server copy or confirm that your plan stores the completed archives on the backup service.
  5. Start both shards and verify ordinary joining and travel. A backup maintenance task should leave players on the original world unless you have separately agreed a restoration.

Check recovery on an isolated copy

Use separate storage and ports for a restoration rehearsal. Stop its processes before loading the checkpoint, restore the shared settings and matching shard data, then adapt only the test-specific access and network details. Prevent ordinary players from confusing the rehearsal with production. Verify known characters, world progress and travel in both directions.

Keep your recovery notes with the archive. Include the build, required mods and the relationship between paired files. A successful download proves that you retrieved bytes; it does not establish that the checkpoint can load or that it includes the caves. Record any part of the verification you could not perform.

Handle a real rollback carefully

Preserve a fresh copy of the current cluster before restoring an older checkpoint. Stop both shards and choose the agreed pair together. Restoring only one shard can create mismatched progress, so involve support if one archive is missing or damaged. Tell players the chosen recovery time and the progress they may lose. Do not delete the current cluster while you are still establishing whether the older copy is complete.

Klei cluster and shard path documentation; Klei shard-specific log locations.

No comments to display