Un snapshot es una imagen de un volumen o sistema de archivos en un instante concreto que se crea en segundos, porque solo guarda los bloques que cambian después. Sirve para dos cosas: tener un punto al que volver antes de un cambio arriesgado y obtener una vista estática y coherente de los datos mientras haces una copia de seguridad. En este tutorial usarás un disco adicional en Ubuntu 24.04 para practicar con los tres mecanismos más habituales en Linux: snapshots LVM clásicos, snapshots LVM thin y snapshots de subvolúmenes Btrfs, incluida su automatización con Snapper y la réplica incremental con btrfs send.

Requisitos previos

  • Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath.
  • Un usuario no root con privilegios sudo.
  • Un disco adicional vacío de al menos 20 GB. En la guía es /dev/vdb; el nombre en tu servidor puede ser distinto.
  • Para la sección de réplica, un segundo servidor con un sistema de archivos Btrfs (opcional).

Diferencias entre los tres tipos de snapshot

LVM clásicoLVM thinBtrfs
Espacio del snapshotReservado al crearlo (tamaño fijo)Compartido con el pool thinCompartido con el sistema de archivos
Si se llenaEl snapshot se invalidaSe llena el pool y afecta a todos sus volúmenesSe llena el sistema de archivos
Rendimiento con varios snapshotsEmpeora con cada snapshot activoSe mantieneSe mantiene
Revertirlvconvert --mergelvconvert --mergeSustituir el subvolumen por el snapshot
Sistema de archivosCualquiera (ext4, XFS...)CualquieraSolo Btrfs

Regla práctica: usa LVM clásico para snapshots de corta duración (la ventana de una copia de seguridad), LVM thin si necesitas muchos snapshots sobre ext4 o XFS, y Btrfs si puedes elegir el sistema de archivos y quieres snapshots programados y réplica incremental.

Paso 1: Instalar las herramientas y preparar el disco

Instala las utilidades necesarias. lvm2 suele venir instalado en Ubuntu Server:

sudo apt update
sudo apt install lvm2 thin-provisioning-tools btrfs-progs snapper

Identifica el disco adicional:

lsblk

NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda     253:0    0   40G  0 disk
├─vda1  253:1    0 39.9G  0 part /
└─vda15 253:15   0  106M  0 part /boot/efi
vdb     253:16   0   20G  0 disk

Conviértelo en volumen físico de LVM y crea un grupo de volúmenes llamado vg_data:

sudo pvcreate /dev/vdb
sudo vgcreate vg_data /dev/vdb
sudo vgs vg_data

  VG      #PV #LV #SN Attr   VSize   VFree
  vg_data   1   0   0 wz--n- <20.00g <20.00g

Paso 2: Crear un snapshot LVM clásico

Crea un volumen lógico de 5 GB con ext4, móntalo en /srv/datos y escribe algún dato de prueba:

sudo lvcreate -L 5G -n datos vg_data
sudo mkfs.ext4 /dev/vg_data/datos
sudo mkdir -p /srv/datos
sudo mount /dev/vg_data/datos /srv/datos
echo "versión 1" | sudo tee /srv/datos/config.txt

Crea un snapshot con 1 GB reservado para los cambios:

sudo lvcreate -s -L 1G -n datos_snap vg_data/datos

  Logical volume "datos_snap" created.

Al crear el snapshot, LVM suspende un instante el volumen y congela el sistema de archivos, de modo que el snapshot es coherente a nivel de sistema de archivos. Las aplicaciones con datos en memoria, como una base de datos, deben volcarlos antes o pararse unos segundos si necesitas coherencia a nivel de aplicación.

El tamaño del snapshot no es una copia de los datos: es el espacio donde LVM guarda los bloques originales que se van modificando en datos. Comprueba su ocupación:

sudo lvs vg_data

  LV         VG      Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  datos      vg_data owi-aos--- 5.00g
  datos_snap vg_data swi-a-s--- 1.00g      datos  0.01

