It does not by default (slowly) check the contents, but it does look at file metadata such as time stamps, which you would be hard pressed to not change with what you did. Having noticed something changed, reading through the file would be the next step to find out exactly what blocks changed to upload those.
is an example of a job log file. It examines the source area, has to open a few files, and finds changes.
If you still had old database somehow after the SSD wipe, it could be examined quite carefully for clue.
Recreating the database could also have clues, but it’s not clear how well that will work at the moment.
If you had a database, a compare would be the somewhat user-friendly way to show the modified files.
Specific details of what blocks changed would not be in the output. That needs a DB bug report or you driving a database browser under direction, but again there is the question of how to get the database.
Without that, your question can be somewhat answered by downloading the dlist files for two backups (noticing that the timestamp in the filename is 24-hour UTC), decrypt if needed with a tool, and finding that file in filelist.json. If its information changed, that suggests that some change was backed up.
How the backup process works but you’d still have to fish around different dates to find a change point.
It’s difficult, but that’s how life is without a database. If you’d like to try any of these methods, just ask…
On the other hand, are you saying you got a database and are looking at tables? We can continue that.
The advantage is that rather than having to look in all backups, you can identify where a path changed.
File table has all versions of all paths. Type yours into filter at top of Path column. You’ll get a row for each version, Take the ID, filter for it in FilesetEntry column FileID, take the FilesetID to ID column from Fileset table, take Timestamp and turn it into a time, e.g. at epochconverter.com. Someday, the
Implementing the feature to restore any version of a single file will hopefully see its PR put in a release.
Display versions for a file and allow any version to be restored #4805 PR awaiting someone to commit.