This problem surfaced while trying to solve another problem. Let me explain.
I have an existing LVM consisting of 4 disks. Suddenly 2 disks failed with I/O errors, making the superblock unreadable (filesystem = XFS). I purchased 2 new disks, intending to replace the failing disks by making copies via ddrescue. I wanted to add the 2 new disks to my VG, then run vgcfgbackup and vgcfgrestore in order to regain a working (though still half empty) VG. After copying the falings disks onto the new ones I should be back in business.
However, I goofed by adding the 2 new disks twice. Now I have a VG consisting of 6 PV's (2 original ones that are still OK sdf1 and sdg1, 2 new disks sdi1 and sdj1, and 2 fake disks). I tried to remove both fake disks but pvremove will not let me do it.
I am absolutely certain that both uuid's that are now reported as missing, are empty. How can I get rid of them, so that I can reconvene my restore?
Here's some output:

You don't need to call pvremove on a missing volume. pvremove wipes the PV label on an existing volume. You already wiped the first labels by doing pvcreate a second time. If you added the fake PVs to your volume group, then you need to reduce the volume group using vgreduce.

The warning for PVs not found is due to the cached copy of your metadata. Running "pvscan --cache" should refresh it.

That made a lot of sense but it only worsened the situation:

The 2 new disks /dev/sdi and /dev/sdj were correctly registered before the cache was cleared. They correctly mirrorred the UUID's of both disks that had gone bad. After clearing the cache these new disks suddenly got wrong UUID's, i.e. of /dev/sde1 and /dev/sdf1, which are the other 2 original disks, the disks having no problems. Can I at least go back to the situation before the cache clearance? As the original post demonstrates, I then had 4 correctly registered PVs (plus 2 fakes).
Note: vgreduce will not work untill the metadata are corrected.

I tried to restore the metadata from backup, but that failed as well.
I'm pretty sure the backup at /etc/lvm/backup/AV is exactly right:

But I can't restore this file. The 2 new devices /dev/sdi and /dev/sdj seem to have lost their LVM info. I tried to pvcreate these devices again but that failed. How do I correctly restore the backup file?

First I think you need to figure out what caused the duplicate uuid message. Do you have multiple paths to the drives? Did you not remove the failed drives after ddrescue? Or is it possible the wrong drives were copied?

Check for multiple paths with: multipath -ll

Check the list of all drives with: lsblk -a

Thank you. I do not use multipath. lsblk shows exactly correct info:

I was thinking of entirely removing the VG, rebuild it and restore the last backup file. Would that be safe, i.e. preserve all data?
Something like:

vgremove --force AV
pvcreate --uuid 8C8y2a-GXmN-tPNx-Jha2-Rea1-cqav-AfyfNm /dev/sdi1
pvcreate --uuid JTdK18-uuaq-8U4t-RQ2I-etKd-jUF5-03xIjk /dev/sdj1
pvscan (to check if all 4 devices are there)
vgcfgrestore --file <last backup file> AV

Could this help resolve the problem?

If you need to preserve your data then my best advice is don't do anything to those disks except copy them to new disks and test recovery on those.

I understand, but I would still face the same problem as the metadata would still be mixed up. LVM doesn't let me use any LVM command before this is rectified, and it won't even let me rectify. I really need to do something more definitive with the metadata.
I do have the correct number of devices connected as lsblk shows, and I do have a correct lvm config file that worked in the beginning. Isn't there a way to get rid of all caches etc (LVM won't let me run pvscan --cache) and just use the bare config file that used to work before LVM mixed it all up? Thanks for trying to help me out.

In case you did not know, those files in /etc/lvm/archive and /etc/lvm/backup are exactly that, archive and backup. They are not controlling. The entire state of the volume group is recorded on each PV in the volume group in its LVM header. The file in /etc/lvm/backup is just a formatted and commented version of the ASCII text that begins in the 9th 512-byte sector of that header.

It's not clear just how you got into your current state, but you can unconditionally clear all your LVM headers by running "dd if=/dev/zero bs=1k count=10 of=/dev/{xxxx}" on each of your physical volumes. You will then need to restore those PVs by running pvcreate with the "--uuid" and "--restorefile" options using your known good configuration file as the data source. That should get you into a state where you can do a successful vgcfgrestore.

1 members found this post helpful.

Many thanks for the explanation. This clarified my situation and led me to successfully solve the problem.

I was hoping that the "wipe" option of (newer) fdisk would erase the LVM meta-data, but a quick test proved disappointing, so we'll have to keep using dd for the foreseeable future.