Backup strategy (2): pull/remote/add-only

[ar-jan]

After reading #934 and #784 I've come up with an alternative pull-like mode that works for me for the time being. I'd like to ask if you see any problems with it (or easier alternatives).

Use case:

• Server A has data in multiple directories that should be backed up, and little local disk space.
• Server B is a backup server with plenty of disk space.
• I want to give as little access between the systems as possible.

The data to be backed up from Server A are in different directories. Backing up those folders separately from Server B would be cumbersome, and I don't want to expose the entire file system (even as read-only).

I could run the restic backup from Server A and push to sftp, then chown the backed-up files to prevent tampering/deleting as mentioned in #934, but I'd still have to lock down the backup-user account on server B.

I'm now running the restic backup locally on Server A, and pulling in the repository with rsync from Server B. I've locked down access to server A by using rrsync, so the only allowed access is the rsync command, in read-only mode, and only the location of the restic repository is exposed.
The rsync command from Server B uses --ignore-existing, so if a snapshot on Server A were tampered with it would not propagate to Server B.

Since I have limited disk space on Server A, I've tried to just use different forget/keep policies on the repository versions, and this seems to work fine, since new snapsnots and indexes are always contained in new files. So on Server A I use e.g. --keep-last 7, and on Server B I could keep everything, or set up a more elaborate policy. So my main question is if this will indeed keep working long-term.

P.S. This may look complicated but I like it. The main advantage is that the locking-down is easy to manage: there's just read-only access to only one directory on Server A via rrsync. A draw-back is that to use a remove policy on the Server B repository via cron, I'd need to store the repo password there too.

Details for the rrsync setup:

// On Server A:
gunzip < /usr/share/doc/rsync/scripts/rrsync.gz > /usr/local/bin/rrsync
chmod +x /usr/local/bin/rrsync
// Read-only access, only to /backup/, for the remote backup server:
echo 'command="/usr/local/bin/rrsync -ro /backup/",no-agent-forwarding,no-port-forwarding,no-pty,no-user-rc,no-X11-forwarding ssh-rsa AAAAB3N...' >> ~/.ssh/authorized_keys

[middelink]

How about starting a restic-server on Server B and using that as the repo endpoint for Server A? (and Server B itself is you so care). Aside from the in progress pack files you don't any repo storage on A, while still reaping the benefits from deduping files between A and B. Also the restic password cannot be used for any other system level authentication.

[ar-jan]

I've looked at restic-server and it looks great (I read it should also be faster than sftp?), but I'm lazy and for now I didn't want to look into the proper way of configuring it as a service, and setting up a webserver with Let's Encrypt - my backup server basically has only SSH currently. But yeah, combined with regularly chowning the snapshots so they can't be deleted by Server A this would be a good fit.

[fd0]

That's an interesting scenario. In terms of long-term issues that may arise I can think of several:

• When no changes ever are propagated back from server B to server A, the latter will not be informed about removed content, so it will think that all blobs it ever wrote to the repo are still available
• Server A will add index files, and a restic process on server B will need to merge them with the rest of the repo's index files when prune is run. I'm not sure if that may be an issue in the future.

If I were to build this, I'd first look at syncing the files from sever A to server B and then run the backup there...

Can we close this issue? Did you receive enough feedback? We can still add comments (and the issue will turn up in the search results)...

Please report back ;)

[ar-jan]

Thanks; I'll post here if I find any issues with it, or if I decide on another strategy.