You’ve probably used the Versioning system in macOS without knowing it. In a great many apps, the Revert To / Browse All Versions… command in the File menu opens a version browser quite similar to the Time Machine app, in which you can look through previously saved versions of that document, and revert to one when you wish. It has got me out of a few problems in the past, when I’ve discovered that a large and crucial chunk of a document has gone missing, and there’s been no previous Time Machine backup containing it. The Versioning system can be a real life-saver at times.
If you read my article yesterday about bugs in Time Machine, you’ll recall my observation that first full backups seem to get stuck trying to make a backup of the Versioning database, which is stored in the locked and hidden folder .DocumentRevisions-V100 at the root of each volume. So, unlike all other backup systems for macOS, Time Machine makes backups of that database too, to the point where that can now take hours to complete.
Information about the value of this database isn’t always as complete as it could be. For instance, the Carbon Copy Cloner Knowledge Base (ccc5) states that that app doesn’t attempt to clone the Versioning database because “The DocumentRevisions data store is used by the Versions feature in macOS. The Versions database stored in this folder contains references to the inode of each file that is under version control. File inodes are volume-specific, so this dataset will have no relevance on a cloned volume.”
What that doesn’t tell you is that, without that Versioning database, all old versions of your documents are lost forever from your cloned volume. And that can be a very signficant loss indeed.
So, Time Machine goes out of its way, and your time, to ensure that the Versioning database is copied for each volume it backs up. You might therefore presume that when you restore a document from a Time Machine backup, that restores all its old versions too. Only you’d be wrong: restored documents from Time Machine backups also lose all their old versions. You might consider that to be a bug, and I’d agree with you.
As far as I can tell, in recent versions of macOS including 10.15.3, the only way that you might get access to the old versions of a document is when you perform a full volume restore, which isn’t sensible when all you want are previous versions of a single document. This is because the backup .DocumentRevisions-V100 database isn’t at the root of the Time Machine backup volume, but stored inside each backup for that specific volume. Whether Time Machine’s volume restore feature is smart enough to actually do this I don’t know, but it certainly doesn’t work for individual documents.
To summarise so far:
- To back up Versioning information for documents, Time Machine builds a local .DocumentRevisions-V100 folder in each volume’s backup.
- Backing up Versioning information in 10.15.3 (at least) can take very long times during Time Machine’s first full backup, to the point where that backup isn’t feasible.
- Restoring individual documents from Time Machine backups doesn’t restore their previous versions.
- Restoring complete volumes from Time Machine backups might restore previous versions.
- Third-party cloning and backup apps don’t attempt to back up Versioning information, so lose all previous versions in their clones/backups in any case.
It does make you wonder why Apple chose neither of the obvious solutions: always restore previous versions, or simply forget the whole idea of backing up the Versioning database, as every other app does.
While we’re thinking about problems with Time Machine, I have another strange observation from 10.15.3 which could trip someone up.
When you add an item to the list of those excluded from backups, in the Options of the Time Machine pane, folder paths are tested against each volume being backed up. So, if you excluded a top-level folder named
Documents on an external drive named
johnsmith, when making each backup, Time Machine will look for that path of /Volumes/johnsmith/Documents on each volume which it is backing up. It doesn’t appear to recognise the fact that the volume name is
There is the remote possibility of a name clash here, which could produce unexpected results if you had a volume mounted which contained the same path, such as /Volumes/johnsmith/Documents or /Library/Application Support/Apple perhaps. The chances of this happening seem low, but I was surprised to see Time Machine checking all the paths in its list of exclusions against those on the Recovery volume, for example.