If you use the SIMPLE recovery model in SQL Server you just have the backups. If you lose your system the most recent restore point is your last backup. In many cases that is good enough, but it depends how frequently your content is changing and the cost if changes since the last backup were lost.
If you use the FULL recovery model you can restore to your last backup, then restore your transaction log backups (if any), and then restore the "tail of the log" potentially right up to the time of the failure. That comes at a price - the transaction logs have to be retained, and if you don't back them up they just grow and grow.
So you need to have a SQL Server backup schedule if you are going to use FULL recovery. If the log files are huge, once you have done the first backup you will need to shrink the database the one time to get it to a manageable size.
The config db is particularly prone to this problem because there are a lot of transactions even though this database is usually quite small, so the log file gets very big if you leave it on FULL recovery (the default) and don't back it up.
A SharePoint farm backup gets most things (assuming the backup works), but you should have a copy of your SharePoint root directory (14 hive) and the web root directory, to capture things like web.config modifications and artefacts that weren't deployed through WSPs.