Well, to start, we can use beforestorage to wrap history from the production database, to the extent that your pack keeps it. Beyond that, we likely need to reach into backups, which I would suggest be FileStorage. For now, I am just starting with support for the former, and expect to get to the latter in due time.
I use RelStorage, then zodbconvert can create FileStorage backups and snapshot-rotate them on a retention policy (using bash scripts). I suspect I would have no problem using these (given proper configuration information).
Disclaimer: There is no way to go outside of production database's kept history without configuration, as I do not think we can introspect (a) how many days last pack kept; (b) location of backup FileStorage files; (c) naming convention. But making such configuration and function possible ought to be a goal for cases where the original source of error pre-dates history kept by the last pack.
This is simply kept in simple persistent records stored in site annotations on the live database by event subscribers. The date stamps may be slightly off from the transaction timestamps, but being close enough, we can infer the correct TID, then generate a correct datestamp to use for beforestorage. I am close to positive that this (application-level logging) will be more reliable and sufficient than trying to use ZODB transaction records alone.
This would, of course, depend on (a) ability to go beyond kept production history into (a copy of) your backups, (b) your data retention/rotation strategy. FileStorage is a relatively compact format, it is likely possible to have zodbconvert use zc.zlibstorage wrapping FileStorage to make backups even more compact, if you need near-line access to many of them.
Sean