I plan to run a rest-server with 500 TB for some 100 clients. I do not have access to these clients and do not know their restic passwords. Is it true that only the clients can run restic forget to delete old backups?
Only a party that has the password for a repository can access that repository, yes.
However, there are two options to be aware of:
- One can add multiple passwords/keys to a repository using
restic key add(seerestic help key). Whether that is useful to you or not depends on your needs and requirements. - There is the highly not recommended option
--insecure-no-passwordtorestic initwhich technically (just to answer your question) means that another party than the one knowing a password can delete backups in a restic repository. This is highly not recommended as it will leave the repository completely exposed to access without a password.
Generally speaking, it ought to be the client that does maintenance such as using forget to delete old backups (snapshots) and prune to the repository to get rid of unused data. But you can set things up so that other systems can prune, but they do need access to the repository (preferably so with their own key that you can then also replace and rotate on a regular basis in an automated fashion).
Adding a second password-key to the repository and giving it to the rest-server admin means, that he also can read the content of the backuped files? This is a no-go in my environment.
Just knowing the name of the files is bad enough :-}
Yes, of course. So you might want to simply make the clients do their own pruning. That’s what pretty much everyone does. It shouldn’t be a big deal, just have them do it as part of their regular routines.
@Framsfex if you are affraid to limitless fill up disk space, you can set up a separate partition or disk quota for each client to present a hard stop.
I have at least 50 users, maybe more in the future, adding file system quota for each is extensive.
Some of them will not delete old backups, because they think it is a server task.
@Framsfex Frankly, your initial task isn’t entirely clear. That is, did I understand the context correctly? “Clients can create backups, but they aren’t required to delete them”? I find this a somewhat odd use case. Restic is primarily a tool, nothing more. You can automate quota creation, key distribution, and generally anything else by connecting Restic itself to this task, but this doesn’t fundamentally solve your case. If a client hits their quota, their new backup won’t be saved, and therefore, as the client who initiated the backup, they must resolve their own storage quota limit issue. It’s extremely strange that you want to take responsibility for them by cleaning up their archived data, which, incidentally, they themselves are saving.
Clients can create backups and they should delete old ones. But I (as the rest-server admin) cannot watch them, because I do not have the repository password.
The rest-server can set a quota but it is the same for each user. Different quotas are not possible.
I can set filesystem quotas with ZFS but then I have to create for every user an own dataset.
Currently we are using IBM Storage Protect, a backup system where the backup server deletes old backups.
The backup server admin sets the rules. The clients must not delete old backups. This is what our users expects.
There are simply different designs in play here. Each of these products has their pros and cons. Maybe look at how CERN uses restic for thousands of clients, i.e. how they deal with this type of thing.
They’re running on tax money. They’re probably not even aware of the fact that data can be deleted 
@Framsfex I don’t know how the IBM solution would manage separating those files without access to them. The only way I can imagine would be having discrete backups that can be deleted as a whole but then you don’t have differential data or deduplication. Or they have some magic trick? Can you find out and tell us?
Otherwise you could just have restic create a new repo on every backup run and then delete old repos on the server. No insights needed there. Depending on the features of your storage solution, you might even get deduplication via the file system? But it ain’t pretty, of course.
I mean there is a fundamental design difference there - there is no “backup server” with the restic model, all of the “intelligence” is in the client. If you’re going to switch over to restic, there will have to be some changes, and although you can hide some of that from the end user, some of it will always be visible.
Honestly, that’s no bad thing, better to accept restic as it is than try and smush it to try make it fit badly into an IBM Storage Protect sized hole. IMO anyway.
The problem is that we (computing center) run the server with the restic repositories and we have to ensure that the clients will clean up their old backups, because we cannot do this for them.
IBM SP has a database and knows every file which has been stored (even the encrypted ones) and can delete them after a given time.
Yes, this is some of the design differences that have been alluded to.
Restic is designed in such a way that it completely does not trust the repository storage. There are several reasons for that, of which some you can read in the design documents and the threat model.
IBM Storage Protect presumably does not at all work in this way, and this enables it to act on the clients’ backups on the server side in completely different ways than restic possibly can.
You simply cannot fully manage clients’ backups on the server side without knowing one of the keys to the repository, since restic is designed around different assumptions, a different threat model and different features than your current backup solution.
You will have to make the clients manage their backups, and when doing so you can still keep an eye on each individual clients’ backups to some extent such as detecting if some of them grow unreasonably large, or determine when the last snapshot was made. You can of course also create or use existing wrappers or other types of software and processes that automate the clients’ processes in ways that give you more or less what you are looking for.
But yes, there are limitations to what you can do here. And that is due to different designs in these two products, which both has their pros and cons due to these designs.
Are there any outstanding questions or has the topic been answered?
I want to humbly disagree here and state that it is indeed possible if you allow it by either sharing the repo password with the server or assigning it its own password. Yet that is not the primary design intention, of course.
Yes, you are 100% correct! I was talking about OP’s specific request.
If the server or something running on the server has a key that is applicable for a given restic repository, that server can indeed manage the backups in that repository. Thanks for clarifying!
I edited my previous reply.