As such it only saves/restores specific files/folders. This is what makes the backups so small, relatively fast and allows the use of TKLBAM as a migration tool between various (different) versions of TKL. To make it work in the way you expected would break it for other (legitimate) usage scenarios.

IIRC you can see what files/folders TKLBAM is saving by running a simulation (either run from the Webmin module or see the docs for details). You can also explicitly include or exclude particular files as you desire.

Generally though if you only edit/add files in places where TKLBAM expects you to, all should work as planned. If you start playing with files in 'naughty places' then TKLBAM will not back them up by default, and although you can override it (ie make it back up the 'naughty places') you risk other issues by editing/backing up/restoring files in these places (hence why they are considered 'naughty'). Having said that it is possible that the devs have overlooked something and a location that ideally should be saved has been missed.

So long and the short of it is if your server has been conpromised, best practice is to launch a fresh TKL instance (of the same type as your backup relates to) and restore your backup to that.

Although best practice would also mean that you are continuously checking that your backups work as planned by testing them regularly (in a fresh instance). It doesn't matter how often you do backups, if you aren't sure that they will work when you need them, what's the point?! Restoring backups to a fresh AWS instance is fantastic for testing as it is fast and will cost you very little (literally cents...).