To my knowledge, inode number is not used to locate files in the repository. Consider that multiple filesystems from the same host might be backed up. In fact, multiple hosts might back up to the same repository. Maintaining an index of inode numbers of all files across all snapshots (accounting for collisions where two hosts/filesystems share inode numbers for different files) would be a large amount of new code added to restic to optimize for what is quite honestly an edge case.
No data is actually sent “up to the repo.”
Restic splits each file into chunks and hashes each chunk. These chunks are stored separately in the repository as “blobs,” using the hash of the blob contents as its ID. This way, when a file is unchanged, the restic client can simply look in the repository to see if there is a blob with the same ID. If there is, the blob is not re-uploaded and is effectively deduplicated.
What you perceive as data being sent is probably just the hashing activity on the client, which does take some time. If you measure CPU usage against network usage, you should see that the network usage is nearly nothing, which the CPU is working hard to hash all of the files.
The “parent snapshot” concept simply allows restic to skip the hashing step if the metadata of the file hasn’t changed. Without a file in a previous snapshot to compare metadata against, restic has to process all of the file’s data, but that doesn’t mean the data actually gets sent to the server unless the data doesn’t exist in the repository yet due to an earlier snapshot.
As @764287 pointed out, it would be much better to simply back up against the original files. The paths will be consistent between snapshots, which will allow restic to properly locate a parent snapshot. You should then see a dramatic reduction in the amount of time it takes to create a snapshot – if little data has been changed, this is not much more time than it would take to crawl the backed-up paths using
find or a similar tool.