Tecnologías de almacenamiento en Linux

Desde los sistemas de archivos locales hasta el almacenamiento distribuido

Cuando instalas un servidor Linux, el almacenamiento parece una decisión sencilla: eliges un disco, creas un sistema de archivos y empiezas a guardar datos. Lo difícil empieza cuando aparece el primer problema real: el volumen se queda pequeño, quieres conservar el estado anterior a una actualización, un disco comienza a fallar o el servicio ya no puede depender de un solo servidor. Ahí aparecen diferentes tecnologías de almacenamiento en Linux: sistemas de archivos locales como EXT4 y XFS, gestores de volúmenes como LVM y LVM Thin, soluciones integradas como ZFS y almacenamiento distribuido como Ceph.

Advertencia: los dispositivos y volúmenes son ejemplos. Antes de tocar el almacenamiento, comprueba bien discos, puntos de montaje y datos. Un comando correcto sobre el dispositivo equivocado también destruye información.

Clasificación de las diferentes tecnologías de almacenamiento en Linux

EXT4 y XFS son sistemas de archivos. Organizan archivos, directorios, permisos y espacio libre dentro de un dispositivo de bloques.

LVM y LVM Thin trabajan por debajo del sistema de archivos. Administran dispositivos y presentan volúmenes lógicos que pueden contener EXT4, XFS, swap o discos de máquinas virtuales.

ZFS integra administración de almacenamiento, redundancia y sistema de archivos.

Ceph distribuye los datos entre varios discos y servidores, y puede presentarlos como bloques, archivos u objetos.

No tienes que instalar una tecnología encima de la siguiente. Puedes construir una arquitectura tradicional con LVM y EXT4/XFS, una solución integrada con ZFS o un sistema distribuido con Ceph.

El punto de partida: guardar datos en un servidor

Partimos de un servidor sencillo: un disco, una partición como /dev/sdb1 y un punto de montaje para aplicaciones y datos. Todavía no hay LVM, pools ni clústeres. Primero tienes que decidir qué sistema de archivos colocar directamente sobre esa partición.

Las alternativas locales más habituales son EXT4 y XFS. Ambos utilizan journaling, extents y estructuras maduras. Los dos pueden recuperarse después de una caída inesperada, crecer en línea y trabajar durante años sin requerir una arquitectura compleja.

El journal ayuda a recuperar una estructura coherente después de una interrupción, pero no es un backup. No conserva versiones anteriores ni te protege si pierdes el dispositivo completo.

EXT4: simplicidad y capacidad de reducción

EXT4 sigue siendo una opción totalmente válida. Es conocido, compatible y tiene herramientas de recuperación muy probadas. Algunas distribuciones lo utilizan de forma predeterminada y otras prefieren XFS, pero eso no significa que EXT4 esté en desuso.

Si el disco virtual o físico aumenta de tamaño y queda espacio libre después de /dev/sdb1, primero amplías la partición y después EXT4:

parted /dev/sdb
(parted) print free
(parted) resizepart 1 100%
resize2fs /dev/sdb1

EXT4 puede crecer montado, pero aquí ya aparece una limitación de trabajar directamente sobre particiones: el espacio libre tiene que quedar contiguo al final de /dev/sdb1. No puedes sumar otro disco y entregárselo a ese sistema de archivos como si fuera parte del mismo dispositivo.

EXT4 puede reducirse. Sí, como lo lees: puede reducirse. Tienes que desmontarlo y respetar este orden:

umount /datos
e2fsck -f /dev/sdb1
resize2fs /dev/sdb1 198G
parted /dev/sdb
(parted) unit GiB
(parted) print free
(parted) resizepart 1 201GiB  # (POSICIÓN_FINAL)

