I am trying to find the best solution to detect that the repository is not initialized on a ‘rest-server’ (I have to make the difference with a password error) in a script sh.
A lot of script (especially in docker) tries to read the file ‘$ RESTIC_REPOSITORY/config’ but on a ‘rest-server’ it does not work, or I do not know how to make it work.
Someone would have a suggestion
Well, if as per your original question you want to determine if the repository is on a REST service, then simply look at the URL. If it begins with “rest:” it’s targeting a REST server.
You did say you wanted to know whether the repository was initialized on a REST server. The above won’t tell you that, because the repository could have been initialized on something else and then moved to the REST server. But that’s a different story, and I guess it’s not what you really need to know.
Ok to clear up by question. I have a script that makes my backup, in this script I want to test if the repository is initialized or not. if it is not initialized I initialize it, and I do my backup otherwise I do my backup. If my repo was local I would try to read the file ‘config’ and the question would be settled, but in my case it is a repo ‘rest-server’
The simple detection of an error is not enough because it must take into account other errors, password, etc.
What you could do is run restic snapshots and check if it returns an error code. If the repo is not initialized, it will return a non-zero exit code. Otherwise it’ll load the list of snapshots, which also ensures that the given password is correct.
I don’t think so, but I would need to check the code.
You could also issue a HEAD request for the config file, like curl -I http://rest-server:port/path/to/repo/config and check the response. If it’s there and has a non-zero size, then the repo is likely already initialized.
What are you trying to achieve, what’s your use case?
It sounds like your goal is to have clients auto-initialize a repository. I’d be very careful taking this approach as it can mask errors. For example, you expected a client to backup to a specific repository but it hasn’t been. You look around and find out that it’s been backing up to a different repository, which it automatically created. The client auto-initializing the repository masked the error of pointing it at the wrong repository URL.
I’m trying to put a docker container into service to perform the backup, and in case of the repo isn’t initialized, doing it.
But I do not want to hide another error (password, non-exiting repo, permissions, etc.)
In a way, yes, because if the script doesn’t automatically initialize a repo itself, it won’t back up to the wrong one by itself.
On my backup server I have a script that checks repositories for the last snapshot and reports when they were created. I run this every now and then to see that the client (or whatever else has the key to that repo) backs up as it should. If some client doesn’t have a snapshot created in the last week or so, I investigate.