Typically, Microsoft, development DBAs and production DBAs overthink the backup process.

The COPY_ONLY is a good idea for the development dba but not relevant to production. The idea of using the full recovery model, taking weekly backups then incrementing and doing hourlies defines a massively large recovery cycle that can cripple a business. So, I first define what the business needs then I define a recovery model around those needs.

Here's a simple set of criteria for deciding on a backup approach for production. I only use maintenance plans for replication. Never for backups. Use scripts.

1) Always set a simple recovery model unless the business need dictates otherwise. When setting up a new SQL Server instance, change the recovery model of the Model database to Simple.

2) If you need to backup at different times of the day, do a full backup of the simple recovery model. Do fulls at different times.

3) avoid incrementals because a rapidly changing database will create a massively large backup file on the disk. If you must do an incremental, expect to consume twice or three times as much disk space.

4) If the business defines a need for log backups the goto a full recovery model but:

a) full backup daily

b) incremental backups to the same file at critical points in the day and as the last act of the day

c) log backups of each log file. I find naming them with sequence numbers based upon the hours of the day is very simple and clear.

5) Test recovering the database in a test env. before every guaranteeing the business you can recover the database. By testing I mean restore it and the users, have a test copy of the affected apps connect to it and run through their functions.

6) for Terabyte-sized databases, switch to a file backup if there aren't too many files. If there are too many files, resort to replication or log shipping to a remote location for a recovery path. If that is impossible, you are forced to use the full, incremental and log backup method. Set the business expectation that it will take up to a week to restore the database and that you need 2 terabytes of continguous disk space for every terabyte of database.

Many will disagree but I manage 500 user databases on 100 servers with 40,000 users. I do DR on a regular basis with this method applied to time keeping and critical financial systems. So it doesn't really matter if Microsoft approves or everyone thinks this is the best way. What matters is the business. Get them up and running as fast and as successfully as you can and you will be a hero by doing your job. If you don't you will be looking for another job after failing to do this one.