I agree with Zenst below that it's a separate (though not less important) issue. The backups are there to get the customer back on their feet as quickly as possible, and to protect their data. A surprising number of our clients have had problems with websites related to not having any backups or local copies ... web-based CMSs have made this a remarkably easy trap to fall into.
The nature of the compromise is something we'd be interested in, and hopefully something that they'd bring to our attention. I'd like to be able to have our log monitoring software watch for attempts at common exploits and automatically block them, but it doesn't do that yet. Which is one reason why it's still not ready for launch yet. :-)
Content and software are seperate. Were talking about content and not the software. Sure you fix the flaw in the software that allowed the expliot or the weak password or however the site was taken over, but it is a seprate issue.
They are separate in the PHP software that gets targeted by "the vast majority of hacks". Those hacks are against popular CMS packages that can be scanned for and exploited in an automated fashion. In a CMS, the software being exploited and the content are separate, in PHP as every other language.
The PHP files where the content and the system are one and the same (hand written pages not using a packaged CMS) aren't part of "the vast majority of hacks" category. Compared to exploiting a WordPress vulnerability in 50+ million installs, someone trying to mess with the black box that is someone's custom written page happens insignificantly rarely. Your retort doesn't hold water.
> The PHP files where the content and the system are one and the same (hand written pages not using a packaged CMS) aren't part of "the vast majority of hacks" category.
Speaking from experience, this is simply not true. There are automated scanners in the wild which will attempt to detect and exploit common vulnerabilities in simple PHP templating systems and CMSes. One frequently exploited vulnerability is in applications which use URLs of the form:
index.php?page=foobar
With supporting code along the lines of:
$page = $_GET["page"]; /* if register_globals isn't set */
include("pages/$page.html");
Until relatively recently, when PHP started rejecting filenames with embedded null bytes, code like this was vulnerable to input such as:
As a reporting tool it could be interesting though.