Code with Abrar

Backup using deduplicating engine

Ext4 vs LVM — Two very different layers

Layer What it does Typical commands Snapshot capability
ext4 (filesystem) Puts a directory/file structure on a single block device or partition. fsck.ext4, tune2fs None (needs LVM or other block-level snapshot under it)
LVM (Logical Volume Manager, block-device layer) Pools one-or-more disks/partitions into flexible “Volume Groups”, then carves out “Logical Volumes” that look like ordinary disks to a filesystem. pvcreate, vgcreate, lvcreate, lvs Yes: lvcreate -s makes instantaneous, copy-on-write snapshots

Think of it this way:

┌────────────────────────┐
│  ext4 filesystem       │   <-- you mount this ( /, /home … )
└──────────▲─────────────┘
           │ logical volume
┌──────────┴─────────────┐
│  LVM (device-mapper)   │   <-- lets you resize, add disks, snapshot
└──────────▲─────────────┘
           │ partition or whole disk
┌──────────┴─────────────┐
│  SD card / SSD / HDD   │
└────────────────────────┘

So what is your Raspberry Pi actually using?

On the official Ubuntu 24.04 for Raspberry Pi image, the installer keeps things simple:

/dev/mmcblk0p1   vfat   (boot/EFI)
/dev/mmcblk0p2   ext4   (root filesystem)

No LVM by default, so ext4 sits directly on the SD-card partition. You can confirm:

lsblk -f
# TYPE column shows "part" and "ext4" — you won't see "lvm"

or

sudo vgdisplay        # “command not found” or “0 VGs” → no LVM

Why I mentioned LVM snapshots for backups

Tools like restic are perfectly happy to back up a live ext4 filesystem, but if a file is being written during the run you can end up with a half-written copy. Using an LVM snapshot (or Btrfs/ZFS snapshot) solves that elegantly:

  1. Snapshot created in milliseconds → freezes a point-in-time view
  2. Backup tool reads from the snapshot while the real server keeps writing
  3. Snapshot is deleted when the backup ends

If you don’t have LVM, you still get a reliable backup most of the time—just be aware that a busy database or VM image might need its own dump/hot-backup first.

Options if you do want LVM on a Pi

Scenario How to get there
Fresh install When flashing the next Ubuntu image, drop to the server installer’s advanced storage screen → pick “Use LVM with the new Ubuntu installation”.
Add a second drive (USB/SATA SSD) Leave the SD card as-is for /boot, create an LVM Volume Group on the SSD, move / or data directories there, then enable snapshots only on that drive.
Convert an existing ext4 root in-place Not really supported. Easiest path is backup → reinstall with LVM → restore, or rsync the running system onto a new LVM LV on an external drive and switch cmdline.txt/fstab to boot from it.

Performance-wise, LVM adds < 1 % overhead—fine on a Pi 4/5 with an SSD. On an SD card, the bigger question is wear-levelling rather than speed, so snapshots are best kept short-lived.

TL;DR

  • ext4 is your filesystem; LVM is an optional layer underneath that gives you snapshots, easy resizing and disk pooling.
  • Your stock Ubuntu 24.04 Pi image is plain ext4, no LVM.
  • Restic works either way, but an LVM (or Btrfs/ZFS) snapshot makes truly crash-consistent backups effortless.
  • If you like that convenience, reinstall with “Use LVM” or put your data on an LVM-formatted external SSD and snapshot there.