Yeah I wouldn't mind working that out too. Kinda seems like wasted effort to try and hack in support for this one hook only to change the API afterwards.
I would seriously propose writing a clear api for the database dumps since I would assume there a a lot more coming soon. If you were up for that change I would propose writing something like an…
Yeah but tbh that just feels hacky. I really dislike the use of magical names here and I think it would be much clearer if every hook just provided the name it used for the database dump directory…
Also it looks like I cannot just call the hook podman because the _databases part of the path is hardcoded in borgmatic/actions/restore.py in line 166.
@witten Any opinion on this?
Can we maybe add a function to every database hook to the name of the configured databases instead of assuming their position in the schema?
Ok we maybe need some docs saying that the hook dump and restore layout of the schema is related to the restore code. The code in actions/restore.py checks for the database name on a specified…
Fixed
Yeah other than volumes I would also like to support labels.
So as of right now I have no Idea how exactly the restore function would have to look like and I would really appreciate your input. The restore command should look like this: `borg extract…
Yeah but podman volume import is kinda odd. You import a volume and the contents get merged with the current content of the volume. So either restore deletes the podman volume, creates it again…
Yeah the plan is to store it as a tarball since we can just dump that to a named pipe and save storage that way
Basically I would like the restore command to just act exactly like podman volume export {volume_name}
Thats not what I meant. Podman volume export generates the entire volume contents as a tar archive.
@witten would you mind if the restore command would just dump the volume to stdout? Podman volumes are just normal tar archives and I think it would be very flexibe to just run `borgmatic ...