Snapshots de LVM: qué son y cómo usarlos en Linux

agosto 3, 2026 Alfonso Moreno | Sysadmin Senior 124 Visitas 15 min de lectura

Los snapshots de LVM son la respuesta de Linux a “Time Machine” de Apple: una vista de tu filesystem en un momento dado. Son útiles para backups consistentes y rollback rápido, pero tienen limitaciones importantes que mucha gente descubre cuando ya perdió datos. Esta guía te dice qué son, cuándo usarlos, y cuándo NO.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Qué es LVM (rapidito)

LVM (Logical Volume Manager) es un sistema de gestión de almacenamiento que pone una capa de abstracción entre tus discos y tus particiones:

Physical Volumes (PV): discos o particiones reales (/dev/sda1, /dev/nvme0n1).
Volume Groups (VG): pool de uno o más PVs.
Logical Volumes (LV): las “particiones” que el sistema ve (/dev/vg0/root).
Filesystem: encima del LV va ext4, xfs, btrfs, etc.

La ventaja principal: puedes redimensionar LVs, mover datos entre discos, y crear snapshots sin desmontar.

Qué es un snapshot de LVM

Un snapshot es un LV especial que apunta a un LV “origen” y guarda solo los bloques que cambiaron desde que se creó. Es copy-on-write:

Crear snapshot: instantáneo, casi sin costo de espacio.
Cambios en origen: el bloque original se copia al snapshot antes de modificarse.
Lectura del snapshot: ve los bloques originales + los bloques copiados = estado al momento de crear el snapshot.

Tipos:

Snapshot clásico (thick): reserva espacio en disco para los cambios. Típicamente 15-20% del tamaño del LV origen.
Thin snapshot: no reserva, usa un pool thin. Más flexible pero requiere setup previo.

Crear tu primer snapshot

Asumimos que tienes /dev/vg0/root como LV origen.

Antes de crear nada, inspeccioná el estado actual del VG: lvs te muestra atributos del LV origen (la columna Attr tiene que incluir o, “open”, si está montado y en uso) y vgs te dice cuánto espacio libre queda en el Volume Group, dato crítico porque el snapshot clásico reserva espacio ahi mismo. Sin espacio libre en el VG, lvcreate falla con Insufficient free space.

# Ver info del LV
lvs
# LV   VG   Attr       LSize
# root vg0  -wi-ao---- 50.00g
# Ver espacio libre en el VG
vgs
# VG   #PV #LV #SN Attr   VSize   VFree
# vg0    1   1   0  wz--n- 100.00g 50.00g
# Crear snapshot con 10 GB de espacio para cambios
lvcreate -L 10G -s -n root-snapshot /dev/vg0/root
# Logical volume "root-snapshot" created.

Si lvs muestra tu LV origen sin la flag o (por ejemplo wi-a-----), el LV no está activo y lvcreate -s va a fallar con LV is not active. activa el origen con lvchange -ay /dev/vg0/root antes de retry. Y si la columna LSize del origen es mayor que tu VFree del VG menos lo que quieres reservar, ajustá -L a un valor menor o extendé el VG agregando otro disco.

El parámetro -L 10G es el espacio reservado para cambios. Si los bloques cambiados en el origen superan 10 GB, el snapshot se invalida automáticamente.

Para ver el estado del snapshot recién creado, hay dos variantes de lvs que vale la pena entender. La primera te da el panorama general (atributos, tamaño, snapshot LV visible). La segunda usa -o para pedir columnas específicas orientadas al monitoreo de uso.

lvs
# LV              VG   Attr       LSize
# root            vg0  -wi-ao---- 50.00g
# root-snapshot   vg0  -swi-a---- 10.00g   # 's' = snapshot
# Ver cuánto espacio ha consumido
lvs -o lv_name,lv_size,data_percent,snap_percent
# root-snapshot   10.00g   0.00   5.20

data_percent te dice cuánto del espacio reservado se ha usado. Si llega a 100, el snapshot muere.

