Tente tar
, pax
, cpio
, com algo buffering.
(cd /home && bsdtar cf - .) |
pv -trab -B 500M |
(cd /dest && bsdtar xpSf -)
Eu sugiro, em bsdtar
vez de, tar
porque pelo menos em algumas distribuições Linux tar
é GNU tar que, ao contrário de bsdtar
(from libarchive
), não trata de preservar atributos estendidos, ACLs ou atributos linux.
pv
armazenará em buffer até 500 milhões de dados para acomodar melhor as flutuações nas velocidades de leitura e gravação nos dois sistemas de arquivos (embora, na realidade, você provavelmente tenha um disco mais lento que o outro e o mecanismo de gravação do sistema operacional fará esse buffer como bem, provavelmente não fará muita diferença). As versões mais antigas de pv
não suportam -a
(para relatórios de velocidade média), você pode usar pv -B 200M
sozinho lá.
Em qualquer caso, esses não terão a limitação de cp
, que faz as leituras e as gravações sequencialmente. Aqui temos dois tar
trabalhando simultaneamente, para que um possa ler um FS enquanto o outro está ocupado esperando o outro FS terminar de escrever.
Para ext4 e se você estiver copiando para uma partição que seja pelo menos tão grande quanto a origem, veja também clone2fs
como funciona ntfsclone
, que é copiar apenas os blocos alocados e sequencialmente, portanto, o armazenamento rotativo provavelmente será o mais eficiente.
O partclone generaliza isso para alguns sistemas de arquivos diferentes.
Agora, algumas coisas a serem consideradas ao clonar um sistema de arquivos.
A clonagem seria copiar todos os diretórios, arquivos e seu conteúdo ... e tudo mais. Agora, tudo o resto varia de sistema para sistema de arquivos. Mesmo se considerarmos apenas os recursos comuns dos sistemas de arquivos Unix tradicionais, devemos 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 o sistema / diretório de arquivos a ser clonado
- última modificação, acesso e alteração: apenas as duas primeiras podem ser copiadas usando a API do sistema de arquivos (cp, tar, rsync ...)
- escassez: 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, o restante sendo esparso, fazer uma cópia ingênua preencheria a unidade de destino.
Então, se você considerar ext4
e a maioria dos sistemas de arquivos Linux, terá que considerar:
- ACLs e outros atributos estendidos (como os usados para
SELinux
)
- Atributos do Linux, como sinalizadores imutáveis ou somente anexáveis
Nem todas as ferramentas suportam todas elas, ou quando o fazem, é necessário ativá-lo explicitamente, como --sparse
, --acls
... opções de rsync
, tar
... E ao copiar para um sistema de arquivos diferente, você deve considerar o caso em que elas não o são. suporta o mesmo conjunto de recursos.
Você também pode considerar os atributos do sistema de arquivos, como o UUID, o espaço reservado para raiz, a frequência fsck, o comportamento do diário, o formato dos diretórios ...
Depois, existem sistemas de arquivos mais complexos, nos quais você não pode realmente copiar os dados copiando arquivos. Considere, por exemplo, zfs
ou btrfs
quando você pode tirar instantâneos de subvolumes e ramificá-los ... Esses teriam suas próprias ferramentas dedicadas para copiar dados.
A cópia de byte a byte do dispositivo de bloco (ou pelo menos dos blocos alocados quando possível) geralmente é a mais segura se você deseja certificar-se de copiar tudo. Mas cuidado com o problema de conflito do UUID e isso implica que você está copiando para algo maior (embora você possa redimensionar uma cópia instantânea da fonte antes de copiar).
cp
for lento, outros métodos também serão lentos. A menos que não é orientada para o arquivo copiar