Every save to OneDrive, SharePoint or Google Drive adds a state to the file's history, so the history grows by itself while people work. In the Microsoft 365 apps it sits under File, Version History; in OneDrive on the web it is a right-click away; in a SharePoint library it appears in the item's menu. Restoring there is non-destructive: SharePoint keeps the version being replaced and makes a copy of the chosen one the newest version. How many versions a library keeps is set in the library's versioning settings, and Microsoft notes that a personal OneDrive account can go back through the last twenty-five.
Named versions and what Google adds
Google Docs, Sheets and Slides open the history from the last-edit note at the top of the file, and browsing earlier versions requires edit access. The feature worth using on purpose is naming: a named version is kept distinct rather than merged with nearby edits, the history can be filtered to show only named ones, and Google allows up to forty per document. Naming the state that went to the board or the regulator turns a long list of timestamps into a record someone can find a year later.
History pairs naturally with co-authoring, because it makes a colleague's mistaken deletion recoverable, and it complements track changes, which records proposals awaiting a decision rather than saved states. Developers will recognise the idea from Git, though a document's history is linear and automatic where a repository's is deliberate and branched. The collaboration and meetings topic covers the shared-file habits it belongs to.
Not a backup
History lives inside the same service as the file. The service's retention settings, not the user, decide how far back it reaches, so anything that must survive for years needs a deliberate copy or a named version kept under a retention rule the organisation controls.