Montar el snapshot

El snapshot es un LV más desde el punto de vista del kernel, así que se monta como cualquier partición con mount. El orden importa: primero crear el directorio de mount point (no falla si ya existe con -p), después montar, después listar contenido.

mkdir -p /mnt/snapshot
mount -o ro /dev/vg0/root-snapshot /mnt/snapshot
ls /mnt/snapshot
# /etc /var /home ...  (el filesystem al momento del snapshot)

Importante: montar read-only (-o ro) evita que se modifique el snapshot accidentalmente.

Hacer un backup del snapshot

El caso de uso principal: backup consistente sin downtime. El flujo es snapshot → mount read-only → copia con tar o dd → cleanup. Lo crítico es que umount y lvremove -f van siempre al final: si matás el snapshot antes de desmontar, dejás un mount point colgando que va a dar errores I/O hasta que limpies con umount -l.

# Snapshot
lvcreate -L 5G -s -n root-backup /dev/vg0/root
# Montar read-only
mount -o ro /dev/vg0/root-backup /mnt/backup
# Backup con tar
tar -czf /backups/root-$(date +%Y%m%d).tar.gz -C /mnt/backup .
# O backup a otro disco con dd
dd if=/dev/vg0/root-backup bs=4M status=progress | gzip > /backups/root.img.gz
# Cleanup
umount /mnt/backup
lvremove -f /dev/vg0/root-backup

El backup es atómico: si el origen cambia durante el backup, el snapshot mantiene la vista original.

Rollback: volver al estado del snapshot

Si rompiste algo y quieres volver atrás, el merge es la operación que escribe el contenido del snapshot sobre el LV origen. Antes de mergear, verifica que el snapshot sigue ahí con lvs: si ya no aparece, fue eliminado por algún proceso o se llenó.

# 1. Verificar que el snapshot existe
lvs
# 2. Fusionar el snapshot en el origen
lvconvert --merge /dev/vg0/root-snapshot
# Logical volume vg0/root contains a filesystem in use.
# Can't merge over open origin volume.

El problema: el LV origen está montado y en uso. Para hacer merge real, tienes que bootear desde un live USB o un volumen diferente.

Workaround con lvconvert --merge: como no puedes mergear un LV que está montado y en uso, el kernel deja el merge “pendiente” y lo aplica la próxima vez que el origen se desactive. Un reboot es la forma más limpia de forzar esa desactivación.

# El merge queda pendiente hasta que el LV se desmonte
lvconvert --merge /dev/vg0/root-snapshot
# Merging of snapshot vg0/root-snapshot will start on next activation of vg0/root.
# Cuando se desmonte (próximo reboot), el merge se aplica
shutdown -r now

Al reiniciar, el sistema arranca con el contenido del snapshot.

Snapshots thin: menos restricciones

Los snapshots clásicos requieren reservar espacio en disco para cada uno. Los thin snapshots usan un pool compartido: creas un pool una vez (--thinpool), y todos los thin LVs y thin snapshots sacan espacio de ahí dinámicamente. Esto te permite tener decenas de snapshots sin reservar 10 GB cada uno.

# Crear un pool thin (una vez)
lvcreate -L 100G --thinpool thinpool vg0
# Crear LVs thin en el pool
lvcreate -V 20G --thin -n root-thin vg0/thinpool
# Snapshot de un thin LV: sin reservar espacio
lvcreate -s --thin -n root-thin-snap vg0/root-thin
# No necesita -L porque el espacio viene del pool

Ventajas thin:

Múltiples snapshots sin reservar espacio cada uno.
Mejor uso del storage.
Snapshots más rápidos de crear.

Desventajas:

Si el pool se llena, TODOS los LVs thin fallan.
Más complejo de monitorear.

Monitorear pool thin: a diferencia del snapshot clásico (donde data_percent es por snapshot), el pool tiene un único Data% que refleja el uso total del pool. Si llega a 100%, todos los thin LVs y snapshots del pool fallan.

