You need to consider the best practices for performing SharePoint backups. You can start from here
Its recommended to use powershell for all your backup purposes. Since you explicitly mentioned databases , you can do it through either of the two ways :-
SSMS SQL Jobs - Create maintenance plans and define whether you want full , differential or transactional level recovery for the SharePoint databases. Its always recommended to have full recovery model for content databases and configuration databases. For service application databases depending on the frequency of use , you choose between full or differential.
Powershell - Powershell is the recommended way of taking granular backups like site collections , subsites and lists. For web applications , a full recovery level backup of the content databases will easily save the day during a crisis.
Plan, Plan and plan more can be the best recommendation you can have for SharePoint backups. Come up with a complete solution strategy and understand Disaster Recovery at a process level. A few quick points should help you kick start on this :-
a. Never take manual backups. Automate them through task scheduler for powershell based backups and Schedule SQL Jobs for Content and Configuration Databases.
b. Categorize items for backups. Not all items in the farm deserves the same importance and your recovery strategy should revolve around this. A state service application database cannot be more important than your primary portal's content database. Similarily farm solutions deployed are more important than their corresponding web config entries in the IIS.
c. Schedule backup jobs during non-peak hours
d. Formalize a plan for availability - like going for SQL Cluster or Disaster Recovery + Cluster
f. Always test backups on a test farm periodically to check the backup integrity.
g. When all else fails , try the good old stsadm.