(Incrementals) Ensure proper handling, as these natively use directories

[lsthompson]

When pkgacct --incremental runs, it creates/updates a directory (cpmove-username/) not a tar.gz. BackBork currently compresses this to .tar.gz and deletes the directory — defeating the purpose of incremental backups.

Next run starts from scratch. We need to overhaul this methodology. @velocity08 what do you reckon re: below for remote?

Options by Destination Type

Destination	Option	How It Works	Trade-off
Local	Keep incremental dir	pkgacct --incremental updates dir, we tar for UI display/download but keep dir	✅ Works well, uses disk space for dirs
Remote	A: rsync mode	rsync the incremental dir TO remote (only changed bytes transfer), then delete local dir	Remote stores dirs not tars
Remote	B: Full only	Disable --incremental for remote, always full tar.gz	Higher I/O but simpler
Remote	C: --use_backups	Uses previous remote backup as template (cPanel extracts, diffs, re-tars)	Still I/O heavy, defeats purpose

rsync Approach (Option A) for Remote

1. pkgacct --incremental → creates/updates local cpmove-user/
2. rsync -avz --delete cpmove-user/ remote:/backups/user/
3. rm -rf local cpmove-user/  (don't keep locally)

[lsthompson]

The local approach is also problematic as-is. Native tooling we're leveraging does not use incrementals properly.

It is leveraging a single folder, and just writing diffs into that folder - so there is no restore point whatsoever.

To fix this for local and remote, ultimately we would have to developer tooling for this incremental case.