Inspect LVM Physical Volume Metadata Safely with pvck

You will use pvck to inspect an LVM physical volume (PV), save metadata to files, and decide whether a damaged header has enough evidence for a later repair. The normal workflow is read-only. Repair commands are deliberately kept outside the routine inspection steps because they write to the PV and can make recovery harder.

The route

Jump straight to the step you need, or tick off Done means at the end.

Before you touch the PV
Check the installed version and basic metadata
Print and check the on-disk headers
Extract the current metadata
Search when headers do not locate metadata
Keep repair as a separate decision

This guide targets the installed lvm2 2.03.16(2) release, dated 2022-05-18. Allow about 10 minutes for an inspection, plus the time needed to identify the correct device and preserve its output. You need the pvck command, a root shell or equivalent device-read access, a writable evidence directory, and a maintenance plan if the PV belongs to an active volume group.

Before you touch the PV

Identify the exact device path. Use lsblk, your inventory, and the LVM records to distinguish the PV from a partition, RAID member, or whole disk.

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
sudo pvs -o pv_name,pv_uuid,vg_name,pv_size,pv_free

The final argument to pvck is a device under /dev. Replace /dev/REPLACE_ME in the examples; do not paste a guess. A wrong device can produce plausible-looking output and send your investigation in the wrong direction.

Checkpoint

Write down the device path, PV UUID, volume group, and the reason for the inspection. Stop if the device is a live member of a critical array and you do not have an agreed maintenance window. Inspection reads metadata, but other LVM activity can still change what you observe.

Check the installed version and basic metadata

Confirm the binary version and ask pvck to check the device.

pvck --version
sudo pvck /dev/REPLACE_ME

The version output identifies the implementation whose behaviour you are using. A plain device argument performs the basic PV check. Treat warnings as evidence to investigate, not as permission to repair immediately. Save the terminal output in your incident notes, including the command and timestamp.

If the command cannot see the device, check permissions, device visibility restrictions, and whether the path is the actual PV. The --devices option can restrict the devices visible to LVM, while --devicesfile selects an LVM devices file under /etc/lvm/devices. Do not add --nolocking just to silence a problem: the manual warns that concurrent commands can produce incorrect results when locking is disabled.

Print and check the on-disk headers

Run the header dump and redirect its output to a new evidence file.

sudo pvck --dump headers /dev/REPLACE_ME \
  | tee /tmp/pvck-REPLACE_ME-headers.txt

The headers dump checks and prints the LVM label header, PV header, metadata area header, and related metadata information. The first label and PV headers normally share the second 512-byte sector. The first metadata area header is normally at byte offset 4096. These are useful landmarks when comparing output with a known-good PV, but do not assume every PV has a second metadata area.

Checkpoint

Confirm that the output names the intended device and record any warnings before continuing. The file under /tmp is temporary evidence. Move it to your protected incident directory only after checking its contents and permissions.

Extract the current metadata

Save the latest metadata text to a file rather than relying on terminal scrollback.

install -d -m 700 /tmp/pvck-evidence
sudo pvck --dump metadata \
  --file /tmp/pvck-evidence/REPLACE_ME-current.txt \
  /dev/REPLACE_ME
sudo sed -n '1,80p' /tmp/pvck-evidence/REPLACE_ME-current.txt

metadata uses the headers to locate the current volume group metadata. The file contains the LVM text description, so protect it like infrastructure inventory: it can reveal volume names, paths, and layout. This operation does not change the PV.

If the headers are damaged, the current copy may not be found. If the PV has a second metadata area, ask for it explicitly:

sudo pvck --dump metadata \
  --settings "mda_num=2" \
  --file /tmp/pvck-evidence/REPLACE_ME-mda2-current.txt \
  /dev/REPLACE_ME

The default is mda_num=1. The second area, called mda2, is commonly at the end of the device and is not created by default. A successful command with mda2 is useful recovery evidence, but it does not prove that the primary header is safe.

Search when headers do not locate metadata

Search standard metadata locations and list every version that can still be found.

sudo pvck --dump metadata_search \
  /dev/REPLACE_ME \
  | tee /tmp/pvck-evidence/REPLACE_ME-search.txt

metadata_search is the recovery-oriented read-only mode. It searches common locations instead of trusting only the normal headers. Add -v when you need descriptions and dates in the list:

sudo pvck -v --dump metadata_search /dev/REPLACE_ME

When the listing provides a metadata offset, you can save one specific version by supplying that byte offset. Offsets and sizes in --settings are bytes; units such as MiB are not accepted there.

sudo pvck --dump metadata_search \
  --settings "metadata_offset=OFFSET_FROM_OUTPUT" \
  --file /tmp/pvck-evidence/REPLACE_ME-selected.txt \
  /dev/REPLACE_ME

Replace OFFSET_FROM_OUTPUT with a numeric offset copied from the search result. Do not estimate it. If you need the unprocessed metadata area for specialist analysis, the manpage also documents --dump metadata_area with --file; preserve that larger file before attempting interpretation.

Keep repair as a separate decision

Warning

--repair writes headers and metadata to the PV. It requires metadata extracted by pvck or a backup under /etc/lvm/backup. A repair can use the wrong PV UUID if device names have changed, especially when more than one PV in the same volume group is damaged.

Before any repair, obtain a complete block-level backup or an approved recovery plan, stop competing LVM operations, verify the PV UUID against independent records, and compare the proposed metadata with the volume group's intended layout. The documented repair sequence is a PV header repair followed by a metadata repair. --repairtype metadata requires correct headers, so running it first is not a safe shortcut.

The --test option disables metadata writing, but the manpage warns that multi-stage operations can still produce unusual messages because later stages may expect changes that were not made. Treat test mode as an extra diagnostic aid, not as a substitute for backups or review.

Done means

You identified the PV path and recorded its UUID and volume group.
pvck --version was recorded with the inspection results.
You saved the header check and, where possible, current or searched metadata.
You checked mda2 only when a second metadata area is plausible.
You did not run a repair without independent recovery evidence and an approved change window.