Primero reduces EXT4 y después ajustas el límite final de la partición. Imagina una partición de 500 GiB que comienza en 1 GiB y quieres dejarla con un tamaño aproximado de 200 GiB. Puedes reducir EXT4 a 198 GiB para dejar margen y fijar el final de la partición en 201 GiB: 1 GiB de inicio + 200 GiB de tamaño. En el comando, 201GiB es la POSICIÓN_FINAL, no el tamaño del sistema de archivos. Si reduces primero la partición, cortarás bloques que EXT4 todavía considera suyos.

Si sospechas de corrupción, desmonta EXT4 y analízalo primero sin realizar cambios:

e2fsck -fn /dev/sdb1

Si el diagnóstico encuentra inconsistencias y ya tienes una copia de los datos importantes, ejecuta la reparación:

e2fsck -f /dev/sdb1

Si el superbloque principal está dañado, pueden localizarse las copias alternativas sin crear un sistema nuevo:

mke2fs -n /dev/sdb1
e2fsck -b 32768 /dev/sdb1

32768 es solo un ejemplo. Usa uno de los superbloques alternativos que el comando anterior encuentre para ese dispositivo.

EXT4 encaja bien si buscas una solución conocida, amplia compatibilidad o crees que más adelante podrías necesitar reducir el volumen.

XFS: crecer y trabajar a gran escala

XFS está diseñado para grandes volúmenes, archivos de gran tamaño y operaciones concurrentes. Varias distribuciones orientadas a servidores lo utilizan de forma predeterminada, aunque puedes instalarlo y administrarlo en prácticamente cualquier distribución Linux que incluya soporte para XFS.

Si amplías el mismo disco y el espacio libre queda después de /dev/sdb1, puedes extender la partición y después XFS mientras sigue montado:

parted /dev/sdb
(parted) print free
(parted) resizepart 1 100%
xfs_growfs /datos

El problema aparece si quieres reducir espacio: XFS no tiene una reducción convencional soportada. Para hacerlo necesitas crear otro sistema de archivos con el tamaño correcto, copiar o restaurar los datos y sustituir el anterior.

Esta limitación obliga a pensar antes de crear la partición. Que XFS pueda crecer fácilmente no significa que luego puedas devolver parte de ese espacio sin migrar los datos.

Ante una posible corrupción, primero se analiza sin modificar:

umount /datos
xfs_repair -n /dev/sdb1

Si el diagnóstico confirma que hay que reparar:

xfs_repair /dev/sdb1

xfs_repair -L elimina el log y puede perder actualizaciones de metadatos pendientes. No lo uses como primer intento. Déjalo para casos en los que el log no puede reproducirse y XFS tampoco logra recuperarse por la vía normal.

Entonces, ¿EXT4 o XFS?

No puedes decidir solo por velocidad. XFS suele destacar con archivos grandes, concurrencia y grandes capacidades. EXT4 ofrece una administración sencilla, una recuperación conocida y la posibilidad de reducir. En muchas cargas generales la diferencia es tan pequeña que importa más qué sistema conoce y puede recuperar mejor tu equipo.

Antes de elegir, revisa:

• Tipo y cantidad de archivos.
• Operaciones secuenciales o aleatorias.
• Concurrencia.
• Necesidad futura de reducir.
• Tamaño máximo esperado.
• Herramientas y experiencia del equipo.

Hasta aquí ya puedes almacenar, ampliar y recuperar archivos sobre una partición. El problema aparece cuando quieres repartir mejor el espacio, crear varios volúmenes o crecer agregando otro disco. Una partición directa no te da esa flexibilidad. Ahí entra LVM.

Cuando un sistema de archivos ya no basta: LVM

Si creas EXT4 o XFS directamente sobre una partición, el sistema de archivos queda ligado a ese espacio. LVM agrega una capa intermedia para reunir capacidad y repartirla mediante volúmenes lógicos.

La arquitectura queda así:

Discos → Physical Volumes → Volume Group → Logical Volumes → EXT4/XFS

