I've been part of the IT team in small buisnesses a couple of times now. I prefer doing development, but during some of the lean times one does what one can. The first problem is the nature of the job. IT is just never going to be pure 9 to 5 work. There's too many things that have to happen when there aren't a large number (as in any) of the users using the systems. You can do maintenance during the day, but if you do you probably deserve some abuse, depending on how badly you wreck everyone's day. I've seen good and bad with this... bad is keeping half of the company from doing their jobs. Most small businesses can't afford that.
A lot of the folks that get hired to do IT for small to medium sized buisnesses aren't quite up to the job either. I've seen all sorts of technical mistakes made. The bit about backups is a key. People reuse tape (ok I'm old) or other media past the safety limit (which is a hell of a lot smaller than most people think it is) and then they also implement storage solutions that are almost impossible to manage or back up. They don't test backups, and they don't implement best practices because they don't have time. And because they don't do these things they never will have time to do anything other than react to the current crisis. Working for a small company is a lot harder than a big shop, one guy has to know a lot of fairly specialized things. Bringing a guy from a big shop down usually isn't possible, as no one can afford them. Even worse, the things that you do for large shops are often just not the right way to manage a small business. It's stupid to plan for a network that can fit into a 200000 person organization when it's not going to have more than 100 users. Virtualization isn't a good idea when you end up running everything on one machine, and you don't have any spare hardware to take up the load when that one goes belly up. (been there saw that... didn't implement it - argued about it, wish I'd been wrong!)
In all fairness there's a lot of pressure from the other side as well. Small business owners want the same kind of functionality that large companies have, and don't want to pay for it. I've seen eager IT guys running demos to prove they can do things, and then have the people who control their pay tell them to implement it with no budget. There's a skill to presenting the bill that most training doesn't cover. Even if it did, you can lose a job because someone brought in an illegal copy of something and made it look like you don't have the skills. I've also seen that small businesses can't afford the training to keep their people current. So they hire replacements when they change technology. The replacements usually can't handle the legacy stuff and the situation continues going from bad to worse.
And then there's managing the users. A lot of upper level managers don't understand how damaging it is when one department starts implementing crap that doesn't fit in the enterprize. But the users are often reacting to either perceived, or in many cases actual, neglect from the IT staff. If there's a real need out there and it isn't being met, you can expect anyone who's worth being hired to try to find a solution. The fact that it's a bad solution in the long term doesn't make the reaction wrong. I've implemented some of those rogue systems myself when I couldn't get an IT group to respond when I offered them funding to get the people and hardware they needed to do the job. That one probably cost someone I liked his job, but I still needed to solve the problem I'd been given. But there's also the lusers who can't seem to resist clicking on the destroy the system now attachement. Hell we had one CFO who wouldn't pay to have the AV suite license renewed... or the SSL certs. But it was the IT guy's fault when the company shut down for three days. In my opinion it was too, I was his backup and got the cash released by telling the owner what was going to happen if they did it again. But the other guy needed his job more than I needed mine - and was fired because he didn't do the hard thing.
Like I said, the problem's fairly complex. I don't think simple statements about it actually help much. It'd be interesting to see what a book that detailed how to make it all happen correctly in the real world. Something like Yourdon's _Death_March_ but for SMB IT folks. It's certainly more than can be put in a post here.