Hello I use restic 0.18.0 with an rclone backend.
The command for the rclone backend is in a forced SSH command like this:
restrict,command="rclone serve restic --stdio --append-only ./data" REST_OF_THE_SSH_KEY_HERE
And I do the backup using this command with restic:
restic -o rclone.program='ssh backup-test@HOSTNAME' -r rclone: backup directory-to-backup/
It works great! However I would like a some friend’s server to be my backup server this way (to make sure that if I get hacked, he doesn’t get hacked and vice-versa).
The problem is that since I can’t remove the backups, they risk on taking a LOT of space on his server. Is it possible to:
- Either configure it to automatically clean old backups
- Or let the person manage the backup server clean backups themselves without needing the Restic password
If anybody has an idea about this, I would really appreciate it. Because the only two solutions I see so far are:
- Doing the operation myself, either by getting SSH access to their server, or by them changing the configuration to disable temporarily the “append-only” mode → that’s quite annoying and troublesome to do
- Them removing the repository all together, and my backup script is setup to automatically re-init the repo if that’s the case → big security risk in case the hack or problem happens when the backups are deleted
Thanks in advance to anybody who would have a clue on this!
I’m not sure any of these are really where you want to be. Remember that you’re doing all this not for the backup but for being able to restore. That means you need to make sure the backup works, e.g. by regular checks and notifications if something seems wrong. For that the machine needs the key to the repo.
Why don’t you get something like a raspberry pi with and external hdd and place that at your friend’s house? That way you could leave you repo key on it and have it do regular forgets, prunes and checks via crontab. And if you need to restore, you can physically move the backup drive to your location making the restore way faster.
Well, I do have the key to the repo, since I need it to backup in the first place. Since it’s append only, there’s no problem in restoring and checking it that way.
The problem is that I don’t want to have the responsibility of having a direct access to that backup server, but I don’t want the backup server to have the responsibility of my data (to me having a backup server that knows the decryption key kinds of defeats the point of encryption since if the backup server is hacked, all the data can be decrypted)
Now I thought about it and I’m thinking that if I have multiple backup servers, I could define a crontab on each of them to delete all the backups at regular intervals but completely different times (to make sure there is never a moment where no backup is available). Then in my backup task I could just define that it tries to init the repo before backing it up.
That way there would always be at least one backup functional, and the space wouldn’t be an issue anymore.
A possible solution here, as usual, depends on the budget you have and the threats you try to protect against. For home use, I would add that it should be simple enough so you don’t get into trouble without noticing.
What I personally do is this: I backup (via rest-server but it also works with ssh) to a local Linux machine. Every night, I rsync the whole repo to a raspi in my brother’s basement. This machine doesn’t have much else to do so it reads chunks of the repo during the day checking for errors, cries foul if it finds any and sends a canary message if it doesn’t so I know it still works. Additionally, every now and then I connect a USB drive to my desktop machine and rsync the repo to that to have protection from malware and 3v1l h4x0rz.
It’s a cheap system, it’s easy to understand and maintain and so far it has been working great for several years. And by working I mean the backing up works. Except for occasional tests, I only ever restore from the main backup.
Both variants inherently conflict with the idea behind append-only. There has been some discussion regarding object locks on S3, which could allow deleting old backups while retaining most of the benefits of append-only backups. But that’s still at a point where not even a concept is properly discussed.
What you could do is setup two different ssh-keys. One that’s used for regular append-only backups and a second one that is maybe tied to some security key that is also allowed to delete data. That second key could then be used to prune the repository from time to time.
1 Like