Direct answer

A backup can slow a server through disk reads, compression CPU and storage contention. A fast archive is not useful if the world snapshot is inconsistent. Prefer a documented consistent snapshot or a clean stop before copying files.

Measure backup impact

  1. Record the scheduled backup time, player count and /spark tps statistics before, during and after the job.
  2. Compare disk utilization and OS CPU activity; a profiler may show only part of a storage bottleneck if work happens outside the JVM.
  3. Verify whether your backup software takes a consistent snapshot, coordinates saves, or simply copies active files. Never assume a live tar or rsync copy of changing region files is a consistent backup.

Safer workflow

For the simplest reliable full backup, stop the server cleanly, copy the full world set plus configuration and plugin data, and then restart. If your platform supports consistent filesystem snapshots or a purpose-built backup plugin, follow its documented procedure. Avoid an unreviewed /save-off workflow that might leave saves disabled.

Version and safety notes

A backup of live-changing region files can be inconsistent. Use a documented snapshot or clean stop, and verify restoration away from production.

Reduce cost and verify

Schedule compression off-peak, avoid archiving already-compressed data unnecessarily, and keep completed archives on a different volume or machine. Check the backup manifest and periodically restore onto a separate test server. Compare peak and 95th-percentile MSPT before and after the scheduling change.

References

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