Un Volume Group puede contener varios discos físicos o virtuales y entregar volúmenes distintos para aplicaciones, bases de datos, logs o respaldos. El sistema de archivos continúa siendo EXT4 o XFS; LVM administra el dispositivo que recibe.

Incorporar un disco y ampliar el servicio

Ahora vg_datos se queda sin espacio y agregas un nuevo disco físico o virtual: /dev/sdd:

pvcreate /dev/sdd
vgextend vg_datos /dev/sdd
lvextend -r -L +100G /dev/vg_datos/lv_datos

Con -r, LVM intenta ampliar también el sistema de archivos. Antes de usarla, confirma qué contiene el LV y si esa ampliación está soportada.

También puedes retirar un dispositivo sin desmontar todos los servicios. Si queda capacidad suficiente en otros PV, mueve primero las extensiones utilizadas:

pvmove /dev/sdb /dev/sdc
vgreduce vg_datos /dev/sdb
pvremove /dev/sdb

No ejecutes vgreduce hasta que lvs -a -o +devices confirme que ningún LV sigue utilizando ese PV.

Qué ocurre si falla uno de los discos de LVM

Supón que vg_datos está formado por /dev/sdb y /dev/sdc. Si /dev/sdc falla o desaparece, LVM no reconstruye automáticamente sus datos. Los volúmenes lógicos que utilizaban extensiones de ese PV pueden quedar incompletos y el sistema de archivos podría no montar. Un LV que estuviera contenido por completo en el disco sano sí podría seguir disponible.

pvs
vgs
lvs -a -o +devices

Estos comandos permiten identificar el PV ausente y saber qué volúmenes utilizaban sus bloques. Si necesitas rescatar lo que todavía está accesible, puedes intentar una activación parcial:

vgchange -ay --partial vg_datos

La activación parcial no reconstruye los bloques perdidos. Solo puede ayudarte a acceder a los volúmenes que todavía estén completos o a recuperar parte de la información antes de continuar.

No es lo mismo perder los metadatos de LVM que perder físicamente un disco. pvck permite revisar los metadatos; vgcfgbackup guarda su configuración y vgcfgrestore puede restaurarla desde las copias que LVM conserva normalmente en /etc/lvm/backup/ y /etc/lvm/archive/. Esto puede reparar la estructura de LVM, pero no recupera los bloques de datos que desaparecieron con un disco dañado.

pvck /dev/sdc
vgcfgbackup vg_datos
vgcfgrestore -l vg_datos

Recrear un PV con pvcreate –uuid y restaurar los metadatos puede ser útil cuando se recuperó el contenido del dispositivo o solo se dañó la información de LVM. Hacerlo sobre un disco nuevo y vacío no devuelve los datos originales. vgreduce –removemissing también debe quedar como último recurso, después de recuperar todo lo posible, porque elimina del VG las referencias a los dispositivos ausentes y puede implicar la pérdida de los LV afectados.

LVM aporta flexibilidad, no redundancia automática. Para soportar la pérdida de un disco necesitas redundancia debajo de LVM, un volumen LVM RAID o una copia externa probada. Un snapshot guardado en el mismo VG tampoco es un backup: si se pierde el PV que contiene sus bloques, el snapshot puede perderse junto con el origen.

LVM también puede guardar un estado anterior

Antes de una actualización importante podemos conservar el estado del volumen:

lvcreate --snapshot \
  --name lv_datos_antes_actualizacion \
  --size 20G \
  /dev/vg_datos/lv_datos

El snapshot no duplica inmediatamente todo el origen. A medida que cambian bloques, LVM conserva sus versiones anteriores dentro del espacio reservado. Por eso esos 20 GB no representan el tamaño de los datos, sino la cantidad de cambios que puede absorber el snapshot.

Si el cambio falla y necesitamos volver al estado anterior:

umount /datos
lvconvert --merge /dev/vg_datos/lv_datos_antes_actualizacion

