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.)