Database disaster prevention

A backup can't prevent corruption. Nothing can absolutely prevent corruption.

What a backup does is to enable you to recover data to an earlier point in time in the event of corruption or other disaster.

Whether your backup schedule protects you adequately is not something a community of peers can answer - your business requirements will dictate that. You need to consider your recovery point objective (RPO) - how much data can you afford to lose? If you cap at 5 minutes and you take a full backup once a day and log backups every hour, you're not covered. To truly protect yourself you should be in full recovery mode and your log backups should occur every <= n minutes, where n is the maximum amount of data loss you can sustain.

There are other considerations as well, such as recovery time objective (RTO) - in the event of a disaster, how long can you afford to spend getting back online? This will determine whether you just keep your backups on a drive ready for access, or actively keep a warm standby using log shipping, or higher "cost" DR techniques such as mirroring, FCIs, and Availability Groups. Note that some of these technologies can help save you from data corruption but other types of failures aren't covered (e.g. an accidental delete without a where clause will happily run on both the primary and any secondaries).

In my experience, the best way to protect my database are scheduled backups. As Aaron said, it is very important to answer this two question:

How much data can you afford to lose?
In the event of a disaster, how long can you afford to spend getting back online?

Of course, my database is smaller than 250GB and I prefer a maniacal backup plan, it is a Full database backup every 24 hours, a Differential backup every three hours and make transaction log backups every 15 minutes. Yes, perhaps it will take more time to restore my database if the failure occurs, but my data lost will be minimal.