Migrando para LVM

Question

A unidade do meu servidor de mídia Ubuntu está quase cheia. Espero adicionar mais 2 TB de capacidade à máquina e preferiria que todos os 3,5 TB fossem reconhecidos como uma única unidade. Para complicar as coisas, não quero perder nenhum dado da unidade nem 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 pretendo apagar a unidade antiga e adicioná-la ao grupo de volumes.

Este plano funcionará?

Minhas maiores dúvidas são: -O dd conseguirá copiar minha instalação para outra unidade sem problemas? Mesmo que seja um grupo de volume? -O dd 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á estiver usando LVM:

• Certifique-se de que o novo disco esteja montado e particionado para LVM (alternar 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)
• pvmoveseus dados do disco antigo para o novo. Não há necessidade de dd. ( pvmove /dev/your-old-diskforç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 VG no novo disco.
• Copie seus dados para um novo LV no novo VG.
  Eu usaria dump+ restorese disponível para o seu sistema de arquivos, mas você pode usar cpioor tarou mesmo ddse quiser.
• Formate o disco antigo, transforme-o em um PV, adicione-o ao VG.

---

^{O que se segue é um tanto opinativo e não tem nada a ver com LVM.}

• ^{dump+ restore:}
  • ^{Opere no dispositivo de bloco bruto, para que a origem, atimeetc. não seja afetada e o destino ctime, etc., possa ser definido corretamente.}
  • ^{Preserva todos os hardlinks e deve compreender o interior do sistema de arquivos bem 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:}
  • ^{Opera em sistema de arquivos montado, portanto a origem atimeé alterada, o destino ctimenão pode ser preservado, os números dos inodes mudam, etc.}
  • ^{Preservar hardlinks requer manter todos os inodes conhecidos na memória e pode ou não ser feito corretamente. A ferramenta pode ou não entender o sistema de arquivos bem o suficiente, ou ter privilégios, para preservar atributos estendidos, políticas de segurança e outros metadados específicos do sistema de arquivos.
    (Por exemplo, ext4 suporta carimbos de data/hora abaixo de milissegundos, mas até onde sei, nenhuma dessas ferramentas os preserva.)}
  • ^{A origem e o destino podem ser de tamanhos diferentes; copia apenas dados especificados.}
  • ^{Passa muito tempo em syscalls ( 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 deveriam ser exclusivas (como UUID).
    Não é possível montar ambos (por padrão) ao mesmo tempo no mesmo sistema se forem XFS.}
  • ^{Não é possível redimensionar durante a cópia.}
  • ^{Comparativamente lento se o sistema de arquivos não estiver muito cheio.}