Pool de caché en Unraid: redundancia, perfiles y separación de aplicaciones

Pasos a seguir

1. Decide si necesitas un pool o varios

   Agrupa tareas por comportamiento y consecuencias de una interrupción. Las aplicaciones persistentes, las entradas temporales y un destino de backup pueden beneficiarse de separaciones distintas. Varios pools permiten asignar shares a almacenamientos diferentes, pero añaden capacidad reservada y administración. No crees divisiones únicamente por imitar una configuración ajena. Escribe qué debe permanecer disponible si un pool se llena o necesita mantenimiento. Si todos los servicios esenciales dependen del mismo grupo de unidades, reconoce esa dependencia aunque los archivos aparezcan en shares con nombres diferentes.

2. Elige Btrfs o ZFS por el diseño que mantendrás

   Revisa las opciones admitidas por tu versión de Unraid. En Btrfs importa el perfil efectivo de datos y metadatos; en ZFS importan los vdevs y su redundancia. Una combinación de unidades no equivale automáticamente a un espejo. Evita usar perfiles experimentales como respuesta improvisada a una necesidad de capacidad; la documentación advierte especialmente sobre Btrfs RAID5 y RAID6 para datos importantes. Si necesitas ZFS, distingue un pool de varios dispositivos de un disco individual con ZFS dentro del array. Son topologías con propiedades de protección distintas.

3. Calcula espacio útil y margen por carga

   Suma datos permanentes, entradas pendientes de mover y crecimiento esperado. Revisa la capacidad útil de la topología elegida, especialmente cuando mezclas tamaños de unidad. No presupongas que la suma de capacidades nominales está disponible bajo cualquier perfil. Añade margen para snapshots, metadatos y operaciones de mantenimiento cuando correspondan. Planifica dónde guardarás una copia durante cambios de estructura. Un pool ocupado casi por completo puede dificultar operaciones que necesitan reorganizar datos. La capacidad para una migración o recuperación debe estar prevista antes de necesitarla con urgencia.

4. Asigna unidades y verifica el estado resultante

   Identifica dispositivos por número de serie y conserva sus datos previos antes de crear o formatear el pool. Sigue el procedimiento de la versión instalada y revisa cualquier inicialización necesaria. Después comprueba miembros, sistema de archivos, perfil o vdevs y estado de salud. Guarda una referencia del diseño. No interpretes la presencia de dos unidades en la interfaz como prueba suficiente de redundancia. Si añades una unidad a un pool existente, revisa qué operación adicional transforma realmente la distribución y cuándo termina; la asignación física y la finalización del cambio no son lo mismo.

5. Relaciona cada share con su almacenamiento

   En versiones recientes revisa almacenamiento primario, secundario y dirección de Mover para cada share. Decide qué contenido debe permanecer en el pool y cuál se trasladará. Comprueba también aplicaciones que escriben directamente en rutas de dispositivos, porque pueden eludir las expectativas que tienes sobre las shares. Ejecuta una prueba con archivos identificables y verifica su ubicación antes y después del movimiento. No mantengas copias activas del mismo archivo en rutas que se mezclen sin entender cuál se presenta al usuario. Documenta el recorrido de appdata y discos virtuales por separado.

6. Prueba backup y sustitución antes de un fallo

   Conserva copias coherentes de aplicaciones y archivos únicos en otro destino. Revisa el procedimiento de sustitución para la topología elegida y qué debes comprobar antes de retirar un miembro. No extraigas unidades sanas para experimentar con el único pool de producción. Puedes ensayar la recuperación en un entorno de prueba y documentar el proceso. Guarda configuración, claves y etiquetas. Después de ampliar o reemplazar dispositivos, verifica que la redundancia esperada se ha restablecido y abre una muestra de datos; una operación terminada no elimina la necesidad de comprobar el servicio que depende de ella.

Guía detallada

Redundancia del pool y paridad del array

La paridad del array protege su propio conjunto según el número de fallos tolerados y el estado de sus miembros. No se extiende a un pool independiente por estar en el mismo servidor. Un pool de una unidad puede contener la única copia de archivos recientes aunque el array tenga doble paridad. Para datos permanentes de aplicaciones, combina una topología apropiada con backup. Un espejo no conserva automáticamente versiones anteriores ni protege frente a un borrado legítimo. Identifica dónde está cada copia y qué incidente puede afectar a todas al mismo tiempo.

Mantenimiento de integridad según el formato

Programa comprobaciones compatibles y revisa sus resultados. En Btrfs o ZFS, un scrub verifica datos, pero la posibilidad de reparar depende de que exista una copia válida redundante. No confundas detección con recuperación garantizada. Observa errores nuevos de dispositivos, enlaces y memoria si aparecen problemas repetidos. Conserva diagnósticos antes de intentar reparaciones. Cada sistema de archivos tiene herramientas y condiciones propias, y los procedimientos del array no deben aplicarse a un pool por similitud de nombres. Nunca utilices formato como solución automática a un volumen que no monta.

Ampliar sin perder el diseño inicial

Antes de añadir capacidad, comprueba si necesitas más espacio, más rendimiento o más tolerancia a fallos. No siempre se consigue todo con la misma operación. Revisa las reglas del perfil Btrfs o de los vdevs ZFS de tu versión y evita asumir que cualquier unidad añadida queda protegida igual que las existentes. Conserva una copia y un plan de vuelta atrás para cambios que lo permitan. Después actualiza la documentación y las alertas. Un pool que evolucionó varias veces debe seguir siendo comprensible para quien tenga que recuperar una unidad meses después.

Comparar situaciones

Preguntas frecuentes

Guías relacionadas

• Regla de copia de seguridad 3-2-1: cómo organizarla y probarla