La columna Data% indica cuánto espacio reservado se ha consumido. Si llega al 100 %, el snapshot queda inválido y no se puede usar. Para que LVM lo amplíe solo, edita /etc/lvm/lvm.conf:

sudo nano /etc/lvm/lvm.conf

Dentro de la sección activation, define estos valores (existen comentados en el archivo):

activation {
    snapshot_autoextend_threshold = 70
    snapshot_autoextend_percent = 20
}

Con esto, al superar el 70 % el snapshot crece un 20 %, siempre que quede espacio libre en el grupo de volúmenes. La ampliación la hace dmeventd, que Ubuntu activa por defecto.

Paso 3: Hacer una copia de seguridad desde el snapshot

El uso típico es montar el snapshot en solo lectura, copiarlo con calma mientras el volumen original sigue en uso y borrarlo al terminar:

sudo mkdir -p /mnt/snap
sudo mount -o ro /dev/vg_data/datos_snap /mnt/snap
sudo tar -czf /root/datos-$(date +%F).tar.gz -C /mnt/snap .

Comprueba que el archivo contiene los datos:

sudo tar -tzf /root/datos-$(date +%F).tar.gz | head

./
./lost+found/
./config.txt

Desmonta y elimina el snapshot. Cada snapshot clásico activo ralentiza las escrituras en el origen, así que no lo dejes creado más tiempo del necesario:

sudo umount /mnt/snap
sudo lvremove -y vg_data/datos_snap

Paso 4: Revertir un volumen LVM a un snapshot

Antes de un cambio arriesgado (una actualización, una migración de datos) puedes crear un snapshot y, si algo sale mal, fusionarlo con el origen para volver atrás. Simúlalo:

sudo lvcreate -s -L 1G -n antes_cambio vg_data/datos
echo "versión 2 rota" | sudo tee /srv/datos/config.txt

Para revertir, desmonta el volumen y fusiona el snapshot:

sudo umount /srv/datos
sudo lvconvert --merge vg_data/antes_cambio

  Merging of volume vg_data/antes_cambio started.
  vg_data/datos: Merged: 100.00%

El snapshot desaparece al terminar la fusión. Vuelve a montar y comprueba el contenido:

sudo mount /dev/vg_data/datos /srv/datos
cat /srv/datos/config.txt

versión 1

Si el volumen no se puede desmontar (por ejemplo, es la raíz del sistema), lvconvert --merge responde que retrasa la fusión hasta la próxima activación del volumen. En ese caso la fusión se completa al reiniciar.

Paso 5: Usar snapshots LVM thin

Con LVM thin, los volúmenes y sus snapshots toman espacio de un pool común según lo necesitan. Los snapshots no requieren tamaño propio y puedes tener muchos sin penalizar el rendimiento.

Crea un pool thin de 8 GB y un volumen thin de 10 GB dentro:

sudo lvcreate --type thin-pool -L 8G -n pool vg_data
sudo lvcreate -V 10G --thin -n app vg_data/pool
sudo mkfs.ext4 /dev/vg_data/app
sudo mkdir -p /srv/app
sudo mount /dev/vg_data/app /srv/app

LVM avisará de que el tamaño virtual (10 GB) supera al del pool (8 GB). Es el sobreaprovisionamiento propio de thin: funciona mientras los datos reales quepan en el pool.

Crea un snapshot thin. No lleva -L, porque comparte el espacio del pool:

sudo lvcreate -s -n app_snap1 vg_data/app

Los snapshots thin se crean con la marca de omitir activación, así que para montarlo hay que activarlo con -K:

sudo lvchange -ay -K vg_data/app_snap1
sudo lvs vg_data

  LV        VG      Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  app       vg_data Vwi-aotz-- 10.00g pool        1.85
  app_snap1 vg_data Vwi-a-tz-k 10.00g pool app    1.85
  datos     vg_data -wi-ao----  5.00g
  pool      vg_data twi-aotz--  8.00g             2.31   11.43

Vigila siempre Data% y Meta% del pool: si cualquiera de los dos llega al 100 %, todos los volúmenes del pool dejan de admitir escrituras. Configura la ampliación automática en la sección activation de /etc/lvm/lvm.conf:

activation {
    thin_pool_autoextend_threshold = 80
    thin_pool_autoextend_percent = 20
}

Revertir funciona igual que en LVM clásico: desmonta /srv/app y ejecuta sudo lvconvert --merge vg_data/app_snap1. Para borrar un snapshot thin que ya no necesitas, usa sudo lvremove -y vg_data/app_snap1.

Paso 6: Crear subvolúmenes y snapshots Btrfs

En Btrfs los snapshots son una función del propio sistema de archivos: un snapshot es un subvolumen nuevo que comparte bloques con el original. Para practicar, crea un volumen lógico de 4 GB y formatéalo en Btrfs (en un servidor real usarías un disco o partición dedicados):

sudo lvcreate -L 4G -n btrfs vg_data
sudo mkfs.btrfs -L datosbtrfs /dev/vg_data/btrfs
sudo mkdir -p /mnt/btrfs
sudo mount /dev/vg_data/btrfs /mnt/btrfs

Crea un subvolumen para los datos y un directorio para guardar los snapshots:

sudo btrfs subvolume create /mnt/btrfs/web
sudo mkdir /mnt/btrfs/snaps
echo "<h1>versión 1</h1>" | sudo tee /mnt/btrfs/web/index.html

Crea un snapshot de solo lectura. Es la opción adecuada para copias y para btrfs send:

sudo btrfs subvolume snapshot -r /mnt/btrfs/web /mnt/btrfs/snaps/web-$(date +%F_%H%M)

Create a readonly snapshot of '/mnt/btrfs/web' in '/mnt/btrfs/snaps/web-2026-09-25_1020'

Lista los snapshots del sistema de archivos:

sudo btrfs subvolume list -s /mnt/btrfs

ID 257 gen 9 cgen 9 top level 5 otime 2026-09-25 10:20:14 path snaps/web-2026-09-25_1020

Recuperar un archivo

Un snapshot se navega como cualquier directorio. Para recuperar un archivo, cópialo con --reflink, que en Btrfs no duplica los bloques:

echo "<h1>roto</h1>" | sudo tee /mnt/btrfs/web/index.html
sudo cp -a --reflink=always /mnt/btrfs/snaps/web-2026-09-25_1020/index.html /mnt/btrfs/web/index.html
cat /mnt/btrfs/web/index.html

<h1>versión 1</h1>

Revertir el subvolumen completo

Para volver atrás entero, sustituye el subvolumen por una copia escribible del snapshot. Detén antes los servicios que usen esos datos:

sudo mv /mnt/btrfs/web /mnt/btrfs/web.old
sudo btrfs subvolume snapshot /mnt/btrfs/snaps/web-2026-09-25_1020 /mnt/btrfs/web
sudo btrfs subvolume delete /mnt/btrfs/web.old

Sin -r, el snapshot nuevo es escribible y pasa a ser el subvolumen web. Si montas el subvolumen directamente (por ejemplo con subvol=web en /etc/fstab), desmóntalo antes y vuelve a montarlo después.

Paso 7: Automatizar snapshots Btrfs con Snapper

Snapper crea snapshots periódicos y los borra según una política de retención, usando temporizadores de systemd. Crea una configuración para el subvolumen web:

sudo snapper -c web create-config /mnt/btrfs/web

Snapper crea el subvolumen /mnt/btrfs/web/.snapshots y el archivo /etc/snapper/configs/web. Ajusta la retención: por ejemplo, 24 snapshots horarios, 7 diarios, 4 semanales y ninguno mensual ni anual:

sudo snapper -c web set-config TIMELINE_LIMIT_HOURLY=24 TIMELINE_LIMIT_DAILY=7 TIMELINE_LIMIT_WEEKLY=4 TIMELINE_LIMIT_MONTHLY=0 TIMELINE_LIMIT_YEARLY=0

Asegúrate de que los temporizadores están activos:

sudo systemctl enable --now snapper-timeline.timer snapper-cleanup.timer
systemctl list-timers 'snapper-*'

