How to wipe metadata from block devices:

Reliably wiping all metadata from all block devices
that belong to a (possibly deeply) nested structure of block devices
is impossible in practice from within the running ReaR recovery system.

Reason:

After booting the ReaR recovery system a nested structure of block devices
is not visible regardless that it actually exists on the disk.

For an example see
https://github.com/rear/rear/pull/2514#issuecomment-726116193
that reads (excerpts):

On the original system the structure of block devices is:

# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME                                               KNAME     PKNAME    TRAN TYPE  FSTYPE       SIZE MOUNTPOINT
/dev/sda                                           /dev/sda            ata  disk                20G
|-/dev/sda1                                        /dev/sda1 /dev/sda       part                 8M
`-/dev/sda2                                        /dev/sda2 /dev/sda       part  crypto_LUKS   20G
  `-/dev/mapper/cr_ata-QEMU_HARDDISK_QM00001-part2 /dev/dm-0 /dev/sda2      crypt LVM2_member   20G
    |-/dev/mapper/system-swap                      /dev/dm-1 /dev/dm-0      lvm   swap           2G [SWAP]
    |-/dev/mapper/system-root                      /dev/dm-2 /dev/dm-0      lvm   btrfs       12.6G /
    `-/dev/mapper/system-home                      /dev/dm-3 /dev/dm-0      lvm   xfs          5.4G /home

That structure is recreated via an initial "rear recover" run on the replacement hardware
so that the same structure is now also on the disk of the replacement hardware.

But when booting the ReaR recovery system again on that replacement hardware
only this partial structure of the block devices is visible
(only the disk and partitions but no nested block devices inside the partitions):

RESCUE # lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME        KNAME     PKNAME   TRAN TYPE FSTYPE       SIZE MOUNTPOINT
/dev/sda    /dev/sda           ata  disk               20G
|-/dev/sda1 /dev/sda1 /dev/sda      part                8M
`-/dev/sda2 /dev/sda2 /dev/sda      part crypto_LUKS   20G

The reason why nested block devices are not visible is that /dev/sda2 is LUKS encrypted
so nothing what there is inside of /dev/sda2 could make any sense
for any program or tool that scans for nested block devices in /dev/sda2
unless /dev/sda2 gets unencrypted with "cryptsetup luksOpen":

RESCUE # cryptsetup luksOpen /dev/sda2 luks1sda2
Enter passphrase for /dev/sda2:
...

RESCUE # lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME                      KNAME     PKNAME    TRAN TYPE  FSTYPE       SIZE MOUNTPOINT
/dev/sda                  /dev/sda            ata  disk                20G
|-/dev/sda1               /dev/sda1 /dev/sda       part                 8M
`-/dev/sda2               /dev/sda2 /dev/sda       part  crypto_LUKS   20G
  `-/dev/mapper/luks1sda2 /dev/dm-0 /dev/sda2      crypt LVM2_member   20G

Now the LUKS volume symbolic link /dev/mapper/luks1sda2 that points to its matching
kernel block device /dev/dm-0 (with parent kernel block device /dev/sda2) is there
and the LVM storage objects that are inside the LUKS volume become visible:

RESCUE # pvscan
  PV /dev/mapper/luks1sda2   VG system          lvm2 [19.98 GiB / 0    free]
  Total: 1 [19.98 GiB] / in use: 1 [19.98 GiB] / in no VG: 0 [0   ]

RESCUE # vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "system" using metadata type lvm2

RESCUE # lvscan
  inactive          '/dev/system/swap' [2.00 GiB] inherit
  inactive          '/dev/system/home' [5.39 GiB] inherit
  inactive          '/dev/system/root' [12.59 GiB] inherit

The LVM logical volumes are inactive so they need to be activated with 'vgchange -ay'
which will create the symbolic links /dev/VGName/LVName (/dev/system/{swap|home|root})
pointing to matching kernel device nodes /dev/dm-{1|2|3} (all child devices of /dev/dm-0):

RESCUE # vgchange -ay
  3 logical volume(s) in volume group "system" now active

