This page documents the preferred future storage layout for the Arch Linux workstation and the agreed backup strategy using local snapshots, NAS backups, and monthly raw images.
| Layer | Recommended Choice |
|---|---|
| Boot | EFI partition |
| Encryption | LUKS optional but recommended |
| Filesystem | btrfs directly on the main partition |
| Local rollback | snapper snapshots |
| NAS backups | borg to Unraid XFS storage |
| Disaster recovery | monthly raw image backup |
nvme0n1p1 EFI
nvme0n1p2 LUKS optional
-> btrfs
-> @
-> @home
-> @var_log
-> @pkg
-> @snapshots
The current system layout used:
btrfs on top of that LVThis layout is valid and common.
However, if the system only uses one big LV for one btrfs filesystem, LVM does not add much value. It adds another abstraction layer without delivering many benefits that matter in this case.
LVM is useful when it provides actual volume-management value, for example:
If the layout is just:
btrfs filesystemthen btrfs is doing almost all the interesting work and LVM mostly just adds indirection.
EFI -> LUKS -> btrfs -> subvolumes
The agreed design uses multiple layers because one backup technology alone is not enough.
Purpose:
Important limitation:
Suggested tool:
snapperPurpose:
Because the Unraid NAS target storage is XFS, btrfs send/receive is not the right method for the NAS layer.
Instead, use a content-aware backup tool that works well on normal filesystems.
Suggested tool:
borgborg is a strong fit here because it already fits the existing familiarity and works well with an XFS target.
This backup can run while the OS is live.
It should back up the important system and user paths, not volatile runtime directories.
Purpose:
partclone.btrfs problemImportant rule:
partclone.btrfsRaw backups are slower and larger, but they are intentionally dumb and therefore safer against metadata misinterpretation.
btrfs snapshotsborgNo separate weekly "full" is strictly necessary if using borg, because it already maintains versioned incremental history internally.
The weekly layer can instead be represented by retention policy and verification.
borg gives real off-machine history, and raw images cover bare-metal disaster recovery.
A reasonable starting point:
Keep at least:
Typical paths to include in borg backups:
/etc/home/root/usr/local/var/libTypical paths to exclude:
/dev/proc/sys/run/tmp/mnt/mediaThe exact include/exclude list should be tuned to the machine.
This is a full operating system recovery path, but not a byte-for-byte disk clone.
Typical emergency recovery would be:
btrfs filesystemfstabThis is the simpler disaster restore path.
Typical process:
This is why the monthly raw image remains valuable even when borg already exists.
EFI + LUKS + btrfs if desiredbtrfs snapshots for convenienceborg to Unraid XFS storage for regular real backupsThis gives a system that is both practical and resilient.