Intenta tar
, pax
, cpio
, con algo de amortiguación.
(cd /home && bsdtar cf - .) |
pv -trab -B 500M |
(cd /dest && bsdtar xpSf -)
Sugiero en bsdtar
lugar de tar
porque al menos en algunas distribuciones de Linux tar
es GNU tar que, al contrario de bsdtar
(from libarchive
) no maneja la preservación de atributos extendidos o ACL o atributos de Linux.
pv
almacenará en búfer hasta 500 millones de datos para que pueda acomodar mejor las fluctuaciones en las velocidades de lectura y escritura en los dos sistemas de archivos (aunque en realidad, es probable que tenga un disco más lento que el otro y el mecanismo de escritura del sistema operativo hará ese búfer como bueno, entonces probablemente no habrá mucha diferencia). Las versiones anteriores de pv
no son compatibles -a
(para informes de velocidad promedio), puede usar pv -B 200M
solo allí.
En cualquier caso, esos no tendrán la limitación de cp
, que hace las lecturas y las escrituras secuencialmente. Aquí tenemos dos tar
trabajando simultáneamente, por lo que uno puede leer un FS mientras el otro está ocupado esperando que el otro FS termine de escribir.
Para ext4 y si está copiando en una partición que es al menos tan grande como la fuente, vea también clone2fs
cuál funciona ntfsclone
, es decir, copia los bloques asignados solo y secuencialmente, por lo que el almacenamiento rotacional probablemente sea el más eficiente.
Partclone generaliza eso a unos pocos sistemas de archivos diferentes.
Ahora, algunas cosas a tener en cuenta al clonar un sistema de archivos.
La clonación sería copiar todos los directorios, archivos y sus contenidos ... y todo lo demás. Ahora todo lo demás varía de un sistema de archivos a otro. Incluso si solo consideramos las características comunes de los sistemas de archivos Unix tradicionales, tenemos que considerar:
- enlaces: enlaces simbólicos y enlaces duros. A veces, tendremos que considerar qué hacer con enlaces simbólicos absolutos o enlaces simbólicos que señalan el sistema de archivos / directorio para clonar
- Última modificación, tiempos de acceso y cambio: solo se pueden copiar los dos primeros utilizando la API del sistema de archivos (cp, tar, rsync ...)
- escasez: tiene ese archivo escaso de 2 TB que es una imagen de disco de VM que solo ocupa 3 GB de espacio en disco, el resto es escaso, hacer una copia ingenua llenaría la unidad de destino.
Entonces, si considera la ext4
mayoría de los sistemas de archivos de Linux, deberá considerar:
- ACL y otros atributos extendidos (como los utilizados para
SELinux
)
- Atributos de Linux como banderas inmutables o de solo agregado
No todas las herramientas de apoyo a todos aquellos, o cuando lo hacen, usted tiene que permitir explícitamente como el --sparse
, --acls
... opciones de rsync
, tar
... Y al copiar en un diferentes sistemas de archivos, usted tiene que considerar el caso en que no lo hacen admite el mismo conjunto de características.
También es posible que tenga que considerar los atributos del sistema de archivos como el UUID, el espacio reservado para la raíz, la frecuencia fsck, el comportamiento diario, el formato de los directorios ...
Luego, hay sistemas de archivos más complejos, en los que realmente no puede copiar los datos copiando archivos. Considere, por ejemplo, zfs
o btrfs
cuándo puede tomar instantáneas de subvolúmenes y bifurcarlos ... Esos tendrían sus propias herramientas dedicadas para copiar datos.
La copia de byte a byte del dispositivo de bloque (o al menos de los bloques asignados cuando sea posible) es a menudo la más segura si desea asegurarse de copiar todo. Pero tenga cuidado con el problema de choque de UUID, y eso implica que está copiando en algo más grande (aunque podría cambiar el tamaño de una copia instantánea de la fuente antes de copiar).
cp
es lento, otros métodos también lo serían. A menos que no sea una copia orientada a archivos