RESCUE # lsblk -bipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME                          KNAME     PKNAME    TRAN TYPE  FSTYPE             SIZE MOUNTPOINT
/dev/sda                      /dev/sda            ata  disk              21474836480
|-/dev/sda1                   /dev/sda1 /dev/sda       part                  8388608
`-/dev/sda2                   /dev/sda2 /dev/sda       part  crypto_LUKS 21465382400
  `-/dev/mapper/luks1sda2     /dev/dm-0 /dev/sda2      crypt LVM2_member 21463285248
    |-/dev/mapper/system-swap /dev/dm-1 /dev/dm-0      lvm   swap         2147483648
    |-/dev/mapper/system-home /dev/dm-2 /dev/dm-0      lvm   xfs          5792333824
    `-/dev/mapper/system-root /dev/dm-3 /dev/dm-0      lvm   btrfs       13518241792

So it is possible to make the whole structure of nested block devices visible and accessible.

But when there are LUKS encrypted block devices that contain nested block devices
the LUKS passphrase is mandatory to 'luksOpen' LUKS encrypted devices
to be able to wipe nested block devices inside LUKS volumes.

When "rear recover" is run on arbitrary replacement hardware it could happen
that there are LUKS encrypted block devices that contain nested block devices
but the LUKS passphrase is unknown by the admin at that point in time and
then it is impossible to wipe nested block devices inside LUKS volumes.

The usual tool to wipe signatures (i.e. metadata) from a device is wipefs.
But wipefs only wipes metadata that belongs to the specified device
and wipefs does not descend into nested child devices (wipefs has no "recursive" option).
Even if wipefs could descend into nested child devices it would not help
in the ReaR recovery system when deeper nested child devices cannot be made visible
(e.g. when there are nested block devices inside LUKS volumes with unknown LUKS passphrase).

So a more generic and more efficient method is needed
that also wipes metadata from nested block devices
even if the nested block devices are not visible.

The basic idea is to use 'dd' to zero out a sufficient amount of bytes (16 MiB - see at the bottom)
at the beginning and at the end of a block device to also wipe metadata
from deeper nested block devices even if they are not visible.

In the above example look at /dev/sda2 with its deeper nested block devices

`-/dev/sda2                                        /dev/sda2 /dev/sda       part  crypto_LUKS   20G
  `-/dev/mapper/cr_ata-QEMU_HARDDISK_QM00001-part2 /dev/dm-0 /dev/sda2      crypt LVM2_member   20G
    |-/dev/mapper/system-swap                      /dev/dm-1 /dev/dm-0      lvm   swap           2G [SWAP]
    |-/dev/mapper/system-root                      /dev/dm-2 /dev/dm-0      lvm   btrfs       12.6G /
    `-/dev/mapper/system-home                      /dev/dm-3 /dev/dm-0      lvm   xfs          5.4G /home

where in the ReaR recovery system only

