Just Enough Backups (JEB)

Just Enough Backups is a Fabric mod that adds server-side world backups with a usable in-game workflow.

It supports:

• full, partial, and differential backups
• manual backups through commands and UI
• automatic scheduled backups
• configurable public backup/restore announcements
• retention by backup count
• retention by total backup size per world
• restore preparation from the backup browser
• a configurable client HUD popup with live preview
• parallel (multi-threaded) scanning, compression, and restore extraction
• optional Zstandard compression inside ZIP archives
• optional remote backup storage (S3-compatible and WebDAV)
• optional Mod Menu integration

The mod is designed to keep the actual backup logic on the server side while exposing management and configuration through a client UI.

Remote storage

Remote storage is disabled by default. The configuration screen has a dedicated Remote tab with a provider selector, enable switch, and fields for S3 (endpoint, region, bucket, prefix, access key, secret key) and WebDAV (URL, prefix, username, password). For S3, bucket and region are required; the endpoint is optional for AWS and can point to an S3-compatible service. For WebDAV, set the collection URL. Credentials can be configured directly in the screen (secrets are masked) or set in config/justenoughbackups.json or through environment variables, which take precedence and avoid storing plaintext secrets on disk.

Set credentials in the server config or use environment variables, which take precedence:

• S3: JEB_S3_ACCESS_KEY_ID and JEB_S3_SECRET_ACCESS_KEY
• WebDAV: JEB_WEBDAV_USERNAME and JEB_WEBDAV_PASSWORD

Use HTTPS for remote endpoints. Plain HTTP is accepted only for loopback development endpoints. Remote backups are published after upload and SHA-256 verification; their catalog contains the metadata and checksum. Retention protects bases required by incremental chains. Restore downloads each required archive as a stream into isolated staging, verifies its checksum, then verifies the reconstructed world before preparing the world replacement. remoteStorage.maxRetries bounds upload attempts; a failed WebDAV upload restarts compression and transfer, while interrupted uploads are not resumed across process restarts. Do not place credentials in shared or committed config files.

Features

Backup types

• Full: creates a complete snapshot of the entire world at the moment of backup. No base backup is required and it serves as the foundation for later incremental backups.
• Partial: creates an incremental backup containing only the files that have changed since the most recent backup of any type (full, partial, or differential). It uses that most recent backup as its base.
• Differential: creates an incremental backup containing only the files that have changed since the most recent full backup. Differential backups are stored in a separate retention bucket from partial backups, allowing independent retention policies.

Dependencies between backups are tracked. Retention and delete operations respect those dependencies, so required base backups are preserved when newer partial or differential backups still depend on them.

Automatic backups

Automatic backups are driven by per-type schedulers (FULL, DIFFERENTIAL, PARTIAL) and can be configured to:

• run independently based on configured intervals for each backup type
• send optional public warning before an automatic backup starts
• pause when no players have been online since the last backup
• run on server start
• run on server stop

Public announcements can be sent to chat, sent to the action bar, or disabled.

Retention policy

Retention can be configured in two ways at the same time:

• count-based retention
• keep the newest X full backups
• keep the newest X partial backups
• keep the newest X differential backups
• size cap per world
• optional hard cap for the total size of a world's backup folder
• applied to the final published backup set
• respects dependency chains

If a new backup would exceed the configured space cap even after deleting every backup that is allowed to be removed, creation fails instead of publishing an invalid final state.

Performance: parallel processing

Backups and restores use multiple worker threads to speed up large worlds:

• scanning / hashing: the world snapshot scan runs across threadCount threads (up to one per CPU core), reading and hashing files in parallel
• compression: the ZIP archive is written with parallel compression
• restore extraction: backup ZIP files are extracted across threadCount threads

The number of threads is controlled by threadCount in the config and can be set between 1 and the maximum number of CPU threads (default: CPU cores minus two). Lower values reduce CPU usage; higher values speed up large worlds.

ZIP compression uses DEFLATED by default, with deflateCompressionLevel controlling the compression level (1–9, default: 6). compressionMethod: "ZSTANDARD" writes ZIP method 93 entries and zstdCompressionLevel controls the level (1–22, default: 3). Both DEFLATED and ZSTANDARD use parallel multi-threaded compression. For Zstandard, large entries are spilled to temporary scratch files to bound memory usage. Existing DEFLATED archives remain supported. Zstandard archives require the mod's Zstandard reader and may not open in older ZIP utilities.

Backup management UI

The backup browser includes: