Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

It would be helpful if we had a slider that could select the number of backup copies of each team's tables to keep, and checkboxes to select the situations that would warrant making a backup copy: received a sync (full or two weeks), started a raid session, ended a raid session. And finally, a button to make a backup copy on demand.

Backups would be a rolling copy, so if I ask to save 10 backups, when the eleventh is saved, the oldest is removed. A restore tab would list the backups, the timestamp of the backup, and the reason ("Received full push from playerXYZ").

Describe the solution you'd like
A clear and concise description of what you want to happen.

See above.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

I currently keep physical copies of the WTF files, but manually moving them in/out is a pain.

Additional context
Add any other context or screenshots about the feature request here.

I don't yet know if this is a sync bug, an incompetent user, or a malicious user... but we've seen several instances lately where specific players seem to be getting out of sync (showing a red sync light) but attempts to sync don't fix the problem and sometimes seems to make it worse.

It would also help if versions rejected syncs from newer versions, giving the user a warning they can't receive syncs and need to update, since we've seen at least once that mismatched versions failed to sync properly. but at the rate you're publishing new versions, it's just not possible to keep 200 people always on the same version.

So, if we could maintain known-good snapshots that we could revert to, it would help us recover from whatever it is that's going on lately.

We are aware of a sync indicator issue. We've been able to validate that there is nothing wrong with the tables themselves, and are currently in the process of reviewing. Making backups of the tables doesn't actually solve the issue, and would exponentially explode the size of the saved variables. That alone is enough for us to say that we're not going to implement this change.

That being said, we are trying to track down a list of actions to exactly reproduce the issue, as we've not been able to lately.