La fusión puede quedar pendiente hasta la siguiente activación del volumen. Planifica la parada y comprueba el resultado con lvs; no lo trates como un simple botón de “deshacer”.

El límite del snapshot tradicional

Si el espacio reservado se llena, el snapshot deja de ser válido. Mantenerlo activo también puede penalizar las escrituras. Úsalo durante una intervención controlada o para sacar una copia hacia otro almacenamiento, no para dejarlo allí indefinidamente.

No olvides algo básico: un snapshot dentro del mismo VG no es un backup. Si pierdes los discos o los metadatos que contienen el origen y el snapshot, pierdes ambos.

LVM resuelve la flexibilidad del espacio, pero en virtualización aparece otro problema: reservar desde el inicio toda la capacidad lógica de cada máquina virtual puede desperdiciar almacenamiento.

LVM Thin: utilizar el espacio cuando se escribe

Tienes 500 GB físicos y quieres crear tres discos virtuales de 300 GB. Con volúmenes tradicionales tendrías que reservar 900 GB. Con LVM Thin, cada máquina ve su tamaño virtual y el thin pool asigna bloques físicos a medida que se escriben.

Thin pool físico: 500 GB
├── VM 101: 300 GB virtuales
├── VM 102: 300 GB virtuales
└── VM 103: 300 GB virtuales

La creación puede hacerse así:

lvcreate --type thin-pool -L 500G -n pool_vm vg_datos
lvcreate --type thin -V 300G -T vg_datos/pool_vm -n vm101

El volumen thin puede recibir EXT4, XFS o utilizarse directamente como disco virtual. Sus snapshots comparten los bloques que no han cambiado y no requieren reservar un LV fijo de antemano:

lvcreate --snapshot -n vm101_antes_actualizacion vg_datos/vm101

Asignación bajo demanda no significa capacidad sobreaprovisionada

El tamaño virtual permite sobreaprovisionar, pero no crea espacio físico. Si todas las máquinas utilizan simultáneamente su capacidad, el thin pool puede llenarse.

Aquí no basta con mirar el tamaño de los volúmenes. Tienes que vigilar datos y metadatos del pool:

lvs -a -o lv_name,lv_size,data_percent,metadata_percent,seg_monitor

LVM Thin tampoco amplía el pool por arte de magia. Para hacerlo automáticamente necesita espacio libre en el VG, monitorización mediante dmeventd y parámetros explícitos en /etc/lvm/lvm.conf:

activation {
    thin_pool_autoextend_threshold = 70
    thin_pool_autoextend_percent = 20
}

lvchange --monitor y vg_datos/pool_vm

Al alcanzar el 70 %, LVM intentará ampliar el pool un 20 %, siempre que el VG todavía tenga extensiones disponibles.

Si Data% o Meta% llegan al 100 %, pueden fallar escrituras y quedar afectados todos los volúmenes alojados en el pool. Esta es la contrapartida del sobreaprovisionamiento: utiliza mejor la capacidad, pero convierte el pool en un recurso común que exige alertas y margen libre.

LVM Thin funciona muy bien con máquinas virtuales, contenedores, snapshots y clones. Pero ni LVM tradicional ni LVM Thin comprueban por sí solos que el disco devuelva exactamente los datos que escribiste. Si además quieres integrar administración, redundancia e integridad, tienes que mirar otra arquitectura.

ZFS: cuando también importa comprobar la integridad

ZFS reúne funciones que en una arquitectura tradicional están repartidas entre varias capas. Administra discos, redundancia, espacio, datasets, volúmenes de bloques, checksums, compresión, snapshots y replicación.

No se limita a comprobar si el sistema de archivos es estructuralmente coherente. Cada bloque dispone de un checksum que permite detectar si su contenido cambió de manera inesperada. Cuando existe redundancia y otra copia es válida, ZFS puede reconstruir el bloque dañado.

Diseñar primero el pool

La unidad de redundancia es el vdev. Uno o varios vdev forman un pool:

