message: Failed to create pre-backup Kanister phase - cause: cause: message: "Failed to exec command in pod: container postgres-postgresql is not valid for pod postgres-postgresql-0"
but the container deployed by that chart is in fact named postgresql
container name
I have not done a lot with Blueprints yet so will want to dig deeper but I assume my next step is to change this part of the blueprint to represent the right container name?
I have also attached the logs.
Page 1 / 1
@jaiganeshjk Please disregard this post now.
Hello @Geoff Burke,
Could you please try this Logical PostgreSQL backup:
I have tested the link you are using, and indeed the blueprint is not working, the container parameter can even be removed, but the problem is that the functions used in the psql commands in that blueprint probably were deprecated.
We will have to update the blueprint to fix the issues, and also to work with latest versions of PostgreSQL (15), I will raise this internally to get this updated.
Hi @FRubens
Thanks in fact I changed the name and it did not solve the problem. I exec into the container and was having issues with the commands themselves so guessed something might have changed but not being a postgres expert was not sure that I was correct.
cheers
Hi the Mongodb app aware example has issues as well as that version number 9.0.0 is no longer available
I am not trying to be picky but I sometimes tell potential customers to go and try it themselves as there are easy examples on the Kasten-io Documentation site so as you can imagine they come back to me thinking they did something wrong.
I tried without setting a version just for fun but most likely stuff has changed and been deprecated here as well
"Failed to exec command in pod: command terminated with exit code 2"
cheers
Hello @Geoff Burke,
Thank you for pointing out, I have tested and indeed the mongo command was deprecated, it must be replaced with mongosh inside the blueprint to work.
We are working to update the application consistent blueprints templates to support latest versions.
Regards
FRubens
Hello @Geoff Burke,
Thank you for pointing out, I have tested and indeed the mongo command was deprecated, it must be replaced with mongosh inside the blueprint to work.
We are working to update the application consistent blueprints templates to support latest versions.
Regards
FRubens
ok thank you very much for this. I have a demo coming up soon and really wanted to show this. I do underline that application owners are the ones who have to create these and keep them up to date since we can’t be experts in everything. Although this one you found pretty fast . I will give it a spin.
Thank you
ok trying this again. Blueprint errors out with exit code 2 which I believe means command not performed correctly somehow in the script. To be fair all I did was change the mongo to mongosh. However I can exec into the pod and exec successfully:
I think that I have to stop being lazy and go back and review Kanister outside of Kasten then comeback
Maybe you can even add -f at the end of the command and monitor it while running the backup, it is not easy to read, but you can see the commands being executed.
I have tested replacing mongo with mongosh and the policy completed with success, you can also provide the kanister log here so we can check.
FRubens
Thanks @FRubens will do!
Well in the end there was no need. I was pretty sick yesterday so I have no clue what I did. Today I deleted what I did yesterday and took the blueprint from the docs, changed the mongo command to mongosh again and … voila
I did not trust myself, maybe I put the blueprint in the default namespace in haste or something so I checked.. all good snapshot and the hooks blueprint is there that performs the db lock. Thanks again @FRubens for answering this on a weekend. I realize this is free support so I really appreciate it when people answer from your team.
. I will give it a spin. 
