Recovery methodsTechnicalUpdated October 17, 2026 · Data Recovery Cases Editorial Team

Filesystem Journals and Crash Consistency

A filesystem journal exists so that the filesystem’s own metadata can be brought back to a consistent state after a crash or power loss. How it does that differs between filesystems, and none of the mechanisms is a general-purpose backup of earlier file versions or a promise that every write an application expected to land actually did.

In short

NTFS $LogFile and ext4 JBD2 both restore metadata consistency, by different mechanisms.
The USN change journal records that files changed, not their old bytes, and cannot reverse a change.
A consistent filesystem does not mean a database, VM disk or document inside it is intact.
Replay writes to the source, even on a read-only ext4 mount.
Replay is not repair, and neither is recovery; image the source first.

What journaling actually solves

Filesystem metadata — directory entries, allocation bitmaps, inode or file-record fields — is usually updated through several related writes. If power loss or a crash interrupts that sequence partway through, the metadata can be left internally inconsistent: a block marked both allocated and free, a directory entry pointing at a record that no longer matches it. A journal exists to make that specific failure recoverable: it records enough about pending metadata changes that, the next time the filesystem is mounted, they can be brought to a consistent state instead of being left half-applied.

That shared goal is where the similarity ends. What is recorded, how a transaction is judged complete, and what happens to an incomplete one are defined separately by each filesystem, so the description of one journal — including terms such as redo, undo, commit record or revoke — should not be carried over literally to another.

Four kinds of log, four different promises

Recovery discussions often use “the journal” for several unrelated structures. The table separates the ones most often confused on NTFS and ext4 volumes; it is not a survey of every filesystem.

Scroll horizontally to see the full table →

What each log is for, what it can contribute as evidence, and what it does not promise
Log	Purpose	Possible evidence	Not promised
NTFS `$LogFile`	Transaction log and checkpoint information used to restore filesystem consistency after a failure	Indications of recent metadata activity, where records have not yet been reused	Previous file contents, a complete history, or an undelete database
NTFS USN change journal (`$UsnJrnl`)	Per-volume record that files and directories changed, with the name and reason flags	Names, reasons such as create, delete, rename or overwrite, and ordering by USN for the records that survive	Old file bytes, the order of every individual write, a way to reverse a change, or coverage beyond what has been trimmed
ext4 JBD2 journal	Bring metadata (and, in `data=journal` mode, data) to a consistent state after a crash	Copies of committed blocks or fast-commit deltas still present in the journal area	A chronological archive of user writes, or consistent file data in the default mode
Application log (database, VM, mail store)	The application’s own transactional or recovery state	Whether the application’s own transactions were complete, using its own tools	Anything about the filesystem underneath; it depends on the filesystem having stored its files

NTFS `$LogFile`: consistency, not history

Microsoft’s NTFS overview describes NTFS as maintaining a transaction-based log file and checkpoint information, and using that log after a system failure to restore filesystem consistency automatically during the next startup. That is the role to keep in mind: $LogFile is a consistency mechanism for the filesystem itself. It should not be described as a backup, a full historical record of file content, or an undelete database — a common but mistaken assumption, since people hear “journal” and imagine old file versions being replayed backward.

The detailed on-disk record format and recovery algorithm of $LogFile are not part of that public overview, and this page does not reconstruct them. In particular, whatever NTFS does with incomplete operations at mount time is NTFS behaviour; it is not a model for ext4, whose journal is described below in its own terms.

NTFS `$UsnJrnl`: change records, not content

NTFS additionally keeps a USN change journal, a separate structure with a separate job. Microsoft documents it as a per-volume record that is updated, whenever a file or directory changes, with a description of the change and the name of the object (Change Journals). So $LogFile and $UsnJrnl answer different questions: the first is about whether the filesystem’s transactions can be brought to a consistent state, the second about which objects changed and roughly why.

Several properties limit how far USN records can be read as a timeline:

No reversal. Microsoft states that the change journal logs the fact of a change and its reason, and does not record enough information to reverse the change (Change Journal Records). A record that a file was overwritten does not contain the bytes it had before.
Aggregated reasons. Repeated changes of the same kind to the same file may add only one reason flag to the current record rather than a new record each time, and the record written at close is a summary that gives no indication of the order of the changes. USN data therefore is not a log of every individual write.
Finite coverage. The journal is trimmed from its beginning once it exceeds its configured size, and an administrator can delete and re-create it (Creating, Modifying, and Deleting a Change Journal). The absence of a record is not, by itself, evidence that nothing happened.

The recovery value of USN data is context: historical names, evidence that an object existed, and correlating delete or rename events with other evidence. Finding a record does not make the change undoable; any content still has to come from the volume itself, a snapshot or a backup.

ext4 JBD2: commits, checksums and revocation

The Linux kernel’s ext4 journal documentation describes JBD2 as protecting the filesystem against metadata inconsistencies after a system crash. Its own vocabulary matters for interpretation:

Descriptor and commit. A transaction is written as a descriptor block, which lists the final locations of the journaled blocks that follow, then the blocks themselves, then a commit block. The kernel documentation states that if there is no commit record, or the checksums do not match, the transaction is discarded during replay; committed transactions are replayed by writing their blocks to their final locations.
Revocation. A revoke record marks blocks that were journaled earlier but must not be replayed, typically because a metadata block was freed and reused for file data. Without it, replay could overwrite that newer data. The documentation warns that revocation does not mean “this block is superseded by another”.
Not an archive. The journal is a working area for pending transactions, not a chronological store of user activity. Once transactions are checkpointed to their final locations, the journal area is used again for new ones, so what remains in it at any moment is a narrow, recent and incomplete slice.

