Backups are vital, but just having a backup isn't enough, what's needed is a backup strategy, which means thinking about what you are protecting against, setting up a system and testing that it actually works.
A Drupal website installation has two elements, database and code. The codebase should be running under some kind of version control which gives you great layer of protection when it's hosted in a private repository on GitHub or BitBucket. The repository contains all of the code that runs the site - and also a record of every change made to it. We use this system to push code changes made on our local development server to the staging and live versions of sites. This allows us to test thoroughly and get changes approved before going live. It also means that if you make a change to the code that doesn't function correctly, you can easily roll the site back to the previous version.
The database as a complete entity can be backed up on a schedule using the Drupal Backup and Migrate module. Backup and migrate has lots of options and flexibility, you can backup as frequently as once an hour, choose from a range of locations such as local private directory, FTP location, DropBox - and also have control over how many versions are kept and for how long.
For more fine-grained control of site content you can use Drupal's Revisioning module alongside Views Revisions and Block Revisions. Using these modules correctly gives you the same ability to travel back in time for site content and configuration - nodes, blocks and views - as storing code in a repository. This isn't suitable or necessary for all websites, it very much depends on the nature of the site and the nature of the information being recorded - please get in touch with us if you would like more information about this for your web design project.
Using all of these techniques together with a backup system like CrashPlan on your development server can give you a rock solid backup solution that can cater for any eventuality.