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.
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.