Іншим засобом підтримки цілісності є запозичений з систем управління базами даних прийом, званий журналізація (іноді уживається термін "журналирование"). Послідовність дій з об'єктами під час файлової операції протоколюється, і якщо відбувся останов системи, то, маючи в наявності протокол, можна здійснити відкіт системи назад в початковий цілісний стан, в якому вона перебувала до початку операції. Подібна надмірність може коштувати дорого, але вона оправданна, оскільки у разі відмови дозволяє реконструювати втрачені дані.
Для відкоту необхідно, щоб для кожної протокольованої в журналі операції існувала зворотна. Наприклад, для каталогів і реляційних СУБД це саме так. З цієї причини, на відміну від СУБД, у файлових системах протоколюються не всі зміни, а лише зміни метаданих (індексних вузлів, записів в каталогах і ін.). Зміни в даних користувача в протокол не заносяться. Крім того, якщо протоколювати зміни призначених для користувача даних, то цим буде завданий серйозного збитку продуктивності системи, оскільки кешування втратить сенс.
Журналізація реалізована в NTFS, Ext3FS, REISERFS і інших системах. Щоб підкреслити складність завдання, потрібно відзначити, що існують не цілком очевидні проблеми, пов'язані з процедурою відкоту. Наприклад, відміна одних змін може зачіпати дані, вже використані іншими файловими операціями. Це означає, що такі операції також мають бути скасовані. Дана проблема отримала назву каскадного відкоту транзакцій [Брукшир, 2001]