I’m retrieving the backup data in runtime via the before-snapshot action so there is no backup folder in advance (it is created by that ‘before’ script). And according to the before-snapshot action naming I was expecting that the action will be triggered before anything related to the initiated snapshot but it isn’t true and first of all Kopia validates that the snapshot folder exists.
Is there a way to run the before-snapshot action really before?
You are probably doing something wrong… as I use before-snapshot action exactly in this manner and all works. I take filesystem snapshot and mount it to the new folder - which does not exist before.
Share your scripts - maybe somebody can help with it.
And have a look at examples from docs. This is what I used when creating my scripts.
I checked it one more time with:
kopia policy set /path/to/backup --before-snapshot-root-action /path/to/script.sh
kopia policy set /path/to/backup --action-command-mode=essential
kopia policy set /path/to/backup --snapshot-time="13:00"
/path/to/script.sh:
#!/bin/bash
mkdir -p /path/to/backup
This simple setup adjusts the before-action with a script that just creates the /path/to/backup folder which is backed up at 13:00 by kopia server.
Either the snapshot is run at the schedule or manually the result is the same - it fails with:
Error: unable to create local filesystem: unable to determine entry type: lstat /path/to/backup: no such file or directory.
and my before-script didn’t even run (the snapshot run log is empty). If I create the /path/to/backup the snapshot runs just fine.
I’ve already read all documentation multiple times and tried all possible variations of the setup with the same result.
I think you might be right here. This is indeed a bit weird kopia behaviour - and not clearly documented. Should be easy though to work around it by creating your ad hoc folder inside another one you backup.
Yes, this weird setup seems the only solution here.
I was playing with the Kopia last month and from one point is good software with promising features but on the other hand, it’s very buggy and unpredictable when you try to use something move advanced (policies, cli, etc.).
And the product seems abandoned on github.
Maybe not entirely abandoned yet as there is some activity. But yes it is not very lively project and forum. Unfortunately it is often the case with open source when original author does not have time etc. and there is nobody else to take it over.
Yeah, though I think another factor is that there are too many functions with too few users. Backups have a lot of possible configurations, but these configurations tend to be unrelated. Like for example, the skills on handling local backups have little overlap with the skills on handling client certificates, which also have little overlap with skills on Raspberry Pi. This results in some sort of “knowledge islands”, where one can be an expert in the setup they use, but completely clueless on another person’s setup.
With a larger userbase, there can be at least one person who have the knowledge and motivation in each of these “islands”. On the contrary, Kopia’s “islands” are mostly barren. I myself would like to help other users, but anything CLI or servers are just beyond my knowledge.
As the userbase is unlikely to increase anytime soon, perhaps there’s a need to create bridges for these “islands”, or even minimize them…