everlast,
I think you are going down the right path. It all comes down to how much data you can afford to lose. It looks like you will not lose any data in your backup scheme. By the way don't forget to test for a catastrophic failure. I've been at companies in the past where everything looked good, but when the server went down, the backups didn't work.

When it comes to dev/qa/test backup strategies. The way I set this up in the past is using 3 environments.

1. Production
   This is normal production data backed up to your preference.
2. Development
   This is an older snapshot of production data. This ranges from 2-8 months old. This data is refreshed when everyone (developers) agrees to. The reason for the lag is this is where all stored procedures are tested, and new tables or new columns are tested. Make sure you backup this database before you restore it from production data. There always seems to be one stored procedure you forgot to backup. 
3. Testing
   This data is restored every day with production data. From here you can test code you are about to release into production with fresh data. This is where QA does most of their testing.

I hope this helps.

 - Dave B