Допустим есть некий CMS, пользователь может делать что угодно, хоть локальный аппокалипсис организовать, но система должна каким то образом записывать все его действия и уметь восстанавливаться по первому требованию. Механизм существует в MediaWiki, движок wikipedia.org, но хотелось бы пойти дальше. Как:

• выявить все, не только деструктивные, действия? написать некое окружение, API которого все компоненты будут пользовать? Фишка под PHP, а там не на всё можно поставить хук, так что пока это кажеться единственным выходом, варианты?
• представить изменения любого рода? это изменения в БД, в файлах, просто какие то конфиги и другое. В принципе можно обьявить все возможные действия и в рамках этих действий реализовать пользовательский функционал. Тут три вопроса: какие это действия (в принципе не должны зависить от задачи, как IO API оси)? как выявить не инкрементальные (не зависящие от предидущего) изменения? и как это представить, физически сериализовать и записать в журнал?
• выполнять откат валидируя шаги, что бы откатом не убить систему ещё больше? Т.е. должен быть какой то снепшот системы в целом при котором откат заработает, иначе нет (например удалили таблицу в БД, в которую откат востановит данные). На каких принципах строить валидатор, да так что бы не тормозил проверяя всё?

На все вопросы сейчас рождаються мысли, обнозгую и чуть позже выложу. Интересует оценка тех кто с этим уже возился и вообще идеи как это всё порешать. Задача ИМХО очень сложная, в mediawiki зароюсь позже, когда появиться хоть какое то преставление проблемы. 

как я погимаю суть этакой программы:
  1 при старте ставятся хуки на все что можно (нужно)
  2 действия пользователя перехватываются этими хуками и вносятся в сою базу изменений, при этом на самом деле ничего не происходит (деструктивного)
  3 при запросах информации выдается инфа с учетом изменений хранящихся в проге.

Подобные программы не юзал (только слышал). отзывы были радужные но от ламеров.

Для себя вижу такие проблемы:
  При подмене удаления файлов место реально не освобождается. Следовательно может наступить ситуация когда места на винте физически не будет, а логически полно (много поудаляли). Как быть?
  При многопользовательской работе. + удаленные клиенты. Для каждого своя база свои подмены
  Срок действия такой подмены не более 1 сессии пользователя, иначе ... результат непредсказуем (могут возникать всякие нехорошие ситыации как с местом на диске).

Ну и политический момент: зачем разрешать делать то что делать пользователю нельзя? Тоесть если человек привыкнет к тому что его действия (деструктивные) не имеют никаких последствий то и отношение к безопасности и стабильности у него будет посредственное (если вобще будет), что может привести к пагубным результатам на машинах без подобной проги + прога может не от всего защищает.

Сумбурно, но мысли.

Добавлено @ 16:42 
для реализации реализации альфы думаю не менее 1000 чч (человеко часов) надо. Это я со своего уровня говорю может для профи и меньше. Но сомневаюсь.

В принципе это транзакции, как в БД, отсюда их проблема: короткое время работы. Нельзя держат транзакцию неделю, а идея в том что бы терпеть хотя бы 3-5 дней зверского издевательства над системой сотнями юзеров, сделав откат одного не терялись бы данные другого (этим бекап не подходит). Под PHP в принципе хуки не поставить, если только своё расширение писать, но можно заставить весь софт пользовать "фильтрованное" API. Новый софт должен конечно портироваться в такую среду, но это уже не так больно 


ИМХО не проблема, отказ по месту фатален по определеению. Сейчас пока идея держать корзину инкрементальных патчей, с каждого изменения снимаеться diff и кладёться в корзину под временем, откат в обратном порядке. При удалении весь файл в корзину. В принципе работать должно быстро, остановлюсь на этом если кто какую инновационную идею не подскажет 


Вот это проблема, пользователи юзают единую базу, запись может частями редактироваться (параллельно) двумя юзерами, при этом откат одного не должен разруштй изменения другого, но! должен как то выделить запись как возможно битую из-за отката. Юзер наделённый правами должен просмотреть запись, реверснуть откат или наоборот откатить всё из записи и вернуть её во множество не битых записей. Естественно передвижений не будет, просто дополнительные флаги и прочая мета инфа, потери мизерные по идее. Пока не до конца врубаюсь как это всё представить....


И тут трабла - срок несколько дней, конечно "мелкие откаты" можно фильтровать, но глобальные изменения (заменили документ, добавили 3 записи в БД и т.д.) должны храниться хотя бы пару дней.


Нет, человек будет получать в купол каждый раз как накосячит   Другое дело бывает "мышь дёрнулась" или "шеф прибежал, сказал всё вернуть!", система должна быть живуча на такие моменты. Откаты выполняет по прежнему человек, но у него должны быть в руках инструменты и данные, что бы работать.


Ну если под задачу, то можно уложиться и в меньшее    Откатами файлов сейчас займусь, под *nix'ы всё, пользую системными утилитами.