Teste tar , pax , cpio , com algo em buffer.
(cd /home && bsdtar cf - .) |
pv -trab -B 500M |
(cd /dest && bsdtar xpSf -)
Sugiro bsdtar em vez de tar porque pelo menos em algumas distribuições Linux tar é o tar GNU que, ao contrário de bsdtar (de libarchive ), não manipula a preservação de atributos estendidos ou ACLs ou atributos linux .
pv armazenará em buffer até 500M de dados para acomodar melhor as flutuações nas velocidades de leitura e gravação nos dois sistemas de arquivos (embora, na verdade, você provavelmente tenha um disco mais lento que o outro e o sistema operacional) O mecanismo fará isso tamponando também, então provavelmente não fará muita diferença). Versões antigas de pv não suportam -a (para relatórios de velocidade média), você pode usar pv -B 200M sozinho.
Em qualquer caso, eles não terão a limitação de cp , que faz o lê e o escreve sequencialmente. Aqui temos dois tar trabalhando simultaneamente, então podemos ler um FS enquanto o outro está ocupado esperando que o outro FS termine de escrever.
Para o ext4 e se você estiver copiando em uma partição que seja pelo menos tão grande quanto a origem, consulte também clone2fs que funciona como ntfsclone , ou seja, copia apenas os blocos alocados e seqüencialmente, portanto, o armazenamento rotacional provavelmente será o mais eficiente.
partclone generaliza isso para alguns sistemas de arquivos diferentes.
Agora, algumas coisas a serem consideradas ao clonar um sistema de arquivos.
Clonagem seria copiar todos os diretórios, arquivos e seus conteúdos ... e tudo mais. Agora o todo o resto varia de sistema de arquivos para sistemas de arquivos. Mesmo se considerarmos apenas os recursos comuns dos sistemas de arquivos tradicionais do Unix, temos que considerar:
- links: links simbólicos e links físicos. Às vezes, teremos que considerar o que fazer com links simbólicos absolutos ou links simbólicos que apontam para fora do diretório / system de arquivos para clonar
- última modificação, acesso e horários de alteração: somente os dois primeiros podem ser copiados usando a API do sistema de arquivos (cp, tar, rsync ...)
- dispersão: você tem esse arquivo esparso de 2 TB que é uma imagem de disco da VM que ocupa apenas 3 GB de espaço em disco, sendo o restante escasso, fazer uma cópia ingênua ocuparia a unidade de destino.
Então, se você considerar ext4 e a maioria dos sistemas de arquivos Linux, você terá que considerar:
- ACLs e outros atributos estendidos (como aqueles usados para
SELinux) - Atributos do Linux como sinalizadores imutáveis ou somente de anexação
Nem todas as ferramentas são compatíveis com todas elas ou, quando o fazem, você precisa ativá-lo explicitamente como --sparse , --acls ... opções de rsync , tar ... E ao copiar para em sistemas de arquivos diferentes, você deve considerar o caso em que eles não suportam o mesmo conjunto de recursos.
Você também pode ter que considerar atributos do próprio sistema de arquivos, como o UUID, o espaço reservado para root, a freqüência do fsck, o comportamento do journing, o formato dos diretórios ...
Depois, há sistemas de arquivos mais complexos, nos quais você não pode copiar os dados copiando arquivos. Considere, por exemplo, zfs ou btrfs quando você pode tirar instantâneos de subvolumes e ramificá-los ... Eles teriam suas próprias ferramentas dedicadas para copiar dados.
A cópia byte a byte do dispositivo de bloco (ou pelo menos dos blocos alocados, quando possível) é geralmente a mais segura se você quiser ter certeza de que copiou tudo. Mas cuidado com o problema de conflito do UUID, e isso significa que você está copiando em algo maior (embora seja possível redimensionar uma cópia da fonte antes de copiar).