As far as I know, restic uses the full path internally always, so that behaviour is expected.
The data chunks will still deduplicate, but the first backup of the “real” system will be slower as restic will need to scan everything to make sure it has all the data already stored. Subsequent backups of the real system will be significantly faster, because the full scan won’t be necessary.
I’m sorry, I don’t really understand what you mean by this? When you perform a restore, the contents of the snapshot (or the parts of the snapshot you specify) will be restored. So if you restored /srv/rsnapshot/daily.0/foo.example.com/home/andy/.bash_profile from a snapshot, that file and path would be restored inside the target directory you specified. The contents/metadata of the restored file would be as they were when the snapshot was created.
I think a chroot would work to get you the path structure you want? But it would involve some setup. There’s a bit of discussion about it in Backfilling snapshots from non-restic archives - #2 by cdhowie , and some reports of using proot to accomplish the same in Backup option to remove a leading path prefix · Issue #2092 · restic/restic · GitHub , and some other solutions too that sound promising.