Well, as the guy who wrote that backup stuff, I can add some detail.
Users will take up very little space in a table. You can test that yourself. Even adding thousands of users with no tickets will take very little space.
Similarly, thousands of tickets with no attachments use very little space. The big space taker is the attachments table. Hence that script+mod which exposes archive options to the deletion process, by modifying the core delete function it means that users who can delete tickets don't even know they are archiving and it saves the company from possible liability issues.
I'll get to work and make it into a 1.9+ plugin. Haven't seen much plugin documentation, suppose I should look again.
Any further ideas or options you would like added? I was thinking of an admin option for backup location. An email admin report of daily deleted tickets and possibly a "archive space in use" and a "current db space in use" detail on admin view, or in the graphs..
Would be cool to generate a report of users with the most space wasted. Perhaps even emulate an email inbox size of message summary on the main page. Which could be useful for tiny installs where space is at a premium.
Perhaps an anti spam option where a user has a set limit on the amount of ticket storage space, something like 50mb each. It wouldn't prevent a ddos, but could annoy your largest client with lots of problems... Do could be good or bad.
Could even as options to archive via ftp, remote servers might not want to archive directly.
I'm thinking database backups as well. But that isn't really the purpose of the software. Could be good for a plugin though, where this is the sole purpose of the web space.
If building the infrastructure to backup things via ftp, it could be handy to simply export the SQL or as a json object meaning it could be much easier to recover. The initial implementation assumes that the goal was to really remove but keep a copy in a printable or readable state, rather than worrying about a recoverable version. That could be useful!
There will be complications should fields change after backup.. Or if users or staff are deleted. Or if you have promised to keep all old tickets for users to refer to. Perhaps we could add a staff message saying attachments have been archived and give a location, so if a user requested further information about an ancient ticket which heavily relied on attachments they could then request an admin recover the attachments.. Assuming the database has capacity to retain all ticket data apart from attachments.
I'll continue to think on it, but welcome all ideas and preferences. If someone will get benefit from it, then it's probably worth doing.