Hi Paul,
Three approaches I've seen work, roughly from least to most effort:
1. Nightly export to your own warehouse. Once a day, run sacct --parsable2 --allusers --duplicates for the previous day (well inside your 1-week query limit) and write it to Parquet or Postgres somewhere offsite. It's one small query per day, so it barely touches the production dbd, and nothing in it ever gets purged. For history, load your existing archive files into a throwaway slurmdbd with sacctmgr archive load, export those once the same way, and you have one continuous record.
2. A jobcomp plugin. JobCompType=jobcomp/elasticsearch (or jobcomp/kafka on recent versions) streams each finished job record off the controller asynchronously, independent of slurmdbd and its purge schedule. The catch is that jobcomp records carry fewer fields than the full accounting tables, with less step-level detail, so check they cover what you need for billing.
3. Change-data-capture from the MySQL binlog. A CDC tool such as Debezium or Maxwell reads the binlog and applies inserts and updates to an offsite copy, and you drop the DELETE events the purge generates. It's the closest thing to "a replica that ignores purges" and doesn't slow the cluster, but it's more moving parts, and schema changes on Slurm upgrades need watching.
For raw data you can reprocess in new ways, option 1 is the one I'd start with. It's simple, it's plain files, and it survives upgrades.
Jim Jardine