Migrando a LVM

Question

La unidad de mi servidor multimedia Ubuntu está casi llena. Espero agregar otros 2 TB de capacidad a la máquina y preferiría que los 3,5 TB sean reconocidos como una sola unidad. Para complicar las cosas, no quiero perder ninguno de los datos del disco ni tener que reconfigurar ningún programa.

Mi plan era usar LVM para crear un grupo de volúmenes en la nueva unidad y usar dd para copiar el contenido de la unidad anterior. Luego planeo borrar la unidad anterior y agregarla al grupo de volúmenes.

¿Funcionará este plan?

Mis preguntas más importantes son: -¿Podré copiar mi instalación a otra unidad sin problemas? ¿Incluso si es un grupo de volumen? -Podrá copiar una unidad de 1,5 TB a una unidad de 2 TB y dejar libre el espacio restante.

Answer 1

Si ya estás usando LVM:

• Asegúrese de que el nuevo disco esté montado y particionado para LVM (alternar bit LVM)
• Cree un PV en el nuevo disco ( pvcreate /dev/your-new-disk)
• Amplíe su VG para incluir el nuevo PV ( vgextend your-volume-group /dev/your-new-disk)
• pvmovesus datos del disco antiguo al nuevo. No es necesario dd. ( pvmove /dev/your-old-diskforzará a LVM a mover los datos del disco antiguo a cualquier otro disco disponible).

Si aún no estás usando LVM:

• Cree un PV y VG en el nuevo disco.
• Copie sus datos en un nuevo LV en el nuevo VG.
  Yo usaría dump+ restoresi está disponible para su sistema de archivos, pero puede usar cpioo tarincluso ddsi lo desea.
• Formatee el disco antiguo, conviértalo en un PV y agréguelo al VG.

---

^{Lo siguiente es algo obstinado y no tiene nada que ver con LVM.}

• ^{dump+ restore:}
  • ^{Opere en el dispositivo de bloque sin formato, de modo que la fuente, atimeetc., no se vea afectada y el destino ctime, etc., se pueda configurar correctamente.}
  • ^{Conserva todos los enlaces físicos y debe comprender los aspectos internos del sistema de archivos lo suficientemente bien como para preservar todos los atributos extendidos, políticas de seguridad y otros metadatos específicos del sistema de archivos.}
  • ^{El origen y el destino pueden ser de diferentes tamaños; sólo copia datos en uso.}
  • ^{Debería ser el método más rápido.}
• ^{cpio/ tar/ rsync/ cp:}
  • ^{Opera en un sistema de archivos montado, por lo que atimese cambia el origen, el destino ctimeno se puede conservar, los números de inodo cambian, etc.}
  • ^{Preservar los enlaces duros requiere mantener todos los inodos conocidos en la memoria y puede que se haga correctamente o no. La herramienta puede comprender o no el sistema de archivos lo suficientemente bien, o tener privilegios, para preservar atributos extendidos, políticas de seguridad y otros metadatos específicos del sistema de archivos.
    (Por ejemplo, ext4 admite marcas de tiempo de menos de milisegundos, pero hasta donde yo sé, ninguna de estas herramientas las conserva).}
  • ^{El origen y el destino pueden ser de diferentes tamaños; sólo copia los datos especificados.}
  • ^{Pasa mucho tiempo en llamadas al sistema ( ,,,,,,,,,,, stat… ) .opendirreaddirclosedirmkdiropenreadwriteclose}
• ^dd:
  • ^{Es una copia exacta del dispositivo de bloque sin formato.}
  • ^{Copia todos los bloques, ya sea que estén en uso o no.}
  • ^{Duplica todas las estructuras del sistema de archivos, incluidas las cosas que deberían ser únicas (como el UUID).
    No se pueden montar ambos (de forma predeterminada) al mismo tiempo en el mismo sistema si son XFS.}
  • ^{No se puede cambiar el tamaño durante la copia.}
  • ^{Comparativamente lento si el sistema de archivos no estaba muy lleno.}