Strange rest-server cache behaviour?

Hey all, my backup scenario is this:

  • rest-server runs on a raspberry pi
  • 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 :slight_smile: Thanks!

Hey :slight_smile: I think it would be helpful to see some restic output that shows the problem you are having. Would you mind sharing it here?

1 Like

Could be due to inode changes. Try mounting your samba volume with unix extensions and serverino enabled.

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.

1 Like

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 :smiley:

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 :slight_smile: Thanks all the same!

1 Like

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).

Thanks for the suggestion - but no, same script with same paths each time :slight_smile: