Accelerare rsync su smb

Sto eseguendo il backup di un box Linux su SMB su un NAS. Montare il NAS localmente e quindi risincronizzare molti dati (circa 100 GB). Credo che ci voglia molto tempo per farlo: più di 12 ore. Mi sarei aspettato di essere molto più veloce una volta che tutto è stato copiato poiché quasi nulla è cambiato di giorno in giorno.

C'è un modo per accelerare questo?

Stavo pensando che forse rsync pensa che stia funzionando con i dischi rigidi locali e usa il checksum invece dei confronti tempo / dimensioni? Ma non ho trovato il modo di forzare i confronti di data e ora. Qualcos'altro che potrei controllare?

Penso che tu abbia un malinteso sull'algoritmo rsync e su come applicare lo strumento.

Il vantaggio in termini di prestazioni di Rsync deriva dall'esecuzione di trasferimenti delta, ovvero dallo spostamento solo dei bit modificati in un file. Per determinare i bit modificati, il file deve essere letto dagli host di origine e destinazione e bloccare i checksum rispetto a determinare quali bit sono stati modificati. Questa è la parte "magica" di rsync, lo stesso algoritmo rsync.

Quando si monta il volume di destinazione con SMB e si utilizza rsync per copiare i file da ciò che Linux "vede" come origine locale e destinazione locale (entrambi montati su quella macchina), la maggior parte delle versioni rsync moderne passa alla modalità di copia "intero file" e disattiva l'algoritmo di copia delta. Questa è una "vincita" perché, con l'algoritmo delta-copy attivo, rsync leggerà l'intero file di destinazione (via cavo dal NAS) al fine di determinare quali bit del file sono cambiati.

Il "modo giusto" per utilizzare rsync è eseguire il server rsync su una macchina e il client rsync sull'altra. Ogni macchina leggerà i file dalla propria memoria locale (che dovrebbe essere molto veloce), concordando su quali bit dei file sono cambiati e trasferirà solo quei bit. In questo modo stai usando quantità rsync di un 'cp' inventato. Potresti realizzare la stessa cosa con 'cp' e probabilmente sarebbe più veloce.

Se il tuo dispositivo NAS supporta l'esecuzione di un server (o client) rsync, sei nel posto di lavoro. Se hai intenzione di montarlo sul computer di origine tramite SMB, puoi anche usare 'cp' per copiare i file.

Sembra che i timestamp siano il tuo problema, in quanto questa pagina si riferisce:

http://www.goodjobsucking.com/?p=16

La soluzione proposta è quella di aggiungere

--modify-window=1

ai parametri rsync.

Sì, puoi accelerarlo. Devi far sembrare l'origine o la destinazione come una macchina remota, dicendola indirizzandola come " localhost:".

Hai dichiarato che stai montando la condivisione SMB localmente. Questo fa apparire l'origine o la destinazione come un percorso locale per rsync. La pagina man rsync afferma che le copie in cui l'origine e la destinazione sono percorsi locali copieranno l'intero file. Questo è indicato nel paragrafo per l'opzione "--whole-file" nella pagina man. Pertanto, l'algoritmo delta non viene utilizzato. L'uso della localhost:soluzione " " ripristinerà la funzionalità dell'algoritmo delta e accelererà i trasferimenti.

Ho pensato di inserire qui i miei 2p.

Mio fratello ha appena installato un NAS Buffalo sulla sua rete d'ufficio. Ora sta esaminando i backup off-site, quindi se l'ufficio dovesse bruciare, almeno ha ancora tutti i suoi documenti aziendali altrove (a molte centinaia di miglia di distanza).

Il mio primo ostacolo è stato quello di ottenere il VPS che ha (un piccolo server privato virtuale Linux, niente di troppo robusto) per connettersi come utente VPN al suo router a banda larga (sta usando un DrayTek per questo) in modo che esso stesso possa far parte di la sua VPN, e così può quindi accedere direttamente al NAS, in modo sicuro. È stato risolto e funzionante alla perfezione.

Il problema successivo consisteva quindi nel trasferire i file dal NAS al server VPS. Ho iniziato facendo un mount Samba e ho riscontrato esattamente lo stesso (o anche peggio) problema che hai descritto. Ho fatto un rsync a secco e ci sono voluti più di 1 ora e 30 minuti solo per capire quali file avrebbe trasferito, perché come dice Evan, con questo metodo, l'altra estremità non è rsync, quindi deve fare molti file chiamate / letture di sistema sul supporto Samba (attraverso una connessione PPTP / sintonizzata, con un tempo di andata e ritorno di circa 40 ms). Completamente impraticabile.

Non sapevo che Buffalo eseguisse effettivamente un demone rsync, quindi, usando questo, l'intera esecuzione a secco richiede solo 1 minuto e 30 secondi per 87k file per un totale di 50Gb. Ovviamente, trasferire 50 Gb di file (da un NAS che si trova su un collegamento a banda larga con solo 100k / sec di larghezza di banda in uscita) è completamente un'altra questione (ciò richiederà diversi giorni) ma, una volta completata la rsync iniziale, qualsiasi backup incrementale dovrebbe essere alleggerimento del grasso (i suoi dati non cambieranno molto su base giornaliera).

Il mio suggerimento è di usare un NAS decente, che supporti rsync, per i motivi sopra menzionati da Evan. Risolverà tutti i tuoi problemi.

Odora di avere un NAS più economico. Potrebbe anche essere dalla larghezza di banda della tua rete ...

I NAS "standard" per i consumatori sono molto deboli quando si tratta di IO pesanti, che è quello che stai cercando di fare qui. Potrebbe anche essere uno switch economico che collega il PC e il NAS che non è abbastanza potente da gestire correttamente tutti i pacchetti.

prova questo pensa che aleast ti dia il 10% in più che velocità stai ottenendo http://www.thegeekstuff.com/2009/09/linux-remote-backup-using-rsnapshot-rsync-utility/

Esistono due potenziali fonti del problema: si utilizzano opzioni di linea comune errate o il NAS ha problemi con il timestamp (o entrambi :-). Controlla questa discussione "rsync sul NAS copia ogni volta ogni volta" per maggiori informazioni.