Does it make sense to use full recovery if the data and log files are on the same HD? We have a database that was set up to use full recovery and my guess is that the reasoning was only to prevent data loss if a failure happened between full backups.

We make daily full backups of the database and we have no need to recover to any point in time previous to our last full backup. 

Our data files and log files are in the same hard drive. From my experience (as programmer, I'm not a DBA), most database failures I've seen were related to disk failures and so I wonder if this setup makes any sense. I imagine that if the hard drive fails, we wouldn't be able to recover using the transaction logs.

So my question is twofold:


Is the most likely cause of a database failure, a hard drive failure, or are there other common reasons that would justify this setup ?
Would it make more sense to switch to the simple recovery model and convince the business that in the worst case scenario they would have to re-input data for the day ?
I can't speak to 1 but for 2, I don't know that your position should be pushing the business toward a specific RPO (recovery point objective). They may not be aware that they'd have to re-enter all the data for a day if things go belly up. Talk to them, find out how much data loss they're willing to tolerate. If they say 24 hours is too much, great, then that indicates the current approach is insufficient for their needs. If that requires hardware purchase to meet the RPO, then they will need to provide funding or accept their current max data loss. Finally, document the outcome in some public place and then test on your restores a recurring basis to ensure you are able to meet that RPO.

That said, there are plenty of other reasons to have data and log (and temp) on separate drives. Some of them documented on this question https://serverfault.com/questions/38511/ms-sql-layout-for-best-performance