How to avoid scripts with hardcoded password?

As mentioned in other answers your credentials will be somewhere accessible to your script.

But I would put them is separate configuration file which will be read by your script.

You will have the following advantages:

• you can use the same script for several systems (with different configuration files)
• you will be able to share the script with others (or show it to someone without compromising your credentials)

You can create public/private key pairs and encrypt the password. This should obfuscate the password from casual passers by, as they would only have the public portion of the key known to them.

You should also protect the script using directory and file permissions.

Additionally, (depending on the database) you should be able to create a user account for the database that has back-up privileges only. This would prevent someone from creating tables, dumping tables, and replacing contents. You can limit access to this user to the times you would expect the backups to run.

Update

This post on Comodo actually explains the keys a little better. Since you're worried about someone gaining access to the original password that exists in the code, the attacker would have to listen for the private key from the user triggering the script (which could happen via SSH on a cron on a separate [virtual] machine). Obviously there would be no point if you were storing both keys on the same system unless of course you were storing the private key with higher privileges than the public key.

Both keys together = password

About the permissions, if someone has access to your system and it's this much of a concern for a password to be stored on the box in a "readable format" it sounds like there are deeper issues with the configuration of permissions on the box itself. Additionally if someone can sudo and beat your own privileges (like the host that runs the box), then the key hashing is really the only option to prevent the admin user from getting into the database.

Additionally you would need to disable the root account on the database since this would allow the attacker to read the database tables anyhow.

Considering the automated nature of the script, I don't think there is a better way of storing the password besides hardcoding it.

My recommendation would be locking the script down with proper unix filesystem permissions. Making the script -rwx------ and setting the owner and group to appropriate values will go a long way towards securing the password.

Of course, have proper logging measures in place to detect if the script has been compromised. If it has, change the password on the database server immediately.