Provate tar, pax, cpio, con qualcosa di buffering.
(cd /home && bsdtar cf - .) |
pv -trab -B 500M |
(cd /dest && bsdtar xpSf -)
Suggerisco bsdtarinvece tarperché almeno su alcune distribuzioni Linux tarè tar GNU che contrariamente a bsdtar(da libarchive) non gestisce la conservazione di attributi estesi o ACL o attributi di Linux.
pvbufferizzerà fino a 500 milioni di dati in modo da poter meglio gestire le fluttuazioni della velocità di lettura e scrittura sui due file system (anche se in realtà, probabilmente avrai un disco più lento rispetto all'altro e il meccanismo di riscrittura del sistema operativo farà quel buffering come bene quindi probabilmente non farà molta differenza). Le versioni precedenti di pvnon supportano -a(per i rapporti sulla velocità media), è possibile utilizzare pv -B 200Mda soli lì.
In ogni caso, quelli non avranno la limitazione di cp, cioè le letture e le scritture in sequenza. Qui ne abbiamo due che tarlavorano contemporaneamente, quindi uno può leggere un FS mentre l'altro è impegnato ad aspettare che l'altro FS finisca di scrivere.
Per ext4 e se stai copiando su una partizione grande almeno quanto l'origine, vedi anche clone2fscome funziona ntfsclone, ovvero copia solo i blocchi allocati e in sequenza, quindi l'archiviazione rotazionale sarà probabilmente la più efficiente.
partclone lo generalizza a pochi file system diversi.
Ora alcune cose da prendere in considerazione quando si clona un file system.
La clonazione avrebbe copiato tutte le directory, i file e i loro contenuti ... e tutto il resto. Ora tutto il resto varia da file system a file system. Anche se consideriamo solo le funzionalità comuni dei file system Unix tradizionali, dobbiamo considerare:
- collegamenti: collegamenti simbolici e collegamenti reali. A volte, dovremo considerare cosa fare con i symlink assoluti o i symlink che indicano la clonazione del file system / directory
- ultima modifica, accesso e tempi di modifica: solo i primi due possono essere copiati utilizzando l'API del filesystem (cp, tar, rsync ...)
- scarsità: hai quel file sparso da 2 TB che è un'immagine del disco della VM che occupa solo 3 GB di spazio su disco, il resto è scarso, fare una copia ingenua riempirebbe l'unità di destinazione.
Quindi, se consideri ext4e la maggior parte dei file system Linux, dovrai considerare:
- ACL e altri attributi estesi (come quelli utilizzati per
SELinux)
- Attributi Linux come flag immutabili o solo append
Non tutti gli strumenti supportano tutti questi, o quando lo fanno, devi abilitarlo esplicitamente come --sparse, --acls... opzioni di rsync, tar... E quando copi su un diverso filesystem, devi considerare il caso in cui non lo fanno supporta lo stesso set di funzionalità.
Potrebbe anche essere necessario considerare gli attributi del file system stessi come l'UUID, lo spazio riservato per root, la frequenza fsck, il comportamento di journaling, il formato delle directory ...
Quindi ci sono file system più complessi, in cui non è possibile davvero copiare i dati copiando i file. Considera ad esempio zfso btrfsquando puoi scattare istantanee di sottovolumi e diramarli ... Questi avrebbero i loro strumenti dedicati per copiare i dati.
La copia da byte a byte del dispositivo a blocchi (o almeno dei blocchi allocati quando possibile) è spesso la più sicura se si desidera assicurarsi di copiare tutto. Ma fai attenzione al problema dello scontro UUID, e questo implica che stai copiando qualcosa di più grande (anche se potresti ridimensionare una copia istantanea della fonte prima di copiare).
cpè lento, anche altri metodi sarebbero lenti. A meno che non si tratti di una copia orientata ai file