You can also use this with AGs. Create the db, do a nul backup, start direct seeding.
It is useful to eliminate disk/network as a backup bottleneck if you need to test a system as well. If this is a production dB, then you do want copy_only if you need an intact chain.
With all due respect, this QoD is a bad choice and I wouldn't have chosen it. IMHO, QoD should introduce interesting and challenging topics, not something about picking the right syntax.
The title 'Extremely Quick Backups' is misleading since it clear to us now that it does not backup anything. And I also disagree with your statement 'It is useful to eliminate disk/network as a backup bottleneck if you need to test a system...' What purpose does this command fulfil on a test system. Without actually writing to a file system how reliable and useful is the result of such a test?
No offence, just a Friday nit-picking rant. Have a great weekend.
Sorry to butt in, in the backup process there are 3 steps if you want, read, process and write. Usually you don't read and write to the same device, or at least you shouldn't.
Eliminating the write part you can test how fast you do the read and process parts, if you see that your read speed if good but you backup performance isn't, the problem must be elsewhere.
True that it doesn't give you a complete picture, but I wouldn't say it's totally useless.
Cheers