lvs vg0/thinpool
# LV       VG   Attr       LSize   Pool   Data%
# thinpool vg0  twi-a-tz-- 100.00g         75.00
# 75% lleno = el pool está al 75%
# >85% = necesitas extender

Snapshots vs backups: no son lo mismo

Esta es la confusión más común. Un snapshot NO es un backup.

	Snapshot	Backup
Qué guarda	Bloques cambiados vs origen	Copia completa de los datos
Si el disco muere	Se pierde con el origen	Sobrevive si está en otro disco
Espacio	Bajo (solo cambios)	Alto (copia completa)
Velocidad creación	Instantáneo	Lento (copia GB)
Restauración	Merge o montar	Restaurar desde archivo
Para qué sirve	Rollback rápido, backup consistente	Recuperación ante desastre

Reglas:

Snapshot en el mismo disco que el origen: te protege de cambios accidentales, no de fallo de disco.
Backup en otro disco/nube: te protege de fallo de disco, ransomware, borrado accidental.
Snapshot + backup juntos: usa el snapshot para hacer backup consistente, después borralo. Es el patrón correcto.

Snapshots automatizados con cron

Un script simple que crea un snapshot diario, hace backup, y limpia el viejo. Lo clave del flujo: primero cleanup defensivo (si quedó un snapshot del run anterior, lo borra para no acumular LVs huérfanos), después crear nuevo, después montar read-only, después backup, después cleanup de mounts y LVs. El set -e hace que cualquier comando que falle aborte el script — preferible a un backup a medias que queda sin verificar.

#!/bin/bash
# /usr/local/bin/lvm-snapshot-backup.sh
set -e
VG=vg0
ORIGIN=root
SNAP_NAME=root-snap
MOUNT=/mnt/snapshot
BACKUP_DIR=/backups/daily
RETENTION_DAYS=7
# Cleanup old snapshot if exists
if lvs $VG/$SNAP_NAME >/dev/null 2>&1; then
    umount $MOUNT 2>/dev/null || true
    lvremove -f $VG/$SNAP_NAME
fi
# Create new snapshot (10G reserved)
lvcreate -L 10G -s -n $SNAP_NAME $VG/$ORIGIN
# Mount read-only
mkdir -p $MOUNT
mount -o ro /dev/$VG/$SNAP_NAME $MOUNT
# Backup
mkdir -p $BACKUP_DIR
tar -czf $BACKUP_DIR/root-$(date +%Y%m%d-%H%M).tar.gz -C $MOUNT .
# Verify backup
test -s $BACKUP_DIR/root-$(date +%Y%m%d-%H%M).tar.gz
# Cleanup
umount $MOUNT
lvremove -f $VG/$SNAP_NAME
# Delete old backups
find $BACKUP_DIR -name "root-*.tar.gz" -mtime +$RETENTION_DAYS -delete

Cron corre el script todos los días a las 3 AM y redirige stdout+stderr a un log para debug. Las 3 AM es horario de baja actividad para servidores; cualquier hora de madrugada sirve mientras no choque con otros jobs pesados (mysql backup, logrotate, etc.).

Cron:

# Diario a las 3 AM
0 3 * * * /usr/local/bin/lvm-snapshot-backup.sh >> /var/log/lvm-snapshot.log 2>&1

Antes de un upgrade grande del sistema, crear un snapshot es la red de seguridad más barata que tienes. Si el upgrade rompe X11, drivers, o algún servicio, mergear el snapshot vuelve al estado anterior sin reinstalar. El snapshot reserva solo lo que cambie durante el upgrade — para apt full-upgrade típico, 5 GB alcanza de sobra.

Casos de uso donde SÍ tienen sentido

Upgrade de sistema

# Antes de un apt upgrade importante
lvcreate -L 5G -s -n pre-upgrade /dev/vg0/root
apt full-upgrade -y
# Si algo se rompe
lvconvert --merge /dev/vg0/pre-upgrade
# reboot

