First a little disclaimer… you should be backing up your data. If you’re not, stop reading and go work out a backup strategy.
We recently had an issue where our primary SCCM site server failed to boot after updates were applied to it. As it turned out, for whatever reason one of the secondary drives for the VM had been corrupted and we had to detach it from the VM to run a repair on the VHD. This drive happened to contain not only the entirety of our packaging efforts (source files, scripts, etc), but also was the default and only content storage location for our primary site DP role.
What we didn’t know – and what I’m sharing with you today – is now painfully obvious to me but slipped me by at the time. When we detached the drive from the VM and booted SCCM to reattach it and run repairs, the SCCM core components had already started up and didn’t see it’s content storage location. So after we repaired the drive when we expected everything to start working again (namely distributions from the DP) we were surprised when it refused to deliver anything that we didn’t refresh.