---

Hej Liste

Jeg skal tage backup af mit ene nas over til det andet, og havde tænkt
mig at bruge rsync.
Det drejer sig om ca. 600GB backupdata fra f.eks. TimeMachine, hvilket
vil sige ret mange filer, og søger derfor efter den bedste måde at lave
denne overførsel på.

Data'erne ligger pt på en Qnap T-509 og skal over på en Intel SS4000-E.
Der er ssh adgang til dem begge men intel maskinen har en meget lille
CPU.

Mit spørgsmål er derfor. Hvordan får jeg overført data bedst?
Er dette med rsync? og hvilken af systemerne skal i dette tilfælde være
server så det virker mest optimalt?
(Altså, er det serverdelen eller clientdelen der bruger mest CPU)

--
Mvh
Jesper Laursen

---

Jesper Laursen skrev den 03-02-2009 07:33:
> Hej Liste
>
> Jeg skal tage backup af mit ene nas over til det andet, og havde tænkt
> mig at bruge rsync.
> Det drejer sig om ca. 600GB backupdata fra f.eks. TimeMachine, hvilket
> vil sige ret mange filer, og søger derfor efter den bedste måde at lave
> denne overførsel på.
>
> Data'erne ligger pt på en Qnap T-509 og skal over på en Intel SS4000-E.
> Der er ssh adgang til dem begge men intel maskinen har en meget lille CPU.

rsync er fint.

Afhængig af hvor lille cpu'erne er kan du

1) slå komprimering fra
2) sige "kopier altid hele filen hvis den er ændret istedet for at finde
forskellene". Dette kræver naturligvis en masse båndbredde.

Det skulle vist være det værste.

Er båndbredden flaskehalsen så overvej gigabit.

---

On 2009-02-04 10:57:54 +0100, Thorbjørn Ravn Andersen
<thunderaxiom@gmail.com> said:

> Jesper Laursen skrev den 03-02-2009 07:33:
>> Hej Liste
>>
>> Jeg skal tage backup af mit ene nas over til det andet, og havde tænkt
>> mig at bruge rsync.
>> Det drejer sig om ca. 600GB backupdata fra f.eks. TimeMachine, hvilket
>> vil sige ret mange filer, og søger derfor efter den bedste måde at lave
>> denne overførsel på.
>>
>> Data'erne ligger pt på en Qnap T-509 og skal over på en Intel SS4000-E.
>> Der er ssh adgang til dem begge men intel maskinen har en meget lille
>> CPU.
>
> rsync er fint.
>
> Afhængig af hvor lille cpu'erne er kan du

Data skal sendes fra en 1.6Ghz Intel Celeron CPU til en 300Mhz XScale ARM CPU.

> 1) slå komprimering fra
Kan ikke helt se hvordan dette skulle gøres i rsync.

> 2) sige "kopier altid hele filen hvis den er ændret istedet for at
> finde forskellene". Dette kræver naturligvis en masse båndbredde.
Pt er den stadig igang med at overføre nyt indhold. Så der burde den
vel slet ikke kontrollere for filstørrelser.

> Er båndbredden flaskehalsen så overvej gigabit.
Der er gigabit mellem de to maskiner. Faktisk har begge maskiner Dual
gigabit, men mener ikke at switchen undersøtter at bundle linjerne.

Pt overfører jeg med omkring 2-3MB/s hvilket betyder at det vil tage
LAANG tid om at blive færdig.
Jeg vil derfor gerne optimere det meget mere.
Dette er på filer omkring 8 MB, men har også prøvet størrer filer, hvor
den kun kommer op på omkring 4MB/s.

Rsync bruger pt 70-80% CPU på den lille maskine og 2-3% på den store CPU.

Kommendoen jeg overfører med ser sådan ud:

rsync -Phavu /share/MD0_DATA/ 10.0.1.185::backup/

Håber at disse oplysninger kunne være med til at hjælpe lidt mere.

--
Mvh
Jesper Laursen

---

Jesper Laursen <powerlauer@gmail.com> wrote:

>> 1) slå komprimering fra
> Kan ikke helt se hvordan dette skulle gøres i rsync.

Hvis man skal slå komprimering fra så kræver det at du kører rsync over
ssh. Hvis du gør det kan du sætte noget alá dette i ~/.ssh/config

Host backup.host
   Ciphers aes128-cbc
Compression no

mvh
--
Allan Willems Joergensen, OnDemand: http://www.nowhere.dk

"One for the road?" - Trapper. "While we've still got one." - Hawkeye

---

On 2009-02-04 19:35:34 +0100, Allan Willems Joergensen <allan@nowhere.dk> said:

> Jesper Laursen <powerlauer@gmail.com> wrote:
>
>>> 1) slå komprimering fra
>> Kan ikke helt se hvordan dette skulle gøres i rsync.
>
> Hvis man skal slå komprimering fra så kræver det at du kører rsync over
> ssh. Hvis du gør det kan du sætte noget alá dette i ~/.ssh/config
>
> Host backup.host
>    Ciphers aes128-cbc
> Compression no

Men kryptering af indholdet burde da ikke give nogen hastighedforbedring.
Især ikke når det er CPU som svigter.

Eller er jeg helt forkert på den?

--
Mvh
Jesper Laursen

---

Jesper Laursen <powerlauer@gmail.com> wrote:

>> Host backup.host
>>    Ciphers aes128-cbc
>> Compression no
> Men kryptering af indholdet burde da ikke give nogen hastighedforbedring.
> Især ikke når det er CPU som svigter.
> Eller er jeg helt forkert på den?

Du har helt ret, det er også derfor der bruges et minde CPU-intensivt
cipher.

Men kører du på et lokalt netværk kan man med fordel køre rsync som
daemon på target (så er du ude over overhead til ssh).

mvh
--
Allan Willems Joergensen, OnDemand: http://www.nowhere.dk

"Sit on my face, and tell me that you love me"

---

On 2009-02-05 08:18:56 +0100, Allan Willems Joergensen <allan@nowhere.dk> said:

> Jesper Laursen <powerlauer@gmail.com> wrote:
>
>>> Host backup.host
>>>    Ciphers aes128-cbc
>>> Compression no
>> Men kryptering af indholdet burde da ikke give nogen hastighedforbedring.
>> Især ikke når det er CPU som svigter.
>> Eller er jeg helt forkert på den?
>
> Du har helt ret, det er også derfor der bruges et minde CPU-intensivt
> cipher.
>
> Men kører du på et lokalt netværk kan man med fordel køre rsync som
> daemon på target (så er du ude over overhead til ssh).

Helt fint. Det er også måden jeg gør det på.
Den er lige blevet færdig med første del.

sent 18.81M bytes received 467.37G bytes 2.24M bytes/sec
total size is 470.23G speedup is 1.01

--
Mvh
Jesper Laursen