Defense in depth.

Remove the unneeded code so it never executes. If it's needed, block features you don't need. For the rest go one level higher and block operations you don't need. (php.ini controls, file permissions, LSM, etc.) For operations that are allowed, ensure data/code separation to prevent persistence. When that fails, have a very restrictive firewall so that data extraction and attacking other systems is difficult. Have network restrictions again one level higher. (switches / cloud network) If everything fails, have detailed logs to know what failed and when. If even that fails, have backups. If that fails, have company insurance prepared.

> Should we pre-emptively have our servers rebuild daily just in case a 0-day backdoored them?

Depends on your threat model and available money. Are you trying to stop automated malware or state actors? In the first case a good configuration should be enough. In the second you may want to start thinking about how you're going to verify the firmware your harddrives are running. And there's a whole spectrum in between.

I mean, to block majority of php blog/cms malware it's enough to make sure your code is owned by user A, php server runs as user B, and B cannot write to A's files. 0-day or not, lots of stupid automated malware stopped.

> It's not possible for me to track all the 0 days for every piece of software and library that my servers run.

That's why it's nice to run unmodified distro software. Because these guys can track it for you: http://www.ubuntu.com/usn/ (for example, any reasonable distro has similar announcements)