Механізм індивідуального відкату заснований на зворотному виконанні всіх змін, зроблених даною транзакцією (undo). При цьому з журналу в зворотному хронологічному порядку вибираються всі записи про зміну бази даних, зроблені від імені даної транзакції. Для цього необхідна ідентифікація всіх записів в журналі. У System R всі записи однієї транзакції зв'язуються в один список в порядку, зворотному хронологічному. Посилання в списку являє собою адресу запису в файлі-журналі. Оскільки схема індивідуального відкату єдина для всіх ситуацій індивідуальних збоїв, зокрема для ситуації руйнування тупиків, то зворотне виконання операцій супроводиться зняттям встановлених при прямій роботі транзакції синхронізаційних захоплень з об'єктів бази даних. Отже, після виконання індивідуального відкату транзакції ситуація в системі така, як якби транзакція ніколи і не починалася.

Специфіка м'якого збою системи складається у втраті стану оперативної пам'яті. У оперативній пам'яті знаходяться буфера бази даних. Підтримуються буфера двох сортів: буфера журналу і буфера власне бази даних. Буфера журналу містять останні записи в журнал. Є два буфери журналу. Як тільки один буфер повністю заповнюється, проводиться його запис в файл-журнал і продовжується заповнення другого буфера. Таким чином, при звичайній роботі системи обміни з файлом журналу не приводять до припинення роботи. Буфера бази даних містять копії сторінок бази даних, які використовувалися останнім часом. Внаслідок звичайних в програмуванні принципів локалізації посилань досить ймовірно, що після приміщення копії сторінки бази даних в буфер ця сторінка зажадається в найближчому майбутньому. Тому наявність копії сторінки в буфері дозволить уникнути обміну з пристроєм зовнішньої пам'яті, коли ця сторінка знадобиться в наступний раз.

Помітимо, що розмір буферного пулу СУБД багато в чому визначає її продуктивність. Звичайна реляційна СУБД, така, як System R, при наявності достатнього розміру буферного пулу цілком конкурентноздатна по відношенню до систем, заснованих на спеціалізованій апаратурі машин баз даних.

Задача System R по забезпеченню надійного завершення транзакцій, тобто гарантованій наявності вироблених ними змін в базі даних, вимагає наявності у зовнішній пам'яті інформації про ці зміни. Для цього при закінченні будь-якої транзакції підтримується гарантована присутність в файлі-журналі всіх записів про зміни, зроблені цією транзакцією. При використанні буферизації для запису в журнал для цього досить насильно виштовхнути у зовнішню пам'ять недозаповнений буфер журналу. Під насильним виштовхуванням розуміється запис буфера у зовнішню пам'ять відповідно не до логіки ведення журналу, а з логікою закінчення транзакції. Тільки після здійснення такого насильного виштовхування буфера журналу транзакція вважається такою, що закінчилася. Помітимо, що останнім записом в журналі від будь-якої транзакції, що змінює базу даних є запис про кінець транзакції. Ці записи використовуються при відновленні. Розглянемо тепер (поки не зовсім точно) як здійснюється в System R відновлення бази даних після м'якого збою.

Основою алгоритму відновлення є те, що система дотримується правила попереджуючого запису в журнал (WAL - Write Ahead Log). Це правило означає, що при виштовхуванні будь-якої сторінки з буфера сторінок спочатку гарантується наявність в файлі журналу запису, що відноситься до змін цієї сторінки після моменту її виштовхування в буфер. Оскільки записи в журнал блокуються, то для дотримання правила WAL перед виштовхуванням сторінки даних необхідно виштовхнути недозаповнений буфер журналу, якщо він містить запис, що відноситься до зміни сторінки. Застосування правила WAL гарантує, що якщо у зовнішній пам'яті знаходиться сторінка бази даних, то в файлі журналу знаходяться всі записи про операції, що спричинили зміну цієї сторінки. Зворотне невірне: в файлі журналу можуть міститися записи про зміну деяких сторінок бази даних, а самі ці зміни можуть бути не відображені в станах сторінок у зовнішній пам'яті.

При закінченні будь-якої транзакції (тобто виконанні операції RSS END TRANSACTION) проводиться виштовхування недозаповненого буфера журналу і тим самим гарантується наявність в журналі повної інформації про всі зміни, зроблені даною транзакцією. Насильне виштовхування сторінок буфера бази даних не проводиться (дуже накладно було б виробляти такі виштовхування при закінченні будь-якої транзакції). Тим самим після м'якого збою стан бази даних у зовнішній пам'яті може не відповідати тому, яке повинне було б бути після закінчення транзакцій. Отже, після м'якого збою деякі сторінки у зовнішній пам'яті можуть не містити інформації, вміщеної в них транзакціями, що вже закінчилися, а інші сторінки можуть містити інформацію, вміщену транзакціями, які до моменту збою не закінчилися. При відновленні необхідно додати інформацію в сторінках першого типу і видалити інформацію в сторінках другого типу.

System R періодично встановлює системні контрольні точки. Більш детально ми зупинимося на цьому нижче. Поки помітимо лише, що при встановленні такої контрольної точки проводиться насильне виштовхування у зовнішню пам'ять буфера журналу і всіх буферів сторінок. Це операція, що дорого коштує, і виконується вона досить рідко. При кожній системній контрольній точці в журнал вміщується спеціальний запис.

Передбачимо, що остання системна контрольна точка встановлювалася в момент часу tc, а м'який збій стався в деякий більш пізній момент часу tf. Тоді всі транзакції системи можна розбити на п'ять категорій.

Транзакції категорії Т1 почалися і кінчилися до моменту tc. Отже, всі вироблені ними зміни бази даних надійно знаходяться у зовнішній пам'яті, і по відношенню до них ніяких дій при відновленні проводити не треба. Транзакції категорії Т2 почалися до моменту tc, але встигли кінчитися до моменту м'якого збою