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 &lt;= 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).