Pool tank
├── vdev mirror: disco1 + disco2
└── vdev mirror: disco3 + disco4

Si pierdes un vdev, puedes perder el pool completo. El diseño inicial importa más que el número total de discos.

Un pool con dos discos en mirror y un dataset comprimido podría crearse así:

zpool create tank mirror \
  /dev/disk/by-id/ata-disco1 \
  /dev/disk/by-id/ata-disco2
zfs create tank/datos
zfs set compression=lz4 tank/datos

Las rutas persistentes de /dev/disk/by-id/ evitan depender de nombres como /dev/sdb, que pueden cambiar después de un reinicio o una modificación del hardware.

Detectar no siempre significa poder reparar

Un scrub recorre los bloques asignados y valida sus checksums:

zpool scrub tank
zpool status -v tank

En un mirror o RAID-Z, ZFS puede utilizar otra copia para corregir el daño. En un pool sin redundancia puede detectar la corrupción, pero no necesariamente dispone de información válida para repararla.

El checksum te avisa; la redundancia es lo que te permite reparar.

Snapshots para volver y replicar

Antes de una actualización podemos tomar un snapshot:

zfs snapshot tank/datos@antes_actualizacion

Si solo necesitas un archivo, recupéralo desde el snapshot. Un rollback revierte todo el dataset y descarta los cambios posteriores:

zfs rollback tank/datos@antes_actualizacion

La capacidad de enviar snapshots a otro pool convierte esta función en parte de una estrategia de recuperación más completa:

zfs send tank/datos@inicial | \
  ssh backup zfs receive respaldo/datos
zfs send -i tank/datos@inicial tank/datos@diario | \
  ssh backup zfs receive respaldo/datos

Con esto la copia deja de depender únicamente del pool original. Todavía tienes que definir la retención, proteger el destino y probar que realmente puedes restaurar.

Sustituir un disco y reconstruir

Después de identificar de forma inequívoca el dispositivo fallido, el reemplazo inicia un resilver:

zpool replace tank \
  /dev/disk/by-id/ata-disco-fallido \
  /dev/disk/by-id/ata-disco-nuevo
zpool status tank

El resilver reconstruye los bloques necesarios en el disco nuevo. Mientras termina, la protección puede quedar reducida, así que vigila el estado del pool.

Ampliar ZFS requiere planificación

Una forma predecible de ampliar el pool es agregar otro vdev con una redundancia equivalente:

zpool add tank mirror \
  /dev/disk/by-id/ata-disco3 \
  /dev/disk/by-id/ata-disco4

Otra opción es reemplazar progresivamente los discos por otros mayores. Las versiones actuales de OpenZFS incorporan expansión de RAID-Z agregando dispositivos al vdev, pero esto depende de la versión instalada y de las características habilitadas. No bases una ampliación futura en esta función sin comprobar antes que realmente la tienes disponible.

Los límites de ZFS

ZFS reúne muchas funciones, pero tiene límites que debes conocer:

• Un vdev mal diseñado condiciona todo el pool.
• Los snapshots del mismo pool no sustituyen un backup externo.
• Un scrub detecta corrupción, pero solo puede repararla si existe una copia válida.
• La memoria utilizada por ARC y parámetros como recordsize, volblocksize o sincronización influyen en el rendimiento.
• No coloques ZFS sobre un volumen creado por una controladora RAID por hardware. Es mejor, darle acceso directo a cada disco físico mediante HBA, modo IT, JBOD real o passthrough. Así podrá controlar la redundancia, identificar el disco afectado y ejecutar correctamente el reemplazo y el resilver.
• ZFS protege el almacenamiento local, pero no convierte por sí solo varios servidores en un sistema de almacenamiento compartido.

Ceph: cuando perder un nodo no puede detener el almacenamiento

Hasta ZFS, el almacenamiento pertenece principalmente a un servidor. Podemos tener mirror, RAID-Z, snapshots y una réplica externa, pero las máquinas virtuales de otros nodos no comparten automáticamente ese mismo pool.

