Every save keeps the version it replaced

Every time an object is saved, Total CMS keeps the version it just replaced. Every time one is deleted, it keeps the final state. Getting back a paragraph a client overwrote, or a record someone deleted, is one command, and there is nothing to set up: history starts with the first save after you update to 3.6.

It is a record history, not a site backup. Only the object's data is kept, never its uploaded images or files, so the footprint stays small: a snapshot is the size of the record's JSON. Snapshots live in the data directory beside the content they protect, so they survive application updates and travel with any backup you already take of tcms-data.

Two rules decide how much is kept. Each object keeps its ten newest snapshots, and anything older than 30 days goes regardless. Count alone would let one busy afternoon push out last week's version, the one you actually wanted; age alone would let an untouched record hold a snapshot forever. Identical consecutive saves don't stack duplicates, and bulk imports write no snapshots at all. Tune both numbers, or switch history off, under Settings → Backups.

Restoring happens on the command line. tcms backup:list shows an object's snapshots and tcms backup:restore puts one back. A restore is an ordinary save, written through the same path the admin uses, so the collection index rebuilds and every listener fires — and the version you just overwrote becomes the newest snapshot, so undoing a restore is another restore. A deleted object comes back the same way, though any files it referenced are only there if they were never removed from disk.

Sync shares the same history: when tcms push overwrites a schema, collection or object, the file it replaced lands in the same place.