If you have read through this section, you know that page corruption happens in most cases because of hardware failures, or filter driver misbeheaviour. SQL Server asks for a page at a particular offset of the file, and then many issues can happen. The operating system may not be able to read the data, or the page returned does not contain the data that was requested, or its header is unreadable, or its contents have been modified...
Your best friend will always be a reliable backup strategy. Be sure you know how to restore or to failover quickly, but most of all keep in mind that you'll always need to do root cause analysis on your damaged system. If you don't, nothing prevents this from happening again.
You can't avoid hardware failures, because they are mostly unpredictable. Just be sure you have rock-solid backup strategy and a failover system (I mean both of them), backup your databases with checksums enabled and verify the checksums, eventually restore your backup on a day-1 database, enable page checksums at the database level, don't put your transaction log, your data files and your backups at the same place, run dbcc checkdb at regular intervals and monitor the errors. A lot of people in this section are hit by corruption, and because they never run checkdb or never monitor the results, they realize they don't know when their last known good backup was, and they end up with repair_allow_data_loss.
If you are running Enterprise edition, you can count on very cool features, like page restore or mirrored backups.
The error you mention is not exactly a corruption, and can be fixed by running DBCC UPDATEUSAGE. I know they can happen after an upgrade from SQL Server 2000. You should always run DBCC UPDATEUSAGE after an upgrade.
Hope this helps,