Ceph distribuye la información entre varios servidores. Su objetivo no es ser el sistema de archivos local más rápido, sino proporcionar almacenamiento compartido, escalable y tolerante a la pérdida de discos o nodos completos.

Ceph guarda los datos como objetos dentro de RADOS. Los OSD almacenan y replican; los MON mantienen los mapas y el quorum; los MGR aportan administración y métricas; CRUSH decide dónde colocar cada objeto según la topología definida.

Puede presentar el almacenamiento de tres formas:

• RBD: dispositivos de bloques, utilizados con frecuencia para discos de máquinas virtuales.
• CephFS: sistema de archivos distribuido.
• RGW: almacenamiento de objetos mediante interfaces compatibles con S3 o Swift.

RBD puede conectarse a hosts Linux y utilizarse como almacenamiento de bloques para KVM/libvirt, OpenStack, Kubernetes y plataformas de virtualización como Proxmox. En todos esos casos, varios nodos pueden acceder al almacenamiento sin depender del disco local de un solo servidor:

Nodo 1: OSD + MON ─┐
Nodo 2: OSD + MON ─┼─→ Pool Ceph → RBD → discos de VM
Nodo 3: OSD + MON ─┘

De un disco local a un pool replicado

Un pool puede mantener tres copias de cada objeto:

ceph osd pool create pool-vm
ceph osd pool set pool-vm size 3
ceph osd pool set pool-vm min_size 2
rbd pool init pool-vm

Con size 3, Ceph distribuye tres réplicas según la regla CRUSH. min_size 2 fija el mínimo necesario para aceptar operaciones. No reduzcas estos valores solo para quitar una alerta: estarías cambiando la protección y la disponibilidad del pool.

En versiones actuales, el autoscaler puede administrar la cantidad de Placement Groups. Copiar un número fijo desde otra instalación sin considerar OSD, pools y versión puede producir una distribución inadecuada.

Qué ocurre cuando falla un OSD

Si se pierde un OSD, Ceph intenta atender las lecturas desde las réplicas restantes y reconstruir las copias faltantes en dispositivos sanos. El estado del clúster permite seguir esa transición:

ceph -s
ceph health detail
ceph osd tree
ceph osd df

La recuperación automática consume disco, CPU y red, y compite con las operaciones de las aplicaciones. Un clúster demasiado lleno puede tener dificultades precisamente cuando necesita redistribuir más datos.

Ceph tampoco crea capacidad de manera gratuita. Con tres réplicas, la capacidad útil es aproximadamente un tercio de la capacidad bruta, antes de considerar reservas operativas. Erasure Coding mejora la eficiencia, pero agrega cálculo, complejidad y posibles penalizaciones de escritura.

Perder un servidor completo

El verdadero valor de Ceph aparece cuando la regla CRUSH distribuye las réplicas entre hosts diferentes. Si un nodo completo deja de funcionar y todavía existen suficientes copias y quorum, el almacenamiento puede continuar disponible.

Esto es diferente a tener varios discos dentro de un único servidor ZFS. ZFS puede sobrevivir a la pérdida de dispositivos según su redundancia; Ceph puede diseñarse para sobrevivir a la pérdida del host que los contiene.

Ceph no contiene todas las tecnologías anteriores

Los OSD actuales utilizan normalmente BlueStore sobre dispositivos de bloques. ceph-volume puede utilizar LVM para preparar esos dispositivos, pero Ceph no necesita EXT4 o XFS debajo de cada OSD.

Encima de RBD sí puede existir un sistema de archivos:

Ceph RBD → disco de una VM → LVM opcional → EXT4 o XFS

CephFS ya es un sistema de archivos distribuido. ZFS tampoco es una capa obligatoria debajo de Ceph: son arquitecturas diferentes.

Los límites de Ceph