Cambios de config arriesgados

Para cambios de configuración arriesgados (nginx, systemd units, /etc/fstab), el snapshot funciona como un git stash pero a nivel de filesystem entero. El merge queda pendiente hasta el reboot, así que no interrumpe tu sesión actual.

lvcreate -L 2G -s -n pre-nginx /dev/vg0/root
# editar configs nginx
# Si rompe
umount /etc/nginx  # si lo montaste bind
lvconvert --merge /dev/vg0/pre-nginx
reboot

Testing de migraciones de DB

Para testing de migraciones de DB, el snapshot te da un rollback instantáneo sin tener que restaurar un backup completo (que tarda minutos o horas). El patrón es: snapshot → correr migración dentro de una transacción → si falla, rollback de la transacción; si está OK pero quieres volver al estado pre-migración, merge del snapshot.

# Snapshot del volumen de DB
lvcreate -L 5G -s -n pre-migration /dev/vg0/db-data
# Correr migración
psql -c "BEGIN; <migración>;"
# Si falla, rollback instantáneo
lvconvert --merge /dev/vg0/pre-migration
# reiniciar DB

Backups de databases online

Para backups online de databases sin downtime: el snapshot congela una vista consistente del volumen mientras la DB sigue aceptando writes. Después corres mysqldump o pg_dump desde el mount point read-only — los datos leídos son consistentes al momento del snapshot, sin necesidad de lockear tablas.

# Crear snapshot, montar, mysqldump
lvcreate -L 5G -s -n db-snap /dev/vg0/mysql-data
mount -o ro /dev/vg0/db-snap /mnt/db
mysqldump --all-databases > /backups/db-$(date +%Y%m%d).sql
umount /mnt/db
lvremove -f /dev/vg0/db-snap

Limitaciones y gotchas

1. Si el snapshot se llena, muere silenciosamente

Si el origen cambia más allá del espacio reservado, el snapshot se invalida. El sistema NO te avisa por default. Monitoreo:

Monitorear el espacio del snapshot con un threshold del 80% es lo mínimo que necesitas: si te enterás recién cuando llega a 100%, ya es tarde. El truco está en que data_percent puede ser un float (12.34), por eso se usa bc -l para comparar en lugar de bash arithmetic nativo que solo maneja enteros.

# Alerta si supera 80%
DATA=$(lvs --noheadings -o data_percent $VG/$SNAP_NAME | awk '{print $1}')
if (( $(echo "$DATA > 80" | bc -l) )); then
    echo "Snapshot al ${DATA}% - extendido" | mail -s "LVM Alert" [email protected]
fi

2. Snapshots afectan performance

Cada escritura al origen requiere un write al snapshot. Con muchos snapshots, el rendimiento cae. Regla empírica: máximo 2-3 snapshots activos por LV origen.

3. No puedes bootear desde un snapshot sin preparación

Para hacer rollback real, necesitas bootear desde otro lugar (live USB, otro LV con el OS). El merge automático al reiniciar funciona pero requiere cuidado.

4. Snapshots thin compartidos

Si varios LVs thin están en el mismo pool, todos comparten el espacio. Llenar uno puede afectar a otros.

5. Snapshots NO reemplazan backups en otro medio

Si el disco muere, el snapshot muere con él. Para protección real, necesitas backup off-site o en otro disco.

Snapshots en sistemas de archivos: alternativa moderna

LVM snapshots no son la única opción. Muchos filesystems tienen snapshots nativos:

btrfs

btrfs snapshots son a nivel de subvolume, no de LV completo. La flag -r (readonly) es importante en producción: si lo creas escribible, los procesos dentro del snapshot siguen modificando archivos y perdés la inmutabilidad. La restauración es mv + nuevo snapshot, no btrfs send/receive.

