When and why vgs command can change metadata and incur old metadata to be backed up?

I asked:

Sometimes, I see the following message in the VG metadata backups under /etc/lvm/archive:
"""
contents = "Text Format Volume Group"
version = 1
description = "Created before executing 'vgs'"
"""
I'm wondering when and why the new backups will be created by reporting command like vgs?

David:

It's probably a case where lvm sees something wrong after reading the VG metadata, and automatically tries to fix it, writing a corrected version of the metadata to disk. This means that even a command that only reads and reports lvm information can potentially write to disk.

Right now it's hard to identify the precise instances and locations of these repairs. But, I am in the middle of reworking the VG reading code with the goal of consolidating and clarifying all the cases of repair, at which point we can improve the way we handle this. I think we want to try to make these repairs more limited and controlled, especially for commands that in theory are only reading and reporting information. I've also suggested that whenever repairs are done, lvm should record a persistent message in the system log with the details, but that idea didn't get a great reception.

Alasdair:

Very simply if the metadata the command has just read in does not match the last backup stored in the local filesystem and the process is able and configured to write a new backup.

The command that made the metadata change might not have written a backup if it crashed, was configured not to write backups, was running with the filesystem readonly (e.g. booted into a recovery mode), ran on a different node in a cluster, ran as part of an installer that chose not to give you any metadata backups, performed metadata recovery etc. (Plus an old release had a bug where the checking went wrong and it made a backup every time even though nothing had actually changed.)