Ceph aporta alta disponibilidad, pero el precio es una operación mucho más compleja:

• Depende de una red con ancho de banda y latencia adecuados.
• Necesita capacidad libre para recuperarse y rebalancearse.
• Requiere entender quorum, OSD, Placement Groups, CRUSH y dominios de fallo.
• La recuperación puede afectar el rendimiento de producción.
• Un clúster pequeño y mal dimensionado puede ofrecer peor rendimiento y más riesgo operativo que un almacenamiento local bien diseñado.
• La replicación de Ceph tampoco sustituye un backup: una eliminación, corrupción lógica o credencial comprometida puede afectar todas las réplicas.

Rendimiento: ¿cuál es más rápido en tu entorno?

EXT4 y XFS directamente sobre una partición suelen ofrecer la menor latencia porque el recorrido hasta el disco es más corto. En un servidor general pueden acercarse mucho: EXT4 funciona bien con cargas variadas, mientras que XFS suele destacar con archivos grandes, escrituras paralelas y volúmenes de gran tamaño.

LVM también añade una capa entre el sistema de archivos y los discos, pero en volúmenes lineales normales su sobrecarga suele ser mínima. El resultado puede cambiar al utilizar snapshots, thin provisioning, LVM RAID o discos con rendimientos diferentes dentro del mismo grupo.

ZFS realiza más trabajo por cada operación debido al copy-on-write, los checksums y la administración integrada de los bloques. Por eso no siempre tendrá menor latencia que EXT4 o XFS sobre el mismo disco. Sin embargo, con memoria suficiente y una configuración adecuada puede rendir muy bien: la caché ARC y la compresión pueden reducir lecturas y escrituras físicas. La deduplicación, en cambio, consume mucha memoria y puede afectar seriamente el rendimiento.

Ceph agrega red, replicación y coordinación entre nodos, por lo que normalmente tendrá más latencia que un NVMe local. Lo eliges para distribuir los datos, crecer entre servidores y mantenerlos disponibles cuando falla un disco o un nodo, no para eliminar el costo de la red y la redundancia. En cualquier caso, el resultado real depende de los discos, la memoria, la red, el tipo de archivos y la concurrencia; la comparación válida es la que reproduce la carga real del servicio.

Recuperación: Definir que falló…

Cómo escoger la arquitectura

Cada paso agrega funciones, pero también componentes que tendrás que supervisar, actualizar y recuperar.

Conclusión

Cada tecnología resuelve problemas en su entorno. EXT4 y XFS organizan los datos y recuperan la consistencia de un sistema de archivos local. LVM permite administrar y ampliar el espacio que reciben. LVM Thin asigna capacidad bajo demanda y mejora el uso de snapshots y clones. ZFS integra administración, redundancia, checksums, snapshots y replicación. Ceph distribuye el almacenamiento entre servidores y puede mantenerlo disponible incluso cuando se pierde un nodo.

La mejor tecnología no es la que acumula más funciones. Es la que resuelve tu necesidad sin llevarte a una complejidad que el equipo no pueda manejar, especialmente cuando algo falla.

Antes de escoger, responde:

• ¿Qué tipo de carga vas a almacenar?
• ¿Cómo crecerá?
• ¿Vas a necesitar reducir volúmenes?
• ¿Qué estados anteriores quieres conservar?
• ¿Qué pérdida necesitas tolerar: un archivo, un disco, un servidor o el sitio completo?
• ¿Quién sabrá recuperar la plataforma cuando falle?

Fuentes técnicas

• Documentación del kernel Linux: EXT4
• Documentación del kernel Linux: XFS
• Linux manual: administración con LVM
• Linux manual: LVM Thin Provisioning
• Documentación oficial de OpenZFS
• Arquitectura oficial de Ceph
• Ceph Block Device: integración con Linux, QEMU/KVM y plataformas cloud
• Rook: almacenamiento Ceph para Kubernetes