Migrando para o LVM

Question

A unidade no meu servidor de mídia do Ubuntu está quase cheia. Espero adicionar mais 2 TB de capacidade à máquina e preferir que todos os 3,5 TB sejam reconhecidos como uma única unidade. Para complicar as coisas, não quero perder nenhum dado na unidade ou ter que reconfigurar nenhum programa.

Meu plano era usar o LVM para criar um grupo de volumes na nova unidade e usar o dd para copiar o conteúdo da unidade antiga. Então planejo apagar a unidade antiga e adicioná-la ao grupo de volumes.

Este plano funciona?

Minhas maiores perguntas são: -Poderia copiar minha instalação para outra unidade sem problemas? Mesmo que seja um grupo de volume? -Apode ser capaz de copiar uma unidade de 1,5 TB para uma unidade de 2 TB e deixar o espaço restante livre.

    

Answer 1

Se você já usa o LVM:

• Verifique se o novo disco está montado e particionado para o LVM (alternar o bit LVM)
• Crie um PV no novo disco ( pvcreate /dev/your-new-disk )
• Estenda seu VG para incluir o novo PV ( vgextend your-volume-group /dev/your-new-disk )
• pvmove seus dados do disco antigo para o novo. Não há necessidade de dd . ( pvmove /dev/your-old-disk forçará o LVM a mover os dados do disco antigo para qualquer outro disco disponível.)

Se você ainda não estiver usando o LVM:

• Crie um PV e um VG no novo disco.
• Copie seus dados em um novo LV no novo VG.
  Eu usaria dump + restore se disponível para o seu sistema de arquivos, mas você pode usar cpio ou tar ou mesmo dd se desejar.
• Formate o disco antigo, transforme-o em um PV, adicione-o ao VG.

^{O seguinte é um pouco opinativo e não tem nada a ver com o LVM.}

• ^{dump + restore :}
  • ^{Opere no dispositivo de bloco não processado, para que a origem atime etc. não seja afetada e o destino ctime etc. possa ser definido corretamente.}
  • ^{Preserva todos os hardlinks e deve compreender os sistemas de arquivos internos o suficiente para preservar todos os atributos estendidos, políticas de segurança e outros metadados específicos do sistema de arquivos.}
  • ^{A origem e o destino podem ser de tamanhos diferentes; copia apenas dados em uso.}
  • ^{Deve ser o método mais rápido.}
• ^{cpio / tar / rsync / cp :}
  • ^{Opere no sistema de arquivos montado, para que a origem atime seja alterada, o destino ctime não possa ser preservado, os números de inode sejam alterados, etc.}
  • ^{A preservação de hardlinks exige manter todos os inodes conhecidos na memória e pode ou não ser feita corretamente. A ferramenta pode ou não entender bem o sistema de arquivos ou ter privilégios para preservar atributos estendidos, políticas de segurança e outros metadados específicos do sistema de arquivos. (Por exemplo, o ext4 suporta timestamps de sub-milissegundos, mas, até onde sei, nenhuma dessas ferramentas os preserva).}
  • ^{A origem e o destino podem ser de tamanhos diferentes; copia apenas dados especificados.}
  • ^{gasta muito tempo em impressoras ( stat , opendir , readdir , closedir , mkdir , open , read , write , close , …).}
• ^{dd :}
  • ^{É uma cópia exata do dispositivo de bloco bruto.}
  • ^{Copia todos os blocos, estejam em uso ou não.}
  • ^{Duplica todas as estruturas do sistema de arquivos, incluindo coisas que devem ser exclusivas (como UUID).
    Não é possível montar ambos (por padrão) ao mesmo tempo no mesmo sistema, se eles forem XFS.}
  • ^{Não é possível redimensionar durante a cópia.}
  • ^{Comparativamente lento se o sistema de arquivos não estiver muito cheio.}