|Do you know where your variables are?|
Just a couple things not mentioned yet by others:
The string "/home/dieter/dumps" appears at four different places in the script, making the code rather non-portable and a bit harder to maintain. The string should be defined once as a variable, and should probably be among the values that can be manipulated by a command line option. (And this would also entail taking steps to create the "mysql" or "postgres" subdirectories if necessary, reporting suitable error messages when that fails, etc.)
Since this appears to be intended for a unix/linux system, it might raise concerns about protecting database security. When you run the script, and include the "host", "user" and "password" options on the command line, the values of those options become accessible to anyone else logged in on the same machine where your shell is running. All they have to do is use "ps" or "top" with appropriate options while your script is running, and they'll see the credentials you're using to connect to your database.
(Those values will also be preserved in the command history file for whatever shell you're using; the history file is typically readable only by the owner, but if your login is compromised, whoever can pretend to be you will also find the database credentials in your command history.)
Typical ways of avoiding exposure of credentials is to use a config file in the user's home directory (though this might still pose a risk if your login account gets compromised), and/or to use a module like Term::ReadPassword to prompt for the password after the script has started (without echoing user input to the terminal).
UPDATE: One other thing: Every time you do this:
you are leaving yourself wide open to unlimited grief, because you are not making any effort to protect the values in @args from being misinterpreted when that backtick command line runs. Imagine what sort of mayhem you'd get if the password string for the database connection included an ampersand or any kind of bracket character...