Data modes differ in what goes through the journal and which ordering promises are made, as described in the kernel’s ext4 administration guide. In the default data=ordered mode, data is forced out to the main filesystem before the related metadata is committed to the journal, but only metadata is journaled; the journal documentation notes that file data blocks are not guaranteed to be in any consistent state after a crash. In data=writeback, data ordering is not preserved. In data=journal, data is committed into the journal before being written to the main filesystem. None of the modes promises that every user write issued just before a crash survived it.

Fast commits, where enabled, store a minimal logical description of the metadata change in a separate fast-commit area instead of full metadata blocks; a later full commit invalidates the earlier fast commits. It is a different representation of recent changes, not a full copy of the filesystem.

The configured journal mode is therefore not a diagnosis of recoverability. Whether anything useful remains depends on the specific filesystem: what was in the journal at the time, whether replay has already happened, and what has been reused since. The surrounding ext4 structures — superblocks, inodes, extents and orphan handling — are covered in ext4 Superblocks, Inodes, Extents and Journal.

Filesystem, application, crash-consistent and application-consistent

Four terms are often blurred together:

Filesystem transaction — a group of metadata updates the filesystem itself treats as one unit. The journal is about these.
Application transaction — a unit of work in a database, mail store or VM, which may span many files and many filesystem operations. The filesystem journal knows nothing about where it begins or ends.
Crash-consistent image — a copy that looks as if power was cut at one instant. After replay it can mount cleanly while an application inside it still needs its own recovery.
Application-consistent capture — a copy taken after the application flushed or quiesced its state, so its own data is coherent at that point. How such copies are made is covered in Live Systems, Snapshots and Consistent Recovery Copies.

This is why a volume that mounts cleanly after replay does not mean a database, virtual machine disk or document on it is intact: the journal restored the filesystem’s structures, not the application’s logical state, which its own logs and tools have to establish. Even the filesystem’s guarantees depend on the storage stack: the ext4 administration guide explains that write barriers enforce on-disk ordering of journal commits so that volatile disk write caches are safe to use, and that disabling them may be safe when the disks are battery-backed. Statements such as “the data was flushed, so it survived power loss” depend on the application, the mount options, and the controller and drive cache behaviour; they are not universal.

Replay is a write, even on a read-only mount

Journal replay writes committed blocks to their final locations on the volume. On a damaged volume that matters even when nobody intends to change anything. The ext4 administration guide notes that ext4 replays the journal, and thus writes to the partition, even when mounted read-only; the noload option skips loading the journal, but the same guide warns that after an unclean unmount this leaves the filesystem containing inconsistencies. A read-only, no-replay view can therefore be a useful way to look without writing, but what it shows may be inconsistent, and it is not a repair or an undelete method. NTFS likewise uses its log at the next startup to restore consistency.

The practical consequences, and the other layers at which read-only can be enforced, are covered in Why Mounting a Damaged File System Can Be Risky.

Replay is not repair, and neither is recovery

On ext4, JBD2 replay applies transactions that have a valid commit record, up to the latest one, to reach a consistent, recent state — a narrow, defined operation. Other filesystems recover from their logs by their own rules, such as the NTFS log recovery described above. In either case, replay does not fix damage the log never described, such as a corrupted directory or an overwritten metadata region. Filesystem repair is much broader: it can rewrite trees, discard orphaned records, rebuild allocation metadata, relink files, free blocks and alter directory structures outright, and it may or may not include a replay. A filesystem that becomes mountable after either may no longer contain every structure that existed before, which is the subject of Repair vs. Recovery.

When recovering existing data is the goal, unique metadata — including the journal area itself — is preserved before either operation, by imaging the source. Replay or repair, if needed, is then run on a copy, and the states before and after are compared, rather than repairing the only copy and losing the ability to see what changed.

Practical rule

Preserve the source before replaying or repairing a journal, whenever recovering existing data — rather than simply reusing the filesystem going forward — is the actual goal.

What a journal can say about earlier states

Journals are finite, managed regions reused as new transactions occur: older records are overwritten by newer ones, the USN journal is trimmed from its beginning, mounting can trigger a replay of pending state, and ordinary activity keeps updating metadata. A journal can help explain recent structure and context — which names existed, which objects changed, which metadata blocks were in flight — but it does not guarantee a previous version of any file’s contents, and reuse and overwriting limit how far back any inference can reach. There is no general “roll the journal back” method for recovering files; earlier versions come from snapshots, backups or previous-version mechanisms where they exist.

Illustrative example: an overwritten spreadsheet on an NTFS volume

Observed

A spreadsheet was saved over with wrong content. The volume’s USN change journal still holds records for the file name with data-overwrite and close reasons.

Interpretation

The records support that the file was changed and when, under that name. They do not contain the previous bytes and cannot reverse the save; the close record does not show the order of the changes it summarises.

Safer next step

Preserve the volume, then look for the earlier content where it could actually exist: snapshots, backups, application temporary or autosave files, or unallocated remnants examined on the image.

Limit

If the old clusters were reused and no snapshot or backup exists, the journal records may be the only trace that the earlier version existed; they do not make it recoverable.

Technical references: Microsoft: NTFS overview — transaction log and consistency at startup · Microsoft: Change Journal Records — what USN records can and cannot do · Linux kernel: ext4 Journal (jbd2) — commit, checksums, revocation, fast commits · Linux kernel 6.12: ext4 administration guide — read-only replay, noload, data modes. Option behaviour can differ in other kernels; the Microsoft pages do not document the $LogFile on-disk format.