The truth is if it's that fragile, then recovery or repair are not options because you never know when you'll be done. Your best strategy is to rebuild. Organize the rebuild jobs from smallest (simplest, or least-complex) to biggest, and start from the smaller ones.
Importantly, you need to understand what your infrastructure does and why (which you claim you're already trying to do). However, the most critical point is that your superiors understand what you're up against and the risks they bite into if they choose to not go forward with the rebuild(s).
Once you understand what it is you need to rebuild, then you can do it properly: document the strategy to be followed (and incredibly important is that you document the key reasoning points behind the decision process), and plan out the implementation. If your superiors find that it consumes too much of your time, try to talk them into hiring (one? two?) more folks to help you hold the fort while the rebuilds are in progress so the day-to-day isn't left in the lurch. I had to go through this type of a situation recently and the end result of the rebuilds was that the previously inevitable downtime went away almost completely (only ISP outages were an issue). Deployment of new servers was cut down by 95%, and tons and tons of other benefits. Biggest of all: by the time I was done, everything essentially ran itself and even on the end-user support things were almost automated (granted, 99% of my audience were tech-savvy so they didn't need much help anyway). 95%+ of my time was spent just scouring logs and servers to ensure everything was running smoothly (which it was).
Then again, the key point was selling my upper management on the fact that my predecessors had done such a lousy job of setting everything up that trying to fix it was more expensive than a from-scratch rebuild, and that they were one fly's fart away from a catastrophe. You don't need to scare them shitless, just point out where they are and what they're up against if a rebuild isn't even done (even rebuild of only SOME of the systems can make a huge difference). Make sure it's clearly stated in writing (a "big" e-mail explaining the situation clearly to get the ball rolling usually takes care of that).
Key thing: DO NOT try to fix or recover the old stuff - if it's really as messed up as you suggest, you will consume comparable amounts of time to a rebuild, with none of the benefits and the added risk that you didn't fix all the problems because you couldn't spot some of them.
One other thing that served me well in terms of plotting my strategy: take the approach that I'm building something and going to be fired the day I'm done, and whatever I build needs to be inheritable and clearly understandable by my potential successors. This angle will encourage you to keep it simple, stupid, well documented, and easy to maintain/audit. In the end, this is why your predecessors sucked: they didn't think they'd eventually (be) move(d) on - but in IT, that's the one constant: staff rotation.