Control system-state OS — ?

Somewhere I read an article where it was proposed to store system configuration in an ordinary version control system: to initialize inside the /etc directory of the local repository (it was on Linux) and there all to drive. Even if you correct something crooked, can not remember painfully that where the rules, just roll back the changes. The same can be done for the entire file system by adding to the ignore list unnecessary directories like /tmp.
\r
There are also programs like Acronis True Image where you can "freeze" the current state of the system and then either roll back all changes made after this point or to accept them.

What is "any previous state"? And for what OSes?
\r
In Linux, the integrity of the files installed from packages, know package managers. For example, in gentoo you can verify the integrity of package k3b like this:
\r
\rvvdm ~ # equery check k3b
* Checking app-cdr/k3b-2.0.1 ...
415 out of 415 files passed
\r
\r
Similarly, it can be done, for example, distributions based on rpm: www.rpm.org/max-rpm/ch-rpm-verify.html
\r
In debianday this: "debsums -ca "
\r
With the configuration files more difficult. They are designed to that would have to change. There is only one reasonable approach: making periodic backups. Once a week to archive the /etc/ as a rule sufficient.
\r
Theoretically, you could write a daemon that would monitor the status /etc/ and made notes about changes of certain configuration files, but I haven't heard that someone used this approach. Just as unnecessary.
\r
Sometimes there are tips to use some version control system for /etc/ (and in recent years it has become much easier with the advent of git, mercurial, and other DVCS), but in my experience, such a need never arose.
\r
P. S. Well, on Windows monitoring file integrity monitor anti-virus software is, in essence, their main job.

does

When talking about Windows, that is stroinoe tool System Recovery. Creates a checkpoint to return to if necessary. Maybe a complete backup to be done.
\r
Of third-party products — Norton Ghost or Acronis mentioned above.

Speaking of versioning of /etc directory there is a good article on versioned file systems. You can use any of this.
\r
And my own experience about Bacula is a reliable tool, if it is so complex and massive task. By cron or by means of pre - and post-task in bacula you can choose to collect data about packages (the same get-selections) at the time of copying. This will allow at any time to return any saved state of the system (with a relatively high probability of her performance).
\r
Speaking of virtualization is a great solution for saving ultimately a lot of time. Restore saved state virutalization machine takes a few minutes. Status (depending on the depth of the store versions) can be stored either on disk or on external storage (such as tape or network storage). Here a return to any state 100%. In this case, it is recommended to create a separate virtual disk/partition for the system and one for user documents. In this case, you can revert the system to any condition. retaining user data. In your case, it is still recommend to pay attention on virtualization-enabled snapshot.

versioned file system (VxFS)
snapshots of the file system (LVM)

Ubuntoo (okay, debian, writing in CZK):
1. Package list:
dpkg --get-selections > to the thread to get via svn
Commit in svn this file
diff file will allow you to "see" the new packages. This file will allow them all to put
\r
`dpkg --list` will still release, but difficult to restore state.
\r
2. Then wrote about storage /etc/ svn. Can also be committing for the crown, you can by hand after making changes.
Of the downsides of the approach: a bunch of folders .svn /etc
From pluses: in the vault you can see the changes and diffs for these changes. These settings can be deployed on another machine (although I don't think access rights are preserved, like the old svn is not stored — then to store, you need to svn stuff and information about the rights and owners on the files)
\r
In General, many linux distributions are very difficult to "downgrade" back when major updates, and it is in them in most cases, need to "remember" a condition. And in other cases, the changes made by the administrator, who should remember that changed.