Documentation for large-scale deployent

[jtagcat]

Multi-Backend would be nice, but that's currently out of scope. Let's assume single server, cloud or server relay.

• Currently if you backup to the same backend, you can't view others files, but you can delete other's backups. For multi-user, through a relay server (fwd all storage to cloud, but do not allow clients to delete), for enterprise, introduce a single point of failure - only admins may delete (but with power comes responsibility).
• Notifications to admin, when no backup from client x for n time.
• Faster cross-platform mass-deployment: (to be addressed in another issue, 6hrs introducing myself to Restic, need sleep)

[colans]

Currently if you backup to the same backend, you can't view others files, but you can delete other's backups.

Unless I'm missing something, that's no longer true anymore with the --append-only option, as of #784. See Append-only backups with restic and rclone for implementation details.

[jtagcat]

@colans --append-only is a client side option. Assume client no trust.
This would probably need a special back-end, what supports enforcing only appending.

[colans]

Yes, it's a client-side option, but it can be enforced by the server. Please follow the link I posted for more information.

[colans]

The first item was addressed above. For the other two:

Notifications to admin, when no backup from client x for n time.

Scheduling is outside the scope of Restic. For that, you need something like Backupninja and the Restic patch. Basically, Restic doesn't even run until you tell it to run.

Faster cross-platform mass-deployment: (to be addressed in another issue, 6hrs introducing myself to Restic, need sleep)

@jtagcat Please add a link from here to there.

I think we can close this one.

[rawtaz]

• Currently if you backup to the same backend, you can't view others files, but you can delete other's backups. For multi-user, through a relay server (fwd all storage to cloud, but do not allow clients to delete), for enterprise, introduce a single point of failure - only admins may delete (but with power comes responsibility).

I use rest-server for my clients. Each client backs up to one single server running rest-server. This means each have their own account and can only access their own repository.

• Notifications to admin, when no backup from client x for n time.

I use a simple little program/script that checks for the latest file under the snapshots/ directory in each repository in the rest-server filesystem. If you do this, you can make it alert you when one of the repositories haven't gotten a new snapshot file for repository X in N days.

• Faster cross-platform mass-deployment: (to be addressed in another issue, 6hrs introducing myself to Restic, need sleep)

Not entirely sure how you define this (each have their own use cases). Personally I use a restic script that's wrapped in a .app for my Mac clients. To deploy a new client, all I do is copy the .app bundle to the user's ~, run it to make it populate ~/.config/restic/ with some files, add the rest-server and the repository passwords to the config file, then call crontab with an argument to make it schedule the backups. Takes about 3-5 minutes per client, could probably be scripted in a more serious deployment scenario.

@jtagcat Would the above solve the things you mention? I'm curious.

If you have a more specific feature request that's suitable for this issue format, please update the original post in this issue so we can label it and treat it as such. Otherwise it's more of a discussion and we'll probably close it for maintenance reasons. Thanks!

[jtagcat]

The one rest-server per client is an idea I didn't think and works around the issue.

Now that I think of it, one more thing: clients should not be able to delete anything (for compliance and protection for more targeted malware). You could in theory do scripting on the server side to make it read-only for rest-server after a backup.

Indeed a script could be created.

These would all be workarouds, I would leave the issue open for a more integrated solution (would actually close this and create more issues, dividing this issue):

• configure restic-server:
• allow clients to only see their own backups (sso or such user authentication? (multiple devices, client can restore jtag-client2 backups from jtag-client1, but not from rawtaz-client1))
• switch to prevent client side snapshot deletion (exploit: clients could back up 100 times, overriding actual backups, depending on retention policy, one could effectively delete some or all backups)
• restic clients get a new command to get their configs (something like restic get-config <url>), after getting the config, allow to a) choose from existing configs (users) b) name the device (allow server-side configuration).
  Then the client should set up a default cron to call itself until it gets a config from the server. It would also be useful.

[rawtaz]

Honestly, I think you are a bit misinformed here.. Everything you write, except the last bullet point, is already supported. And you do not need to set up one separate rest-server per client.

The one rest-server per client is an idea I didn't think and works around the issue.

Not needed, rest-server already has support for multiple users. You set them up by adding their passwords to a .htaccess file using e.g. htpasswd. Problem solved.

Now that I think of it, one more thing: clients should not be able to delete anything (for compliance and protection for more targeted malware). You could in theory do scripting on the server side to make it read-only for rest-server after a backup.

Use the --append-only argument to rest-server. This will make your clients backing up to their repositories on the rest server only able to add backups, not delete them. Problem solved. If you want even more protection layers for this, simply snapshot the filesystem where the repositories are stored, then you can go back to that. ZFS is nice for this.

allow clients to only see their own backups (sso or such user authentication? (multiple devices, client can restore jtag-client2 backups from jtag-client1, but not from rawtaz-client1))

The rest-server already supports this, as mentioned above. Create multiple user accounts/passwords for your users, and they will be able to back up to different subfolders on that rest-server, and will only see their own repository, not others.

switch to prevent client side snapshot deletion (exploit: clients could back up 100 times, overriding actual backups, depending on retention policy, one could effectively delete some or all backups)

As mentioned above, already possible, use --append-only in rest-server.

restic clients get a new command to get their configs (something like restic get-config ), after getting the config, allow to a) choose from existing configs (users) b) name the device (allow server-side configuration).
Then the client should set up a default cron to call itself until it gets a config from the server. It would also be useful.

This one is not supported currently. Can you elaborate on what problem you are trying to solve here, and how this is supposed to work in an automated fashion (if that's your intention)?

[jtagcat]

Indeed I was. Documentation needed :)

[rawtaz]

@jtagcat I'd be happy if you could elaborate on documentation needed. I agree the current docs are in need of improvement. Can you for example suggest where in the manual we should add what? I'd be happy to write it up given some pointers. Your feedback is welcome!

[jtagcat]

A subtopic under installation or examples is probably the best place to put it.
It seems that a summarization of few of our posts will do, I'd add a link to this issue somewhere.
If you need anything else, ask me. Though I may not reply asap.

[jtagcat]

related: #2122

[jtagcat]

a fair idea for a workaround by youam on irc:

okay, so i'll create one repo per host, backup there, and copy the resulting snapshots over to a global repository with longer history
thank you all

[rawtaz]

@jtagcat How would you/youam copy snapshots from one repo to another repo currently?

[jtagcat]

@rawtaz just an idea, I'd join irc, if I were you.

[rawtaz]

@jtagcat Thanks for the suggestion, but I'm already on the IRC, just not in #restic.

Would you mind answering the question I asked? :) AFAIK there's no copy command in restic, and just copying files from one repo to another is not possible either AFAIK.

[rawtaz]

Yeah, so what you wrote earlier (the idea by @youam) is currently not doable with restic. That's why I asked how it was expected to be done, because it was written as if it was doable. Thanks for the clarification.

[jtagcat]

I will be (already did some work) putting together an interactive / argument-based installer, there's nothing unresolved here (what hasn't forked to an another issue).