Direct answer

Compression trades CPU time for smaller backup files and transfer volume. A higher level is not necessarily better on an active Minecraft host, especially when backups coincide with player peaks.

Separate copy and compression costs

  1. Use a cleanly stopped server or a verified consistent snapshot as input; do not measure by archiving live-changing world files.
  2. Test two archive settings on the same snapshot while logging elapsed time, resulting size and system CPU utilization.
  3. On Linux, inspect the archive with tar -tf backup.tar.gz | head before any extraction. Test restoring the archive to a separate directory or test host.

Choose a practical approach

For an example gzip archive, tar -czf /backup/server-test.tar.gz -C /srv/minecraft . writes the archive outside the source directory; run this only on stopped or snapshotted data and replace the example paths. Compression on the game host can compete for cores; consider off-host compression or a low-load window.

Version and safety notes

Compression tools and paths vary by host and OS. Examples are for consistent offline or snapshotted data; no production backup should be overwritten until a restore test passes.

Verify and keep a rollback

Measure total backup duration, file size and affected-player MSPT; also confirm the entire archive actually extracts and that plugin data and all worlds are present. Do not replace an existing good backup with an untested archive solely to save storage.

References

Check documentation for the versions and hosting environment you actually run.