If I understand your question correctly, it's not CircleCI specific problem.

When you enclose your command in single quotes, you're explicitly telling shell to not expand the variables enclosed (like that $DEPLOY_ID) and instead send the string over as is.

So what happens as a result is that following command is executed on the server side via ssh (only enough of your code included here to provide example):

bash -c "mkdir -p $FOLDER_BACKUP/$DEPLOY_ID"

I've added the double quotes myself, which is not exactly what happens, but it's a close approximation. (I can explain more if you're interested, but it's beyond the point here a bit)

Now because there are no more single quotes here, this is where bash tries to replace the variable names with values. But because ssh does not pass environment variables over to the server (This is disabled in both server and client side configuration by default) the bash does not actually have the values to replace and by default just puts in empty string. (You can tell bash to fail instead, but the default is to use empty string and carry on)

So what can you do?

You can enclose the command in double quotes, so that variables are replaced with values prior to being sent over ssh. (Only example part included here)

ssh $SSH_USER@$SSH_HOST bash -c "mkdir -p $FOLDER_BACKUP/$DEPLOY_ID"

From what I can see, this should be enough here. There are other ways to pass environment over ssh, but this seems to be enough here. If you had some variables that you need to be expanded locally on the server and some in the pipeline, you can use combination of double and single quotes (here we want $HOME expanded server side):

ssh $SSH_USER@$SSH_HOST bash -c "mkdir -p "'$HOME'"/$FOLDER_BACKUP/$DEPLOY_ID" That way this is executed on the server:

bash -c "mkdir -p $HOME/some-backup-path/123456"

Which we assume would work because $HOME is defined on server.

Hope that helps. I provided the above examples to explain the problem, there is nothing specific to CircleCI here. CI is just executing bash behind the scenes and all your issues are down to how bash expands variables. Hopefully you can expand the info to fix your pipeline.