`-/dev/sda2 /dev/sda2 /dev/sda      part crypto_LUKS   20G

is visible.

When 16 MiB are wiped at the beginning and at the end of /dev/sda2
it should also wipe the LVM metadata at the beginning and
at the end of /dev/mapper/cr_ata-QEMU_HARDDISK_QM00001-part2
and metadata at the beginning of the /dev/mapper/system-swap
and at the end of the /dev/mapper/system-home LVs.

What is still on the disk when 16 MiB were wiped at the beginning and end of /dev/sda2
is metadata at the end of /dev/mapper/system-swap and
at the beginning and end of /dev/mapper/system-root and
at the beginning of /dev/mapper/system-home
and as a consequence so that remaining metadata could get in the way
when recreating the /dev/mapper/system-swap and /dev/mapper/system-root
and /dev/mapper/system-home LVs.

So the only really reliably working way to wipe all metadata from all block devices
that could belong to a (possibly deeply) nested structure of block devices
is to prepare replacement hardware for disaster recovery in advance
which means in particular to completely zero out all replacement storage,
see the section "Prepare replacement hardware for disaster recovery" in
https://en.opensuse.org/SDB:Disaster_Recovery

But completely zeroing out storage space may take a long time on big disks
so this is not possible in practice during "rear recover" (where time matters)
when the replacement hardware is the original system hardware which is the case when
disaster recovery is done because of non-hardware-errors (e.g. corrupted file systems
or destroyed disk partitioning).

When the replacement hardware is the original system hardware
some best-effort attempt needs to be done to wipe as much metadata as possible
(with reasonable effort within a reasonable time) from all needed block devices.

Such a best-effort attempt is to use 'dd' to zero out 16 MiB (see at the bottom)
at the beginning and at the end of each block device that is visible from inside
the running ReaR recovery system and that will be actually used for disaster recovery.

Those block devices are the disks where in diskrestore.sh the create_disk_label function
is called (the create_disk_label function calls "parted -s $disk mklabel $label")
i.e. the disks that will be completely overwritten by "rear recover"
and all their child devices (in particular all partitions on those disks).

The following sections are about using 'dd' and how much metadata is stored
for LUKS, RAID, and LVM plus a summary how much data should be wiped
when there are nested RAID plus LVM plus LUKS block devices (which results 16 MiB).

=============================================================================================

'dd' from the end of the device

https://unix.stackexchange.com/questions/108858/seek-argument-in-command-dd
excerpts:
---------------------------------------------------------------------------------------------
you can see what dd does with strace

strace dd if=/dev/urandom bs=4096 seek=7 count=2 of=file_with_holes

It opens /dev/urandom for reading (if=/dev/urandom),
opens file_with_holes for create/write (of=file_with_holes).
Then it truncates file_with_holes to 4096*7=28672 bytes (bs=4096 seek=7).
The truncate means that file contents after that position are lost.
(Add conv=notrunc to avoid this step).
Then it seeks to 28672 bytes.
Then it reads 4096 bytes (bs=4096 used as ibs) from /dev/urandom,
writes 4096 bytes (bs=4096 used as obs) to file_with_holes,
followed by another read and write (count=2).
Then it closes /dev/urandom, closes file_with_holes, and prints that it copied 2*4096 = 8192 bytes.
Finally it exits without error (0).
---------------------------------------------------------------------------------------------

https://unix.stackexchange.com/questions/13848/wipe-last-1mb-of-a-hard-drive
excerpts:
---------------------------------------------------------------------------------------------
dd bs=512 if=/dev/zero of=/dev/sdx count=2048 seek=$((`blockdev --getsz /dev/sdx` - 2048))

Using the seek to get to the end of the drive works very well, i.e.:

    seek=$((blockdev --getsz /dev/sda - 2048))

However, when you use this, I recommend that you either know that your count value is correct,
or not use it at all. The reason I say this is that drives can have either 512 byte sectors
or 4k sectors, and if you use this solution with a drive that has 4k sectors on it,
you won't go to the end of the drive with that count value,
and may miss the RAID information at the end

/sys/block/sdx/queue/physical_block_size may give you the information
but some newer disks play fast and loose with the sector size they report.
It's probably better to read the label on the disk or look it up in the manufacturers data sheet.

The size of every partition is available in /proc/partitions.
The following command shows the size of sdx (in kB units):

awk '$4 == "sdx" {print $3}' </proc/partitions

Thus:

dd if=/dev/zero of=/dev/sdx bs=1k count=1024 \
   seek=$(($(awk '$4 == "sdx" {print $3}' </proc/partitions) - 1024))
---------------------------------------------------------------------------------------------

=============================================================================================

LUKS

man cryptsetup
excerpts:
---------------------------------------------------------------------------------------------
  --align-payload <number of 512 byte sectors>
  Align payload at a boundary of value 512-byte sectors.
  This option is relevant for luksFormat.
  If not specified, cryptsetup tries to use the topology info provided by the kernel
  for the underlying device to get the optimal alignment.
  If not available (or the calculated value is a multiple of the default)
  data is by default aligned to a 1MiB boundary (i.e. 2048 512-byte sectors).

  --header <device or file storing the LUKS header>
  ...
  For luksFormat with a file name as the argument to --header,
  the file will be automatically created if it does not  exist.
  See the cryptsetup FAQ for header size calculation.

  The cryptsetup FAQ, contained in the distribution package and online at
  https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions

---------------------------------------------------------------------------------------------

https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
excerpts:
---------------------------------------------------------------------------------------------

6.12 What does the on-disk structure of LUKS1 look like?

Note: For LUKS2, refer to the LUKS2 document referenced in Item 1.2
[ https://gitlab.com/cryptsetup/LUKS2-docs that leads to
  https://gitlab.com/cryptsetup/LUKS2-docs/blob/master/luks2_doc_wip.pdf ]

A LUKS1 partition consists of a header, followed by 8 key-slot descriptors,
followed by 8 key slots, followed by the encrypted data area.

Header and key-slot descriptors fill the first 592 bytes.
...
Due to 2MiB default alignment, start of the data area for cryptsetup 1.3 and later is at 2MiB, i.e. at 0x200000.
For older versions, it is at 0x101000, i.e. at 1'052'672 bytes, i.e. at 1MiB + 4096 bytes from the start of the partition.

---------------------------------------------------------------------------------------------

https://gitlab.com/cryptsetup/LUKS2-docs/blob/master/luks2_doc_wip.pdf
excerpts:
---------------------------------------------------------------------------------------------
2 LUKS2 On-Disk Format

The LUKS2 header is located at the beginning (sector 0) of the block device

The LUKS2 header contains three logical areas:
* binary structured header (one 4096-byte sector, only 512-bytes are used),
* area for metadata stored in the JSON format and
* keyslot area (keyslots binary data).
The binary and JSON areas are stored twice on the device (primary and secondary header)
and under normal circumstances contain same functional metadata.
The binary header size ensures that the binary header is always written to only one sector (atomic write).
Binary data in the keyslots area is allocated on-demand. There is no redundancy in the binary keyslots area
...
To allow for an easy recovery, the secondary header must start at a fixed offset listed in Table 1.
 Offset            JSON area
[bytes]     (hexa)      [kB]
  16384 (0x004000)       12
  32768 (0x008000)       28
  65536 (0x010000)       60
 131072 (0x020000)      124
 262144 (0x040000)      252
 524288 (0x080000)      508
1048576 (0x100000)     1020
2097152 (0x200000)     2044
4194304 (0x400000)     4092
Table 1:  Possible LUKS2 secondary header offsets and JSON area size.
...
The JSON area starts immediately after the binary header
(end of JSON area must be aligned to 4096-byte sector offset)
---------------------------------------------------------------------------------------------

So a LUKS 2 header can be at most 4194304 bytes = 4 MiB
because the secondary header starts at least at offset 4194304
so a whole LUKS 2 header (primary plus secondary) can be at most 2 * 4194304 bytes = 8 MiB.

Summary:

To wipe a LUKS1 header is should be sufficient to wipe 2 MiB at the beginning of the device.

To wipe a LUKS2 header is should be sufficient to wipe 8 MiB at the beginning of the device.

=============================================================================================

RAID

From
https://raid.wiki.kernel.org/index.php/RAID_superblock_formats#A_Note_about_kernel_autodetection_of_different_superblock_formats
excerpts:

---------------------------------------------------------------------------------------------
The version-0.90 Superblock Format

The superblock is 4K long and is written into a 64K aligned block
that starts at least 64K and less than 128K from the end of the device
(i.e. to get the address of the superblock round the size of the device
 down to a multiple of 64K and then subtract 64K).
The available size of each device is the amount of space before the super block,
so between 64K and 128K is lost when a device in incorporated into an MD array.

The version-1 Superblock Format

The version-1 superblock is capable of supporting arrays with 384+ component devices,
and supports arrays with 64-bit sector lengths.

Note: Current version-1 superblocks use an unsigned 32-bit number for the dev_number
but only index the dev_numbers using an array of unsigned 16-bit numbers
(so the theoretical range of device numbers in a single array is 0x0000 - 0xFFFD),
which allows for 65,534 devices.

The "version-1" superblock format is currently used in three different "sub-versions".

Sub-Version  Superblock Position on Device
0.9          At the end of the device
1.0          At the end of the device
1.1          At the beginning of the device
1.2          4K from the beginning of the device

The version-1 superblock format on-disk layout
Total Size of superblock
Total Size of superblock: 256 Bytes, plus 2 bytes per device in the array
---------------------------------------------------------------------------------------------

Summary:

Version-0.90 Superblock is at most 128K from the end of the device.

Version-1 Superblock is at most 256 Bytes + ( 2 bytes * 65534 devices ) = 131324 bytes = 128.24609375 KiB
additionally possibly plus 4K from the beginning of the device = 129 KiB + 4 KiB = 133 KiB

Result:

To wipe RAID Superblocks it is sufficient to wipe at least 133 KiB at the beginning and at the end of the device.

https://www.systutorials.com/how-to-clean-raid-signatures-on-linux/
excerpts:
---------------------------------------------------------------------------------------------
Show RAID devices

Show the RAID devices by

# dmraid -r

It will show the results like

/dev/sdb: ddf1, ".ddf1_disks", GROUP, ok, 3904294912 sectors, data@ 0

You may find the device at:

# ls /dev/mapper/ddf*

Remove RAID device

Here, there are many methods.
I show the most easier one to the most hard one.
The example here shows that all except the last dd method failed.

Use dmsetup

Trying directly by dmsetup may fail like:

# dmsetup remove /dev/mapper/ddfs1_...

The result:

device-mapper: remove ioctl on ddf1_49424d202020202010000073101403b141c2c9e96c8236dbp1 failed: Device or resource busy
Command failed

We may try the dmraid tool. Assume the disk is /dev/sdb:

DEVICE=/dev/sdb

Remove RAID status by dmraid:

# dmraid -r -E $DEVICE

In this example, it still failed showing errors as follows.

Do you really want to erase "ddf1" ondisk metadata on /dev/sdb ? [y/n] :y

ERROR: ddf1: seeking device "/dev/sdb" to 1024204253954048
ERROR: writing metadata to /dev/sdb, offset 2000398933504 sectors, size 0 bytes returned 0
ERROR: erasing ondisk metadata on /dev/sdb

If all failed, you may try the powerful dd:

# dd if=/dev/zero of=$DEVICE bs=512 seek=$(( $(blockdev --getsz $DEVICE) - 1024 )) count=1024

1024+0 records in
1024+0 records out
524288 bytes (524 kB) copied, 0.00216637 s, 242 MB/s

Check the RAID devices again by

dmraid -r

Now it shows:

no raid disks

Now the RAID signature on the disk is successfully cleaned.
---------------------------------------------------------------------------------------------

=============================================================================================

LVM

https://unix.stackexchange.com/questions/185057/where-does-lvm-store-its-configuration
excerpts:
---------------------------------------------------------------------------------------------

I am not aware of a command that you can use to view the metadata,
but the command vgcfgbackup can be used to backup the metadata
and you can open a backup file thus created to view the metadata

vgcfgbackup -f /path/of/your/choice/file <your_vg_name>

The /path/of/your/choice/file created by the above command will contain
the PV, VG and LVM metadata. One of the sections will look like below:

physical_volumes {

                pv0 {
                        id = "abCDe-TuvwX-DEfgh-daEb-Xys-6Efcgh-LkmNo"
                        device = "/dev/sdc1"    # Hint only

                        status = ["ALLOCATABLE"]
                        flags = []
                        dev_size = 10477194     # 4.99592 Gigabytes
                        pe_start = 2048
                        pe_count = 1278 # 4.99219 Gigabytes
                }
        }
---------------------------------------------------------------------------------------------

In the above example
the size unit for dev_size is 512 bytes
because 10477194 * 512 / 1024 / 1024 / 1024 = 4.99591541290283203125
and
the size unit for pe_count is the extent_size which is 4 MiB
because 1278 * 4 * 1024 * 1024 / 1024 / 1024 / 1024 = 4.99218750000000000000

Unallocated bytes:
dev_size in bytes = 10477194 * 512 = 5364323328
allocated (pe_count) bytes = 1278 * 4 * 1024 * 1024 = 5360320512
so that unallocated bytes = 5364323328 - 5360320512 = 4002816 = 3.8173828125 MiB

Cf.
https://github.com/libyal/libvslvm/blob/master/documentation/Logical%20Volume%20Manager%20(LVM)%20format.asciidoc
excerpts:
---------------------------------------------------------------------------------------------
extent_size
The size of an extent
The value contains the number of sectors
Note that the sector size is currently assumed to be 512 bytes.

...

dev_size
The physical volume size including non-usable space
The value contains the number of sectors
Note that the sector size is currently assumed to be 512 bytes.

pe_start
The start extent
TODO: what is this value used for?

pe_count
The number of (allocated) extents in the physical volume

...

myvg {
  id = "0zd3UT-wbYT-lDHq-lMPs-EjoE-0o18-wL28X4"
  seqno = 3
  status = ["RESIZEABLE", "READ", "WRITE"]
  extent_size = 8192    # 4 Megabytes
  max_lv = 0
  max_pv = 0

  physical_volumes {

    pv0 {
      id = "ZBW5qW-dXF2-0bGw-ZCad-2RlV-phwu-1c1RFt"
      device = "/dev/sda"   # Hint only

      status = ["ALLOCATABLE"]
      dev_size = 35964301   # 17.1491 Gigabytes
      pe_start = 384
      pe_count = 4390 # 17.1484 Gigabytes
    }
---------------------------------------------------------------------------------------------

In this example
dev_size in bytes = 35964301 * 512 bytes = 18413722112 bytes =
                  = 18413722112 / 1024 / 1024 / 1024 GiB = 17.14911508560180664062 GiB
allocated bytes = 4390 * 8192 * 512 bytes = 18412994560 bytes =
                = 18412994560 / 1024 / 1024 / 1024 GiB = 17.14843750000000000000 GiB
unallocated bytes = 18413722112 bytes - 18412994560 bytes = 727552 bytes =
                  = 727552 / 1024 / 1024 MiB = 0.69384765625 MiB

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/logical_volume_manager_administration/lvm_metadata
excerpts:
---------------------------------------------------------------------------------------------
By default, an identical copy of the metadata is maintained
in every metadata area in every physical volume within the volume group.
LVM volume group metadata is stored as ASCII.
---------------------------------------------------------------------------------------------

https://grox.net/sysadm/unix/nuke.lvm
excerpts:
---------------------------------------------------------------------------------------------
#! /bin/bash

# dom0 is on sd{a,b}. ignore 'em.
# disks not done by the installer:
dom1db=/dev/sdc
dom1data=/dev/sdd
dom2db=/dev/sde
dom2data=/dev/sdf
disks="$dom1db $dom1data $dom2db $dom2data"

# remove existings lvm configs
echo "clearing LVM on: $disks ..."
for _vol in `lvdisplay | awk '/LV Name.*domu/{print $3}'`
do
  umount -f $_vol >/dev/null 2>/dev/null
  lvchange -an $_vol
  lvremove -f $_vol
done

for _vol in `vgdisplay | awk '/VG Name.*domu/{print $3}'`
do
  vgchange -an $_vol
  vgremove -f $_vol
done

# last step didn't get 'em all...
for _vol in /dev/mapper/domu*
do
  dd if=/dev/zero of=$_vol bs=512 count=12
done

for _pv in `pvdisplay | awk '/PV Name.*dev.sd[c-f]/{print $3}'`
do
  pvremove -ff $_pv
done

# just in case some were missed... (some always are)
for _pv in $disks
do
  pvremove -ff $_pv
  dd if=/dev/zero of=$_pv bs=512 count=255
done

# see what else the system still knows about
# and get rid of them, too.
# note that we ignore 'sd*' partitions and that this
# assumes that we don't need dm-? for the system
# that we're running on. i know, big assumption.
#
for _part in `awk '/dm-/{print $4}' /proc/partitions`
do
  pvremove -ff $_part
  dd if=/dev/zero of=$_part bs=512 count=255
done

# okay. now we should have clean disk partitions to use.
---------------------------------------------------------------------------------------------

man pvcreate
excerpts:
---------------------------------------------------------------------------------------------
  --[pv]metadatacopies 0|1|2
  The number of metadata areas to set aside on a PV for storing VG metadata.
  When 2, one copy of the VG metadata is stored at the front of the PV
  and a second copy is stored at the end.
  When 1, one copy of the VG metadata is stored at the front of the PV
  (starting in the 5th sector).
  When 0, no copies of the VG metadata are stored on the given PV.
---------------------------------------------------------------------------------------------

In the two above examples the unallocated bytes are 3.8173828125 MiB and 0.69384765625 MiB
so it seems
to wipe a LVM metadata is should be sufficient to wipe 4 MiB
at the beginning and at the end of the device.

=============================================================================================

RAID plus LVM plus LUKS

To wipe RAID Superblocks it is sufficient to wipe 133 KiB at the beginning and at the end of the device.

To wipe LVM metadata is should be sufficient to wipe 4 MiB at the beginning and at the end of the device.

To wipe LUKS headers is should be sufficient to wipe 8 MiB at the beginning of the device.

To wipe RAID superblocks plus LVM metadata plus LUKS headers it should be sufficient to
wipe 8 MiB + 4 MiB + 1 MiB = 13 MiB at the beginning of the device and to
wipe 4 MiB + 1 MiB = 5 MiB at the end of the device.

To be future proof (perhaps LUKS may add a backup header at the end of the device)
wiping 16 MiB at the beginning and at the end of the device should be sufficiently safe.
