Glad you like the article.
Backup strategy is dictated by what restores you want to be able to do, what the data volume is, what storage space you have, and so on. If you have an RTO of 8 hours with a zer data-loss RPO, you need to be able to restore from your most recent full backup and all the way up to the most recent log backup in 8 hours. Depending on the amount of change in the database, you're likely going to be using differential backups as well. Answering this question is an entire series of articles in itself.
As far as consistency checks are concerned, if you're able to, run them on the production system as often as you can. The quicker you can find that you have corruption, the more likely you'll be able to recover with the minimum downtime and data loss. If you can't run them in production, take your full backup, restore it somewhere, and run consistency checks on it. If its clean, you know the production database was clean at the time the backup was taken. This is another article-sized answer, but I hope that helps.
: Check out SQLskills online training!
SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005