Why was the design decision made to hash filenames with sha1? I don't see a security flaw in this specific use-case, but why dance with the devil? If it's about shorter hashes, it's safer to truncate a sha2.
Since it uses a public key to encrypt to, can a malicious server overwrite your data with encrypted but fake data or is the data also signed using a private or symmetric key on the client side? It might seem like an unusual use case, but why trust the server if we don't have to, and for servers the attacker might know what software it runs and therefore what the file structure is. If you can make someone restore software with modifications of your choosing, that would be rather powerful even if admittedly difficult to pull off.
How does that local sqlite database grow, e.g. for a regular amount of files for a 1TB drive, do you get a bunch of gigabytes of state like Duplicity? (I gave up on duplicity because it ate too large a chunk of my ssd while restic didn't need local state at all.) What if the local file is gone, can it (albeit slower I guess) still run normally or do you now need to do a full back-up?
Edit: Found one of the answers: it signs the data with hmac "using a combination of the RSA Public key and the passphrase used to protect the RSA Private key" as key. Erm, what? The private key is contained on the client? What's the point of public key encryption if not to not be able to decrypt the data unless you have access to the private key? If the client has the public and the private key, it might as well use symmetric encryption. But what's weirder: the passphrase that protects the private key is used for signing?! Why not use the private key to sign the hash if you have access to it?! And mixing in the public key does nothing, as this is known information to an attacker. Might as well store the plain hash if it weren't for the private key's passphrase.