Pbm status needs network access to backup storage account

I had the incorrect assumption that the pbm cli only needed access to mongo and not additionally the backup storage itself when running pbm status. It was only after a very long timeout that I ever got a network error.

pbm status --mongodb-uri=mongodb://xxx:yyy@zzz/
Error: get status of backups: get storage: init container: unknown error ensuring container https://xxx.blob.core.windows.net/yyy: -> github.com/Azure/azure-pipeline-go/pipeline.NewError, /mnt/jenkins/workspace/pbm-autobuild-RELEASE/test/percona-backup-mongodb-1.6.1/build/src/github.com/percona/percona-backup-mongodb/vendor/github.com/Azure/azure-pipeline-go/pipeline/error.go:157
HTTP request failed

Put "https://xxx.blob.core.windows.net/yyy?restype=container&timeout=1201": dial tcp n.n.n.n:443: i/o timeout

Now that I know this, I’ll apply the network policy that allows this traffic to the pod running my backup check script. The docs say that the pbm cli uses the control collections to get the agent to take actions. If checking the status really does need to talk to the backup storage account, I think the documentation should note that. Though I suppose that is implied here.

1 Like

Hello, indeed the host running the cli requires access to the storage. Feel free to submit a contribution using the “Edit this page” button on the top right side of the page if you feel the doc is not clear on this.

1 Like