First of all, keep in mind that the sql injection vulnerability does not only involve possible compromised content; for example an attacker may have benefit from this exploit in order to log in as user with uid 1 (or create a new user with advanced privileges), thus gaining the possibility to alter content, structure (views, menus, taxonomies, panels e.t.c) and even upload/inject malicious php code (and of course execute it). It is good that you assume the worst case scenario of your sites being compromised, but I would first advice you to actually check/look for confirmation (possible compromisations and their extent) before acting.
How? Unfortunately, mainly manually. Here is a list of some things you should check out first. Then I would personally check the server access logs (using log analyzer software depending on your web server) and Drupal logs (watchdog) for suspicious actions of any kind (e.g. user creation/edits, content deletions/edits, structure alterations in views/panels/CTs). Then, Hacked module, will help you identify any code changes. You might want to skip this step, but answers to these questions and acquiring a general overview of the server/site status will affect the decision/strategy on how to rebuild/clean up your sites:
You are talking about re-building your sites. In the first case you will use the available pre-exploit database backup. OK, this will make sure that content/configurations/structural elements are reverted back to their original state. What about the code? Drupal core, contributed/custom modules? You will use the current live one(s)? Are you sure they are 'clean' and malicious-code-free? What if they are compromised as well? This is why the damage assessment step is highly important. Only after ensuring that your 're-built' (up to the restore point) is safe then you should worry about the additional content missing from the backup. And this gets even harder for the second case - the second website for which no backup is available.
The reason that documentation is missing a data restore/clean up plan, is that simply there is not an optimal plan/solution for all usecases. And the complexity increases if you think the endless ways an attacker might have compromised a site; for a news site for example an attacker (having gained access to a user's account) may have edited an article and changed the original author's opinion or the presented facts (looks like a legitimate edit, no spamming or weird markup, thus it is very difficult to spot). However, there are plenty of tools, modules and processes that can be used to address similar situations/problems.
I would be more than happy to help you compile a recovery strategy, but I need more feedback:
- Were you involved in the development phase of those sites? (as manual checks might be needed, it is preferable if you have a general idea on how the sites are supposed to operate by design and prior to any possible alterations)
- How big/small your sites are? How many CTs? How many fields each? How many instances/nodes in total? Taxonomies? Views? Panels? Webforms?
- Have you been using Features when building those?
- Is code versioned (e.g. git, subversion)?
- Do you have development environments set up for those sites/projects? Are those up to date/synced with their current production versions?
- During the sites' lifecycles, if any additional structural changes were necessary (e.g. change the configuration of a view, add an extra field to a CT), how those were performed? Directly in the live site? Or they were performed/tested in a staging/development environment first?
- Have you created/implemented any custom modules for those sites? Custom themes?