# Crear snapshot (instantáneo, sin reservar)
btrfs subvolume snapshot -r /mnt/data /mnt/data/.snapshots/2026-08-03
# Restaurar
mv /mnt/data /mnt/data.broken
btrfs subvolume snapshot /mnt/data/.snapshots/2026-08-03 /mnt/data

Mejor que LVM para btrfs. Snapshots son a nivel de subvolume.

ZFS

ZFS tiene snapshots transactionales: o se aplican todos los bloques o ninguno, sin estados intermedios corruptos. zfs send | zfs recv te permite serializar un snapshot a un stream que puedes guardar en otro pool, mandar por SSH, o comprimir — es la base de cualquier estrategia de replicación ZFS seria.

zfs snapshot tank/data@2026-08-03
zfs rollback tank/data@2026-08-03
zfs send tank/data@2026-08-03 | zfs recv backup/data

Si tu pool es ZFS, usa ZFS snapshots. Son superiores a LVM.

XFS

XFS NO tiene snapshots nativos. Para XFS, las opciones son:

LVM snapshots (lo de esta guía).
Stratis (wrapper de LVM con API simple).
Backup a nivel de archivo con xfsdump.

Cuándo NO usar LVM snapshots

El filesystem no es compatible: funciona con ext4, xfs, reiserfs. NO con btrfs (usa sus snapshots), ni con ZFS (usa los suyos).
Servidor de bases de datos con mucha escritura: el snapshot overhead degrada el rendimiento. Mejor método: mysqldump/pg_dump o el método propio de la DB para backup consistente.
Discos en RAID con batería baja: el snapshot requiere flush de cache. Sin batería, riesgo de inconsistencia.
Storage crítico en producción sin pruebas: prueba el rollback en dev primero. Un snapshot que crees mal puede darte falsa sensación de seguridad.

Conclusión

LVM snapshots son una herramienta útil para backups consistentes y rollback rápido. NO son backups por sí mismos. El patrón correcto es: crear snapshot → montar read-only → copiar a otro medio → borrar snapshot. Hacer esto periódicamente con cron te da protección real.

Para 2026, si estás empezando un proyecto nuevo, evaluá ZFS o btrfs con snapshots nativos. Si ya tienes LVM, este workflow te sirve. Si tienes MySQL/PostgreSQL con mucho I/O, los snapshots de LVM penalizan performance; mejor estrategia: backup lógico con mysqldump/pg_dump o pg_basebackup.

FAQ

¿Cuánto espacio reservar? Regla práctica: 15-20% del tamaño del LV. Para una DB con mucho cambio, 30-50%. Si puedes, monitorear data_percent y extender si hace falta.

¿Funciona con SSDs? Sí, sin diferencia. Los SSDs no tienen problema con snapshots. La copia-on-write es a nivel de bloque, no le importa el medio.

¿Y con RAID? Funciona. El snapshot es del LV, que está encima del RAID. El RAID sigue protegiendo contra fallos de disco; el snapshot protege contra cambios accidentales.

¿Puedo tener múltiples snapshots del mismo LV? Sí, pero cada uno consume espacio para sus cambios. El rendimiento cae con cada snapshot activo.

¿Cómo monitoreo el espacio usado? lvs -o lv_name,data_percent te dice el porcentaje. Para alertas, agregar a monitoring (Prometheus + node_exporter, o script bash con mail).

¿Qué pasa si borro el origen sin mergear? Si eliminás un LV origen con snapshots activos, los snapshots quedan huérfanos. No son recuperables fácilmente. Cuidado.

¿Es igual que un snapshot de Docker? Conceptualmente sí (copy-on-write), técnicamente no. Docker usa overlay filesystem, no LVM. Son tecnologías diferentes que resuelven problemas similares.

Preguntas frecuentes

¿Por qué Snapshots de LVM: qué son y cómo usarlos en Linux es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Snapshots de LVM: qué son?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Snapshots de LVM: qué son?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Snapshots de LVM: qué son y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Snapshots de LVM: qué son?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.