Database forensics reconstructs who changed data, what they changed, and when—by mining the transaction logs, redo logs, and audit trails a database keeps even after the visible record has been altered. SQL Server’s transaction log (read via fn_dblog), Oracle redo via LogMiner, PostgreSQL’s write-ahead log, and MySQL’s binary log each preserve INSERT, UPDATE, and DELETE activity that, correlated and hash-verified, exposes tampering, record backdating, and privileged-user abuse to a courtroom standard.
When a financial figure changes, a shipment record disappears, or a contract date is quietly moved, the current state of a database is the least trustworthy thing in the room—it shows only the last write, not the history that produced it. Yet relational engines are meticulous accountants of their own activity. To guarantee durability and enable recovery, every mainstream database writes a running journal of changes before it commits them. That journal, together with native audit trails, is where an insider’s edits, a backdated invoice, or a privileged deletion leave marks the application interface will never show. For general counsel, forensic accountants, corporate security, and litigators, database forensics is the discipline of turning those marks into a defensible reconstruction. This guide explains where the evidence lives across the major platforms, how elite examiners rebuild altered activity, and why the clock is the enemy.
What is database forensics, and how does it differ from ordinary digital forensics?
Conventional digital forensics recovers files, timestamps, and artifacts from an operating system. Database forensics operates a layer deeper, inside the engine that manages the data. Its subject is not a document but a transaction: a logically atomic change to one or more rows, recorded with a sequence identifier, a timestamp, and—often—the identity of the session that issued it. The central insight is that a relational database cannot be crash-safe without writing changes to a durable log before they reach the data files. That write-ahead requirement, present in every serious platform, means the history of modifications frequently survives even when the row itself has been overwritten or deleted.
This changes the questions an investigator can answer. Rather than asking only “what does the record say now,” a skilled examiner asks “what did it say before, who changed it, in what order, and does the recorded chronology match the story the parties are telling?” Insider data manipulation, altered financials, and record backdating are precisely the matters where the current state has been curated but the underlying journal has not. The examiner’s task is to read that journal correctly, correlate it with audit logs and backups, and present the reconstruction without overstating what the evidence supports.
Where does each major database record changes?
Every engine keeps a low-level record of modifications, but the mechanism, retention, and readability differ sharply. Knowing which structure to target—and how quickly it disappears—is the threshold competency of the discipline.
- Microsoft SQL Server writes every change to the transaction log (
.ldf). The undocumented but widely usedfn_dblog()function reads the active log, whilefn_dump_dblog()reads log backups, exposing operations such asLOP_INSERT_ROWS,LOP_MODIFY_ROW, andLOP_DELETE_ROWSagainst specific pages and rows. SQL Server Audit, Change Data Capture, and Change Tracking add higher-level trails when they were enabled in advance. - Oracle Database records changes in online redo logs, archived to archived redo logs when the database runs in ARCHIVELOG mode. LogMiner (
DBMS_LOGMNR) parses redo into readable SQL and, where supplemental logging is on, the reconstructed “undo” SQL to reverse a change. The undo tablespace and Flashback features can also expose prior row versions within a retention window. - PostgreSQL uses the write-ahead log (WAL), inspectable with
pg_waldump. Because WAL is oriented toward recovery rather than human analysis, examiners frequently pair it with logical decoding or the row-level history captured by a configured audit extension. - MySQL / MariaDB maintain the binary log (binlog), read with the
mysqlbinlogutility. In row-based format the binlog captures before-and-after images of each changed row—exceptionally valuable for reconstruction—whereas statement-based format records the SQL text instead.
A recurring pitfall is treating these logs as permanent. They are engineered for recovery and replication, not investigation, and most are recycled aggressively. That volatility—addressed below—is why the first hours of a database matter often determine what can ever be proven.
SQL Server vs. Oracle vs. PostgreSQL vs. MySQL: where the evidence lives
| Platform | Primary change journal | Reconstruction tooling | Native audit option | Volatility risk |
|---|---|---|---|---|
| SQL Server | Transaction log (.ldf) + log backups | fn_dblog(), fn_dump_dblog() | SQL Server Audit, CDC, Change Tracking | Truncated on backup; reused space overwritten |
| Oracle | Online + archived redo logs | LogMiner (DBMS_LOGMNR) | Unified/Fine-Grained Auditing | Online redo cycles fast; archiving may be off |
| PostgreSQL | Write-ahead log (WAL) | pg_waldump, logical decoding | pgAudit extension | WAL recycled after checkpoint |
| MySQL / MariaDB | Binary log (binlog) | mysqlbinlog | Enterprise/MariaDB Audit plugin | Expires on schedule; may be disabled |
The comparison exposes a hard truth: the richest evidence—row-level before/after images and reversible undo SQL—exists only when the right options were configured before the incident. A mature examiner assesses configuration first, then targets the highest-value surviving source rather than assuming a single tool will answer every question.
How do examiners reconstruct UPDATE, DELETE, and INSERT activity?
Reconstruction is the core deliverable. The goal is not merely to observe that a table changed but to rebuild the exact sequence of operations, ideally with before-and-after values and the responsible session. The method varies by engine but follows a consistent logic.
In SQL Server, fn_dblog() yields one row per log operation, ordered by Log Sequence Number (LSN). A modified row appears as LOP_MODIFY_ROW with the raw before and after bytes at a page offset; a deletion as LOP_DELETE_ROWS carrying the removed row image. Decoding those byte structures against the table schema reconstructs the prior value that the current record no longer shows. In Oracle, LogMiner returns both the executed SQL and, with supplemental logging enabled, the compensating undo SQL—so a deleted row can be re-expressed as the exact INSERT that would restore it. In MySQL’s row-based binlog, each event already contains the full before and after image. PostgreSQL’s WAL is the least human-readable, which is why examiners lean on logical-decoding output or a pre-existing audit trail to recover column-level detail.
Two disciplines separate credible reconstruction from a data dump. First, sequence over timestamp: LSNs, redo SCNs, and binlog positions establish the true order of operations even when wall-clock timestamps have been manipulated. Second, corroboration: a reconstructed change is anchored against backups, replicas, audit logs, and application logs so that no assertion rests on a single, contestable source.
What do native audit logs add that transaction logs cannot?
Transaction, redo, and WAL logs answer what changed at the storage layer; they are often silent on who did it and through which session. Native audit facilities close that gap—when they were switched on beforehand. SQL Server Audit can record the login, host, application, and statement for defined actions. Oracle Unified Auditing and Fine-Grained Auditing attach the database user, client identifier, and program to sensitive operations. PostgreSQL’s pgAudit and MySQL’s audit plugins log statement text with the connecting account. Together with change journals, these trails let an examiner move from “row 4471 was updated at this LSN” to “this privileged account, from this host, issued the update through this tool.”
Audit logs carry their own caveats. A sufficiently privileged insider may be able to disable auditing, purge entries, or operate through a shared service account that obscures individual attribution. That is why audit data is treated as one corroborating layer, not gospel—its presence, absence, and any gaps are themselves evidence. A conspicuous window in which auditing was turned off around the disputed change frequently tells a story as loud as the change itself.
How do you detect record backdating and altered financials?
Backdating is the signature fraud of database manipulation: a record is created or edited today but its stored date field is set to the past to fit a narrative—an invoice predated to a prior quarter, a contract timestamped before a cutoff, a log entry inserted to fill a gap. The manipulation lives in the disagreement between the value a human controls (a date column) and the metadata the engine controls (when the transaction actually committed).
- Commit time versus stored date. The change journal records when a row was truly written. If a row bearing an invoice date of January was in fact committed in June, the log exposes the contradiction directly.
- Sequence and identity gaps. Auto-increment identifiers and LSNs advance monotonically. A record with an early stored date but a high, out-of-place sequence value betrays after-the-fact insertion.
- Row placement on disk. A record claiming to be old often physically resides among recent rows, or in a page allocated long after its purported creation.
- Backup and replica divergence. A row “from last year” that is absent from last year’s backups, or differs on a replica, is strong evidence of later fabrication or alteration.
- Financial reconciliation. For forensic accountants, tying reconstructed ledger entries to source documents and control totals turns a technical anomaly into a quantified restatement.
No single indicator is conclusive, and each has innocent explanations that a rigorous examiner rules out. Assembled together, however, the disagreement between engine-controlled metadata and human-controlled fields is extraordinarily difficult to explain away—which is exactly why it withstands cross-examination.
Why does speed matter, and how volatile are these logs?
The defining constraint of database forensics is that its best evidence is engineered to disappear. Change journals exist to enable recovery and replication, not to preserve history for investigators, so databases reclaim them continuously. SQL Server truncates the inactive transaction log on backup and reuses the space; Oracle’s online redo logs cycle through a small fixed set and are lost unless archiving is enabled; PostgreSQL recycles WAL segments after each checkpoint; MySQL expires binlogs on a retention schedule and may not have them enabled at all. In a busy system, the window in which a specific change remains recoverable can be hours, not weeks.
Two behaviors make it worse. Ordinary production activity overwrites older log space as new transactions arrive, and well-meaning IT remediation—restarting services, restoring from backup, running maintenance jobs—can destroy the exact evidence in question. The practical rule is unforgiving: the moment manipulation is suspected, preservation must begin, because every hour of continued operation narrows what can ever be reconstructed. This is why database matters are treated as time-critical from first contact.
How do you build a court-defensible reconstruction?
Recovering the activity is only half the work; the reconstruction must survive challenge. Admissibility rests on the same pillars as any digital evidence, applied to a domain where opposing counsel will probe every inference. Use this framework from the first hour.
- Preserve before you analyze. Capture the transaction/redo/WAL/binlog and available backups immediately, with cryptographic hashes, before production activity overwrites them or IT “fixes” the system.
- Establish legal authority. Confirm data ownership, access rights, privilege, employment policy, and any cross-border or regulatory constraints before acquisition.
- Acquire with integrity. Take hash-verified copies of logs, backups, and, where feasible, a point-in-time image of the data files—working only on copies, never the live database.
- Reconstruct by sequence, not just time. Rebuild the operation order from LSNs, SCNs, or binlog positions so manipulated wall-clock timestamps cannot mislead the chronology.
- Corroborate across sources. Reconcile the change journal against audit logs, replicas, backups, and application logs so no finding depends on a single contestable artifact.
- Separate fact from inference. State plainly what is recorded versus what is reasoned, and document the limits—disabled auditing, recycled segments, shared accounts.
- Maintain chain of custody. Keep a continuous, documented record of who handled each image and export, from preservation through reporting.
- Report to an evidentiary standard. Deliver a reconstruction a non-technical judge or jury can follow, with the methodology, tools, and versions disclosed for a reliability inquiry.
The providers who separate world-class work from a screenshot of a query are those who articulate the boundaries of their own evidence. A report stating “the row was committed in June under this account, though its stored date reads January, and the change is absent from the May backup” is far more durable than one that leaps to “the controller committed fraud.” Federal courts also recognize streamlined self-authentication for records generated by an electronic process and for business records, which is precisely why disciplined, hash-verified acquisition matters from the first minute.
Representative scenario: the invoice that committed too late
Consider a representative dispute. A company’s records showed a large vendor invoice dated within a prior fiscal quarter, supporting a bonus threshold and a tax position. Opposing counsel suspected it had been created after the fact. Because the finance team had continued working in the system, examiners moved immediately to preserve the SQL Server transaction log and the most recent backups, hashing each. Reading the log with fn_dblog(), they located the LOP_INSERT_ROWS operation that created the invoice row and its Log Sequence Number—placing the true commit weeks after the quarter had closed and after several higher-numbered, later-dated records. The invoice was absent from the backup taken at quarter-end. SQL Server Audit, enabled for a separate compliance reason, attributed the insert to a privileged account outside normal accounts-payable workflow. No single artifact was decisive; reconciled together, with hashes and chain of custody intact, they reconstructed a backdated entry the stored date could not defend. This is an illustrative scenario, not a named client or claimed outcome—but it captures why database backdating is proven from engine metadata, not from the record’s own fields.
Do you handle database forensics nationwide?
Yes. Database forensics is delivered from our Arizona home command across all U.S. jurisdictions and internationally, because log acquisition, transaction reconstruction, and lawful analysis are in-house and remote-by-design. Whether the environment is on-premises SQL Server, an Oracle estate, a PostgreSQL cluster, or managed MySQL in the cloud, the same standards apply—hash-verified acquisitions, sequence-anchored reconstruction, continuous chain of custody, and court-ready reporting that distinguishes proven fact from reasoned inference.
Frequently asked questions
Can you recover a deleted or altered database record after it is gone?
Frequently, yes—provided you preserve quickly. Even when the visible row is deleted or overwritten, the engine’s change journal often still holds the operation: SQL Server’s transaction log records the deleted row image, Oracle’s redo logs (via LogMiner) can reconstruct compensating SQL, and MySQL’s row-based binary log stores before-and-after images. Backups, replicas, and undo/flashback data provide further recovery paths. The decisive variable is time, because these logs are recycled continuously; the sooner they are captured and hashed, the more can be reconstructed.
How can you prove a record was backdated?
Backdating is proven by contradicting the human-controlled date field with engine-controlled metadata. The change journal records when the row was actually committed, so a January invoice committed in June is exposed directly. Monotonic sequence identifiers (auto-increment values, LSNs, redo SCNs) that are out of place for the claimed date, the row’s physical placement among newer records, and its absence from period-end backups all corroborate the finding. Assembled together, these engine-level signals are extremely difficult to explain innocently and hold up under cross-examination.
What is the single most important step when database tampering is suspected?
Preserve the logs and backups before anything else, and stop routine remediation. Transaction logs, redo logs, WAL, and binlogs are engineered for recovery, not investigation, so ordinary activity overwrites them within hours and well-meaning IT actions—restores, restarts, maintenance jobs—can destroy the exact evidence at issue. Capture hash-verified copies of the change journal, audit logs, and recent backups immediately, place litigation holds, and analyze only copies. Early preservation is what keeps a court-defensible reconstruction possible.
Do we need auditing enabled in advance to investigate later?
It helps enormously but is not strictly required. Native audit trails (SQL Server Audit, Oracle Unified Auditing, pgAudit, MySQL audit plugins) are the cleanest source of who did what, and enabling them beforehand is best practice. When they were off, examiners still reconstruct the changes themselves from the transaction, redo, WAL, or binary logs and attribute activity by correlating sessions, hosts, and application logs. The reconstruction is simply harder and leans more on corroboration—another reason speed of preservation matters.
About Honeybadger Solutions
Honeybadger Solutions is an Arizona-licensed security and investigations firm providing digital forensics, cybersecurity, and full-spectrum investigations to organizations, counsel, insurers, forensic accountants, and principals nationwide and internationally. Our forensics, cybersecurity, financial-investigations, and background-intelligence capabilities are in-house and remote-by-design, conducted under recognized methodologies with hash-verified acquisitions, continuous chain of custody, and board- and court-ready reporting. We operate three Arizona offices—Casa Grande (headquarters), Phoenix, and Oro Valley—and support engagements across every Arizona venue, all U.S. jurisdictions, and abroad.
Suspect a ledger, invoice, or database record was altered, deleted, or backdated? Call 602-725-2818 to brief a digital-forensics lead and preserve the transaction logs before they are recycled. Confidential. Defensible. Nationwide.
Authoritative references: NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response and Federal Rules of Evidence, Rule 902(13)–(14) (Self-Authentication of Electronic Records).