[ChatDisabled]

Why

Backups still cause sync thread hitch warnings on a busy host, even at qbx_db_backup_max_mb_per_second 6. Apart from launching mariadb-dump, all backup work happens inside the FXServer process:

• Deflate runs on libuv's threadpool, which every Node resource and FXServer itself share.
• CRC, SHA-256 and the stream plumbing run on svMain.

All of these threads run at normal priority. So the backup competes on equal terms with svSync, which ticks at 120 Hz and warns at 100 ms.

What

• Child process. The dump, pacing, zip and SHA-256 now run in a child_process.fork child (dist/spool.js) at below-normal priority. FXServer forks itself with --fork-node22, the same path the stock yarn builder uses. The server process only receives a progress message once a second and the final size and hash.
• Sinks. Sinks no longer zip. Each one hands out a spool path and delivers the finished file: rename, dashboard PUT or S3 upload.
• Cleanup. Cancelling (resource stop, timeout, or the server going away) disconnects the child. The child then kills the dump and deletes the partial zip.
• Requirements. add_unsafe_child_process_permission is still the only server.cfg requirement.
• maxBytes. maxBytes on UploadSink/S3Sink is now only checked once the zip is written. Nothing sets it today.

Measurements

Measured in the real dev FXServer pinned to 2 logical CPUs. Each run dumps 1.75 GB of SQL into a 275 MB zip at level 6. The 120 Hz probe is a normal-priority thread on the same CPUs, standing in for svSync.

Run	Duration	FXServer CPU	svMain max gap	120 Hz probe max
current, pace 6	278 s	25.6 s	18 ms	14 ms
this branch, pace 6	278 s	6.7 s (about 4.5 s of it is the idle server)	10 ms	8 ms
current, unlimited	69 s	19.6 s	10 ms	8 ms
this branch, unlimited	16 s	0.5 s	79 ms	72 ms
deflate on the main thread, unlimited	18 s	17.9 s	349 ms (server thread hitch warnings)	16 ms

Without a pace limit on 2 cores, the child saturates the CPUs. Even at low priority, Windows' anti-starvation boosts then cause short system-wide stalls, so the pace convar still matters. The current code only avoided this at unlimited pace because every zlib chunk waits for svMain's 1 ms loop pump, which capped it at about 24 MB/s.

Testing

• bun test, including new forkSpool tests. Typecheck and lint pass.
• Integration test against a real MariaDB.
• CLI backup under plain Node.
• In FXServer:
  • Backups at pace 6 and unlimited.
  • The zip passes a CRC check.
  • Stopping the resource mid-backup ended the child and the dump and removed the .part file.
• Not tested:
  • A Linux host.
  • The dashboard and S3 upload phases inside FXServer. Those code paths are unchanged apart from receiving the spooled file, and they are unit-tested.