rest-server path set to mounted samba volume (running on a NAS)
rest-server path, IP address, port, etc. never change
restic runs from laptop, backing up to rest-server (on a different VLAN)
whilst raspberry pi stays up and running, cache appears valid. For example, the dataset is 500GB - I back up with 1GB changed, it scans that 500GB super fast (due to it recognising that it’s previously backed up that data), and then send the changed 1GB
after raspberry pi restarts, despite all paths etc being the same, it acts as if it’s an “incomplete” backup - i.e. it scans everything super slowly, does the checksumming, and then carries on (still faster than sending the data, but much slower than a regular backup)
Is there any known reasoning that’d explain this behaviour? Is it a byproduct of samba, rest-server PID, or something like that? Otherwise, let me know and I’ll see what I can do to dig into tracking this down Thanks!
I don’t have an idea what’s going on, but the explanations you mentioned are unlikely to be the cause. For example, the state of the cache has nothing to with whether or not restic decides to re-read a file that has been saved before.
As @moritzdietz suggested, having the raw output from restic for both cases (fast and slow) may be helpful.
The rest-server does not care about inodes at all, it just stores (encrypted) files restic sends to it. I don’t think this has anything to do with it.
It would be different if @stevesbrain’s backup target would be a directory mounted via samba, but that’s not the case: the mounted directory is merely the backend for the rest server.
So, next step: capture restic’s (complete) output for both cases, then we can try to dig in some more.
No worries - grabbing output now for both to compare! (was going to grab debug logs, but didn’t realise how absolutely MASSIVE they are!)
I will give this a shot after collecting the above info, even though @fd0 is confident it’s unlikely to be related; I’m still quite open to trying the abstract, weird, and unexpected
Upon follow up, I cannot replicate this a 3rd time. It must be something else tinkering that made it appear as if it was due to reboots or samba. Until I see otherwise, I don’t believe this to be a restic issue, or something @fd0 can advise me on unless I can find more info Thanks all the same!
You can have a look at what restic snapshots prints in the last column. Did maybe the path change at some point? Or did you add/remove paths? In both cases, restic will re-read all files (because it is not so intelligent to detect added/removed paths).