Inspect LVM Physical Volume Metadata Safely with pvck

pvck reads the headers of a damaged LVM physical volume without writing anything back. This guide walks the read-only inspection: how to save metadata to files, and how to decide whether a damaged header has enough evidence for a later repair. Repair commands are deliberately kept out of the routine steps, because they write to the PV and can make recovery harder.

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

1. Identify the exact device path. Use lsblk, your inventory, and the LVM records to tell the PV apart 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.

Check the installed version and basic metadata

1. 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 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 actually the PV. --devices 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

1. 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, and the first metadata area header is normally at byte offset 4096. Useful landmarks for comparing against a known-good PV, but do not assume every PV has a second metadata area.

Extract the current metadata

1. 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 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 against mda2 is useful recovery evidence, but it does not prove the primary header is safe.

Search when headers do not locate metadata

1. 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 gives you 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

• Get a complete block-level backup or an approved recovery plan first.
• Stop competing LVM operations before repairing anything.
• Verify the PV UUID against independent records.
• 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 a substitute for backups or review.

Done means

• Device identified. You identified the PV path and recorded its UUID and volume group.
• Version recorded. pvck --version was noted alongside the inspection results.
• Evidence saved. You saved the header check and, where possible, current or searched metadata.
• Second area checked only when plausible. You checked mda2 only when a second metadata area made sense.
• Repair held back. You did not run a repair without independent recovery evidence and an approved change window.