Oh? That is very unusual, I’ll try to reproduce it. The questions that popped up in my mind are: Why would restic read that file during backup? What did you do exactly, where is the repo saved, how did you start restic?
Just to clarify: You observed the stack trace and then the empty file was there? Or was it the other way around? When you restart the backup, will it abort again with the same file?
There is a similar concept in restic, but I need to explain a bit of background first. When restic backup starts it reads two things from the repo: The index files (telling it which blobs of data are stored within the files in the data/ directory) and the list of snapshots. With the latter it tries to detect if the same set of files/dirs have already been saved before. If that’s the case, then it downloads the metadata to avoid reading unchanged files again. Blobs can either be parts of files or directory metadata information (as a JSON document). For details please see the design document.
In this case, there was no complete backup before, so the snapshots part is not relevant. But restic also downloads the index files, and will then start reading the files/dirs to save. If it encounters a blob that is already saved (remember, that information is contained in the index file) it won’t save this particular blob again.
So in order to resume interrupted backups, restic regularly writes intermediate index files that contains listings of all data files that have successfully been uploaded since the last index file was written. At least every five minutes such an intermediate index is saved in the repo. That’s a (very basic) checkpoint concept.
I hope my text is understandable, feel free to add further questions 