1) Depends on your downtime and data loss allowance (RTO and RPO SLAs). In short, you need a backup strategy that will allow you to meet them. Find out what they are, then start designing.
Backup the system databases. There's all sorts of things in the system DBs that you don't want to be losing (logins, linked servers, jobs, job history, etc)
Run consistency checks often. When the DB is corrupt is too late. You need to know if you're backing up corrupt databases.
Test your backups. Restoring a backup is the only way to be 100% sure it will restore
Save the backups somewhere else. A backup stored on the same drive as the data file is a waste of space.
Test your recovery strategy.
2) Could have been anything in the IO stack. Buggy IO drivers, misbehaving filter driver, faulty hardware.
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)SQL In The Wild
: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter
We stand on the bridge and no one may pass