It varies from databse to database. There are in-house databases and databases at the customer sites, databases that change rapidly and databases that change rarely and databases that are read only, databases for OLTP and databases for MIS, large databases, small databases, and very small databases. I suspect I'm a good deal more cautious (or maybe just more paranoid) than Steve. These are the databases we had and what we did about backup and recovery; I believe the company is still doing the same.
1) At each customer site: rapidly changing database with current and recent information only, where recovery to point in time is essential. These had (a) transactional replication to another server which could take over in an emergency (MS agreed that this server needed no Sql licences, since from the SQL point of view it was pure standby) and (b) full recovery model with full backup daily and backup log every 15 minutes, full backups (held on yet another server) retained for 4 weeks and log backups while the full backup they were based on was retained.
2) At each customer site: archive database containing history of activity in the above database, used to produce management information. (a) transactional replication as above, plus (b) simple recovery model with full backup twice per month, each backup overwrites the last but 4, held on same server as backups from (1) above. (This is expensive on space, but safe)
3) At each customer site: small database (describing the customisation of our product for the particular customer) that is updatd very rarely by customer or by our customer support team, and rather more often by our release and implementation people (hope that update by the customer becomes in time the most frequent update). Full recovery model, daily full backup, twice daily log backup, backups kept for 4 weeks - this may seem OTT, but the normal restore case for this is that the customer changed his mind about some changes he made AFTER telling the test and "commit" system that the changes are all OK, and that happens any time from a few hours to a couple of weeks after the change was committed.
4) At each customer site: small databases that are read only at customer site except when replaced completely by us: a copy is placed on the replication target server when ever one of these databases is replaced, and a full backup (to the server handling backup filestore) is done at the same time and kept until next time the db is replaced.
5) In-house databases corresponding to 4 above: simple recovery model, daily full backup, backups kept for 3 months. (This is not expensive on space because these databases are very small.)
6) In-House: Prototype databses corresponding to (1) and (2) above (we trasfer these "empty" databases to new customers as part of the installation process. Full or simple recovery model (depending on whether it's from (1) or from (2) above) with same backup regime as at (1) or (2) but no replication. The backup media for these (and for 5 above and 7 and 8 below) is backed up daily as part of a large filestore backup, and these filestore backups are kept for a couple of weeks off-site.
7) In-house: databases like that at (3) for new customers (system as yet uninstalled, or installed but not yet accepted) in which the creative team is doing the customisation required for the particular customer: full recovery model, daily full backups, twice daily log backups, kept for 4 weeks.
8) Copies from customer sites of databases described at (3) to be used in testing/validation/QA. Simple recovery model, backed up once a week, kept for 3 weeks.
I made sure to do at least one recovery from backup per year into dummy databases at each customer site, and recover all in-house databases (to dummy) from backup at least three times per year. The backups might well be useless if recovery wasn't checked regularly.