snapper-timeline crea un snapshot cada hora y snapper-cleanup borra los que exceden los límites. También puedes crear uno manual antes de un cambio:

sudo snapper -c web create --description "antes de actualizar"
sudo snapper -c web list

 # | Type   | Pre # | Date                     | User | Cleanup  | Description         | Userdata
---+--------+-------+--------------------------+------+----------+---------------------+---------
0  | single |       |                          | root |          | current             |
1  | single |       | Fri 25 Sep 2026 11:00:01 | root | timeline | timeline            |
2  | single |       | Fri 25 Sep 2026 11:04:37 | root |          | antes de actualizar |

Para ver y deshacer cambios desde un snapshot:

sudo snapper -c web status 2..0
sudo snapper -c web undochange 2..0 /mnt/btrfs/web/index.html

status 2..0 lista los archivos que han cambiado entre el snapshot 2 y el estado actual (0), y undochange los devuelve a como estaban en el snapshot 2. Los snapshots también son accesibles como directorios en /mnt/btrfs/web/.snapshots/<número>/snapshot/. Una vez que Snapper gestiona el subvolumen, revierte con undochange en lugar de sustituir el subvolumen como en el paso 6, porque web contiene ahora el subvolumen .snapshots.

Paso 8: Replicar snapshots con btrfs send y receive

Un snapshot en el mismo disco no te protege si el disco falla. btrfs send convierte un snapshot de solo lectura en un flujo de datos que btrfs receive reconstruye en otro sistema de archivos Btrfs, y a partir del segundo envío solo transmite las diferencias.

El destino debe ser un directorio en un sistema de archivos Btrfs del servidor remoto, por ejemplo /backups, y el comando remoto necesita privilegios de root. Envía el primer snapshot completo:

sudo btrfs send /mnt/btrfs/snaps/web-2026-09-25_1020 | ssh root@backup_server_ip "btrfs receive /backups"

Crea más tarde otro snapshot y envía solo los cambios con -p (el snapshot padre, que debe existir en ambos lados):

sudo btrfs subvolume snapshot -r /mnt/btrfs/web /mnt/btrfs/snaps/web-2026-09-26_1020
sudo btrfs send -p /mnt/btrfs/snaps/web-2026-09-25_1020 /mnt/btrfs/snaps/web-2026-09-26_1020 | ssh root@backup_server_ip "btrfs receive /backups"

Verifica en el servidor remoto que ambos snapshots existen:

ssh root@backup_server_ip "btrfs subvolume list -s /backups"

No borres en origen el último snapshot enviado: será el padre del siguiente envío incremental.

Solución de problemas

Insufficient free space al crear un snapshot clásico. El grupo de volúmenes no tiene espacio libre para la reserva. Comprueba VFree con sudo vgs y reduce -L o amplía el grupo con otro disco (vgextend).

Un snapshot clásico aparece como Invalid en lvs. Se llenó su espacio reservado. No se puede recuperar: elimínalo con lvremove, crea uno mayor y activa la ampliación automática del paso 2.

mount: wrong fs type al montar un snapshot de XFS. XFS rechaza montar dos sistemas de archivos con el mismo UUID. Monta el snapshot con -o ro,nouuid.

ERROR: cannot find parent subvolume en btrfs receive. El snapshot padre indicado con -p no existe en el destino o se recibió desde otro origen. Envía de nuevo un snapshot completo sin -p.

Conclusión

Has creado, montado, revertido y borrado snapshots LVM clásicos y thin, has gestionado subvolúmenes y snapshots Btrfs, los has automatizado con Snapper y los has replicado de forma incremental a otro servidor. Recuerda que un snapshot local no sustituye a una copia de seguridad externa: úsalo como fuente coherente para tus copias. Como siguientes pasos, puedes programar el envío incremental con un temporizador de systemd, combinar el snapshot LVM del paso 3 con una herramienta de copias como restic o Borg, o proteger la raíz del sistema con Snapper si instalas Ubuntu sobre Btrfs.