Il modo più veloce combina più file in uno (tar czf è troppo lento)


23

Attualmente sto correndo tar czfper combinare i file di backup. I file si trovano in una directory specifica.

Ma il numero di file sta crescendo. L'utilizzo tzr czfrichiede troppo tempo (più di 20 minuti e oltre).

Devo combinare i file più rapidamente e in modo scalabile.

Ho trovato genisoimage, readome mkisofs. Ma non so quale sia il più veloce e quali siano i limiti per ciascuno di essi.


Dubito che tarintroduce un notevole sovraccarico, la lettura dei file è l'operazione costosa qui. Dovresti modificare il modo in cui sono archiviati i tuoi file o usare un approccio radicalmente diverso (copia il filesystem nel suo insieme). Non possiamo aiutarti molto senza sapere come sono organizzati i tuoi file.
Gilles 'SO- smetti di essere malvagio' il

5
Monta il tuo FS con l'opzione "noatime", forse velocizzare le operazioni di IO.
Rufo El Magufo,

2
+1 per mezzogiorno, fa davvero la differenza. Soprattutto per i normali dischi rigidi e anche solo per ridurre le scritture estranee.
JM Becker,

Risposte:


25

È necessario verificare se la maggior parte del tempo viene impiegato nella CPU o nell'I / O. Ad ogni modo, ci sono modi per migliorarlo:

A: non comprimere

Non hai parlato di "compressione" nella vostra lista di requisiti in modo da provare a spostare la "z" dalla vostra lista argomenti: tar cf. Questo potrebbe accelerare un po 'le cose.

Esistono altre tecniche per accelerare il processo, come l'uso di "-N" per saltare i file di cui hai già eseguito il backup.

B: backup dell'intera partizione con dd

In alternativa, se si esegue il backup di un'intera partizione, prendere invece una copia dell'intera immagine del disco. Ciò risparmierebbe l'elaborazione e un sacco di tempo di ricerca della testa del disco. tare qualsiasi altro programma che lavora ad un livello superiore ha il sovraccarico di dover leggere ed elaborare voci di directory e inode per trovare dove si trova il contenuto del file e fare più ricerche su head head , leggendo ogni file da una posizione diversa dal disco.

Per eseguire il backup dei dati sottostanti molto più velocemente, utilizzare:

dd bs=16M if=/dev/sda1 of=/another/filesystem

(Ciò presuppone che tu non stia utilizzando RAID, il che potrebbe cambiare un po 'le cose)


2
non comprimere : o usare pigzse esistono nel sistema più di un processore.
Rufo El Magufo,

Gli algoritmi di compressione LZ4 / zstd e altrettanto veloci possono comunque valere la pena di verificare se possono accelerare un processo semplicemente scrivendo meno dati (se i dati sono comprimibili) pur essendo un ordine di grandezza più veloce nella compressione ma meno efficiente a seconda del livello e algoritmo, anche man gzip dice "Il livello di compressione predefinito è -6", quindi c'è spazio per miglioramenti.
LiveWireBT

8

Per ripetere ciò che altri hanno detto: dobbiamo sapere di più sui file di cui si sta eseguendo il backup. Vado con alcune ipotesi qui.

Aggiungi al file tar

Se i file vengono aggiunti solo alle directory (ovvero, nessun file viene eliminato), assicurati di aggiungere il file tar esistente anziché ricrearlo ogni volta. Puoi farlo specificando il nome file dell'archivio esistente nel tuo tarcomando anziché uno nuovo (o eliminando quello vecchio).

Scrivi su un altro disco

Leggere dallo stesso disco su cui si sta scrivendo potrebbe compromettere le prestazioni. Prova a scrivere su un altro disco per distribuire il carico I / O. Se il file di archivio deve trovarsi sullo stesso disco dei file originali, spostarlo in seguito.

Non comprimere

Sto solo ripetendo quello che ha detto @Yves. Se i file di backup sono già compressi, non è necessario comprimere nuovamente. Sprecherai solo cicli della CPU.


4

Usando tar con cromoterapia lz4 come in

tar cvf - myFolder | lz4 > myFolder.tar.lz4

ti dà il meglio di entrambi i mondi (piuttosto buona compressione E velocità). Aspettati un rapporto di compressione di circa 3 anche se i tuoi dati contengono file binari.

Ulteriori letture: confronto di algoritmi di compressione Come tarare con lz4


1
Quello che sta StefanQ è che è necessario scegliere il compressore in base a dove si trova il collo di bottiglia. Inoltre: ricorda che puoi salvare l'output su un dispositivo di archiviazione fisico diverso o anche su una macchina remota!
Lester Cheung,

2

Sono sorpreso che nessuno menzioni il dump e il ripristino. Sarà molto più veloce di dd se hai spazio libero nel filesystem.

Nota che a seconda del filesystem in questione potresti aver bisogno di diversi strumenti:

  • ext2 / 3/4 - dump e ripristino (pacchetto dump in RH / Debian)
  • XFS - xfsdump e xfsrestore (pacchetto xfsdump in RH / Debian)
  • ZFS - zfs send e zfs recv
  • BTRFS - btrfs invia e btrfs riceve

Nota che alcuni programmi non hanno una compressione integrata (tutti tranne il dump) - pipe per stdout e usa pigz secondo necessità. ;-)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.