If an attacker has access to those files, they already have access to the files you are backing up in the first place, so it doesn’t matter much.
To prevent against an attacker, having access to the password files you mentioned, deleting the backups from the repository, use some kind of storage/backend where there’s versioning or retention of files so that you can always get your repository back if need be.
Another way is to use rest-server with the --append-only mode, which would prevent the attacker from deleting the backups in the repository. However, be sure to read Security considerations in append-only mode as well.
Understood!
I also meant that if the -files-from text file includes:
C:\Data 1
C:\Another data
and someone, whether willing or not, deletes one of the entries, the backup continues working but backing up less information and I would not receive any alert
Great info thanks.
I’m going to study about rest-server
Very kind as always, your answer helps me a lot.
This is indeed true, an attacker could effectively make the backups contain nothing. With access to the system they could also do things like disabling the backups entirely (which you could however detect when there’s no new snapshots being created). I think the only way to deal with that is to back up the data using another user or system service, but then that would have to be protected as well.
In the end it boils down to physical access to the system and other things, it’s kind of a matter of how deep you want to go. At the end of the day one has to establish what one wants to protect against.
Restic’s threat model assumes the system where restic is running to be trusted, in other words restic does not try to protect against a local system (client) compromise, that’s outside of the scope.