rsync all'archivio compresso di file

Prendo i backup di un server con rsync, ma questi backup sono abbastanza grandi e vorrei comprimerli. C'è un modo per avere una sorta di wrapper intorno a rsync per gunzip il file nel backup, rsync le modifiche dal file live, quindi re-gzip il file non appena viene copiato?

Se i file di origine in diretta sono foo , bar e baz , il backup ha foo.gz , bar.gz e baz.gz.

  • Linux: Sincronizza due autorizzazioni di directory, utenti e gruppi e lascia il contenuto del file incontaminato
  • Spostare un database in modalità di ripristino
  • Perché lo script di backup non è riuscito con il cron?
  • Qualsiasi necessità di effettuare il backup dei dati su Amazon S3?
  • Come eseguire backup / snapshot a una partizione ext4 (in assenza di LVM)?
  • Perché il mio rsync è così lento rispetto a cp puro o persino scp?
  • Riprovare: voglio i file compressi in una estremità ei file non compressi all'altra estremità. Non voglio comprimere prima di rsyncing, perché anche con –risyncable, rende rsync less efficiente. So che l'opzione -z per rsync. Non ho spazio sulla macchina di backup per memorizzare tutti i file non compressi.

  • Come posso get CentOS 5 a riconoscere un aumento dello spazio di unità sul mio VM?
  • Soluzione di backup (include il backup del nastro)
  • Qual è il file system più veloce da utilizzare sotto Linux su EC2 per MySQL?
  • EBS + RAID10 + XFS più lento di EBS + RAID10 + EXT3 utilizzando MySQL?
  • VirtualBox: file system vboxsf erroneamente rilevato come readonly?
  • RHEL5: Imansible creare file scarsetti più grandi di 256GB in tmpfs
  • 4 Solutions collect form web for “rsync all'archivio compresso di file”

    Non sono sicuro di capire cosa stai cercando di fare, ma potresti creare backup salvati sul server principale, assicurandovi di essere facilmente rsyncable e non preoccupatevi di decomprimere qualcosa in transito.

    gzip(1) --rsyncable While compressing, synchronize the output occasionally based on the input. This increases size by less than 1 percent most cases, but means that the rsync(1) program can much more effi‐ ciently synchronize files compressed with this flag. gunzip cannot tell the difference between a compressed file created with this option, and one created without it. 

    Penso che il rsyncing di un file system installato fuseCompress potrebbe essere l'opzione migliore. La storia del progetto li menziona in modo specifico facendo miglioramenti alle performance di rsync con esso.

    http://code.google.com/p/fusecompress/

    https://github.com/tex/fusecompress/

    È ansible scrivere un wrapper a rsync. Se si tiranno i dati, non c'è niente di speciale da fare. Se si desidera spingere i dati dalle macchine originali al server di backup, è più delicato farlo funzionare:

    Innanzitutto, è necessario essere sicuri che il wrapper sia richiamato con lo stesso nome, il path e i parametri del rsync originale, alless per l'utente sotto il quale eseguire i backup.

    In secondo luogo, assicuratevi di non scrivere nulla a stdout, perché avrebbe ingannato il canale di comunicazione.

    E in terzo luogo, assicuratevi di passare tutti i parametri che hai ottenuto, modificandoti solo come appropriato per la destinazione nuova non compressa.

    Probabilmente sta cercando la compressione della trasmissione dati tramite rsync, e non la compressione di file all'altra estremità.

    Check out: http://jimmyg.org/blog/2007/rsync-basics.html

    Parametri di compressione dalla pagina man:

      -z, --compress compress file data during the transfer --compress-level=NUM explicitly set compression level 

    Per impostazione predefinita ssh effettua una propria compressione in una certa misura. Non so quanto sia meglio il rsync è più di ssh nativo. Se la maggioranza dei file è già compressa in file gzip, probabilmente non sarà molto che il meccanismo di compressione di rsync può fare per te. È ansible solo spremere un file così tanto.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.