¿Pierde todo cuando tiene una falla de disco duro en un LVM de disco duro múltiple que NO usa RAID?

Estoy debatiendo sobre el uso de LVM para un servidor de medios / archivos porque me gustaría combinar varios discos duros físicos en un solo volumen. No deseo utilizar ningún RAID en mi LVM, así que mi pregunta es:

Si uno de los múltiples discos duros de mi volumen cayera, ¿perdería todos mis datos o simplemente perdería los datos que estaban almacenados en ese disco individual?

Además, si solo perdiera los datos en el disco individual, ¿sería tan simple como reemplazar ese disco y restaurar lo que había en él desde una copia de seguridad para recuperarlo?

Si uno de los múltiples discos duros de mi volumen cayera, ¿perdería todos mis datos o simplemente perdería los datos que estaban almacenados en ese disco individual?

No, perderá los datos almacenados en todo LVM

Además, si solo perdiera los datos en el disco individual, ¿sería tan simple como reemplazar ese disco y restaurar lo que había en él desde una copia de seguridad para recuperarlo?

No, no es tan simple

Puede leer aquí una pregunta similar sobre LVM y recuperación ante desastres

Simple: estás buscando mhddfs .
Finge ser un sistema de archivos grande, escribe en los discos en el orden en que se mencionaron y eventualmente mueve archivos grandes a un dispositivo diferente, si el primero estaba demasiado lleno. En realidad, también puede usar subcarpetas en los discos, lo que permite la misma funcionalidad.
Los discos individuales deben montarse primero y permanecer accesibles. No altera en absoluto los sistemas de archivos y no le importa qué sistema de archivos está en su lugar (siempre que el sistema de archivos informe correctamente el espacio libre). En caso de que se pierda un disco, deberá volver a montar sus mhddfs (sobre la marcha) y los datos de ese disco desaparecerán.
Uso:

mhddfs /dir1,/dir2[,/path/to/dir3] /path/to/mount [-o options]

o en /etc/fstab

 mhddfs#/path/to/dir1,/path/to/dir2 /mnt/point fuse defaults 0 0

Complejo y poderoso: quieres unionfs .
Si bien mhddfs es agradable y extremadamente simple, he tenido problemas con los permisos de archivos al otorgar acceso a otros a través de SSH. No pude encontrar ninguna solución, pero encontré unionfs.
Unionfs también le permite montar varias carpetas en diferentes sistemas de archivos en uno, pero es mágico en los permisos. Puede combinar varias carpetas de solo lectura y una de escritura, de modo que aparezca como una. Las personas con las que compartió su carpeta combinada pueden escribir en una carpeta de solo lectura, como les parece, pero los archivos terminan en una única carpeta de escritura. Los CD de arranque de Linux funcionan así, el disco grabable es un disco RAM. Las personas incluso pueden eliminar archivos en carpetas de solo lectura, lo que realmente no elimina el archivo, sino que crea un archivo oculto en la lista blanca en su directorio de escritura. Si captura todas las opciones, básicamente puede usar su sistema de archivos como un SVN de hombre pobre .
Si usa demasiado las opciones similares a SVN, es posible que pierda datos existentes dos veces (improbable en su escenario, pero posible), mientras que su carpeta de escritura se llena con pequeños archivos ocultos en la lista blanca. Aparte de eso, mantiene sus discos limpios y utilizables individualmente. ¿Qué sucede si un archivo es demasiado grande para un disco? Aún no lo sé.
Uso:

 unionfs-fuse -o cow,max_files=32768 \
                 -o allow_other,use_ino,suid,dev,nonempty \
                 /path/to/dir1=rw:/path/to/dir2=ro:/dir3
                 /u/union/etc

where =rwhace que la carpeta sea de lectura y escritura y la =rohace de solo lectura, incluso si los permisos establecieran lo contrario. En etc/fstabesto es

unionfs-fuse#/path/to/dir1=rw:/path/to/dir2=ro:dir3 /path/to/mount fuse cow,allow_other 0 0

Si solo conecta varios dispositivos, no habría redundancia, por lo que podría perder los datos. Pero si está utilizando un servidor de medios / archivos para una empresa, no debe perder nada porque tiene todo respaldado en un servidor de respaldo / unidad de cinta.

¿Por qué estás evitando RAID? El punto de RAID es la disponibilidad; Si no desea perder tiempo debido a un fallo del disco, puede usar una configuración RAID 1, que también puede acelerar sus lecturas. No son demasiado caros, se pagan por sí mismos la primera vez que tiene una falla en el disco, y si REALMENTE está evitando tener que pagar una tarjeta, puede configurar Linux para usar RAID de software, aunque requiere un poco más de cuidado en la configuración y solución de problemas para asegurarse de reemplazar la unidad correcta.

De lo contrario, tendría que saltar algunos aros para intentar recuperar los datos que pueda de los discos restantes. Sería posible, pero estás pidiendo más problemas de los que deberías tener. Obtenga una buena copia de seguridad y reconsidere el RAID.

Si está utilizando un sistema de archivos que abarca todos los volúmenes LVM, todo el sistema de archivos se dañará ya que el FS no conoce los volúmenes físicos subyacentes y no creará estructuras alineadas a él. Puede ser posible rescatar algunas de las partes en los discos de trabajo, pero no hay garantía para eso.

Y solo recuperar los archivos del disco dañado tampoco funcionará por la misma razón.

Creo que una ruta mucho más simple sería configurar mdadm para su partición de medios. Si no tiene el hardware para "RAID real", la ruta mdadm sería considerablemente más fácil y parece cumplir con sus requisitos de redundancia y reemplazo simple de disco.

# Format your drives first
# Create your MD
mdadm --create /dev/md1 --level=5 --raid-devices=3 /dev/sda2 /dev/sdb2 /dev/sdc2

# In the event that a drive fails do the following
mdadm /dev/md1 --fail /dev/sda1
# Format the new drive
mdadm --add /dev/md1 /dev/sda1

Para más información: http://en.wikipedia.org/wiki/Mdadm

Si uno de los múltiples discos duros de mi volumen cayera, ¿perdería todos mis datos o simplemente perdería los datos que estaban almacenados en ese disco individual?

Si usa mdadm y RAID 5, podría perder una unidad y tener la matriz funcional, pero experimentaría una degradación del rendimiento.

Creo que lo importante para entender que no se ha mencionado es que un archivo en un sistema de archivos no está necesariamente en un lugar en un disco. Se divide en bloques que pueden residir en cualquier lugar dentro de los sistemas de archivos. El primer 4K si su archivo podría estar en el disco1, el siguiente disco2, etc. Puede imaginarse el desastre de intentar recuperar algo si pierde una parte del sistema de archivos.

Btrfs es una buena opción aquí; puede tener metadatos resistentes a la pérdida de un disco (el perfil de fragmento "raid1"); los datos en los otros discos seguirán siendo accesibles (solo para que quede claro, eso se traduce en archivos llenos de agujeros donde se hace referencia al disco faltante). Esto se realiza ejecutando btrfs balance con un filtro :

sudo btrfs balance start -m convert=raid1 /mnt/point