staging.inyokaproject.org

Hallo Community,

wie ihr dem Titel entnehmen könnt haben wir Probleme mit unserem Backupkonzept. Und da ich mittlerweile den Wald vor lauter Bäumen nicht mehr sehe, möchte ich auch gerne eure Anregungen zu dem Thema hören.

Hintergrund: Wir haben in unserem Netzwerk einen Server mit Ubuntu 11.04 aufgesetzt, der als Backupserver dient und die Daten unserer Server soll. Der Backupserver holt dabei die Daten von den übrigen Servern und legt sie in seinem lokalen Filesystem ab (Software-RAID 5). Wir verwenden dafür das Skript Skripte/Backup mit RSYNC. Die zu sichernden Daten setzen sich aus Datenbank-Dumps, VMware Snapshots (VMDK-Dateien) und sonstigen Dateien zusammen. Von groß bis klein ist alles mit dabei. Auf dem Backupserver liegen zur Zeit 7 TByte an Daten. Täglich ändern sich mehrere hundert GByte davon.

Problematik: Wir möchten, um Redundanz zu erzeugen, die Backups auf einen zweiten Backupserver replizieren. Hierzu wurde ein weiter Backupserver mit Ubuntu 11.10 aufgesetzt. Unsere erste Idee war die Backupverzeichnisse einfach mittels rsync zu synchronisieren. Leider mussten wir feststellen das rsync bereits beim Aufbau der Dateiliste abbricht. Ich habe ein wenig mit den Parametern herumgespielt. Ergebnis ist jedoch, dass die Übertragung über ein 1 Gbit/s Netzwerk unter Verwendung von NFS einfach zu lange dauert.

Nun habe ich mir schon überlegt, dass der Ansatz mit rsync zu sichern bereits falsch ist und evtl. ein anderes Tool zu bevorzugen ist. Wie sichert ihr solche Datenmengen? Wie würdet ihr in dem von mir beschriebenen Fall vorgehen?

Es fehlen sicher noch einige Informationen. Wenn ihr noch weitere Infos braucht, sagt mir welche hilfreich sind und ich reiche diese gerne nach.

MfG

Tronde

Tronde schrieb:

Ich habe ein wenig mit den Parametern herumgespielt. Ergebnis ist jedoch, dass die Übertragung über ein 1 Gbit/s Netzwerk unter Verwendung von NFS einfach zu lange dauert.

Hallo Tronde,

Wieso NFS ? Ist das ggf der Flaschenhals ? Auf dem Server sollte rsync als daemon laufen, und auf Client Seite läuft der rsync Backup Prozess (oder umgekehrt). So braucht mann kein NFS.

rsync über smb oder nfs ist der falsch weg.

u1000 schrieb:

Hallo Tronde,

Wieso NFS ? Ist das ggf der Flaschenhals ? Auf dem Server sollte rsync als daemon laufen, und auf Client Seite läuft der rsync Backup Prozess (oder umgekehrt). So braucht mann kein NFS.

rsync über smb oder nfs ist der falsch weg.

Hi.

Das verstehe ich nicht ganz. Ich benutze NFS, da ich die Daten ja irgendwie über das Netzwerk kopieren muss. Benutzt rsync ein eigenens Protokoll zur Netzwerkübertragung wenn ich einen rsync daemon verwende?

Hast du evtl. eine Quelle wo die Konfiguration eines rsync daemons erklärt wird, bevor ich jetzt wild drauf los suche?

Danke im Voraus.

Tronde

Ja,

"rsync ist sowohl ein Netzwerkprotokoll als auch ein unter der GPL stehendes Programm zur Synchronisation von Daten, meistens über ein Netzwerk." (http://de.wikipedia.org/wiki/Rsync)

Beispiel muss ich raussuchen, im wiki habe ich hier nichts gefunden. Suchbegriff wäre "rsyncd.conf". Ich schreib dir hier noch ein Beispiel.

Hallo Tronde,

Es fehlen sicher noch einige Informationen.

finde ich auch 😉

Täglich ändern sich mehrere hundert GByte davon.

Wieviel ist "mehrere hundert" ungefähr (ca. von bis) und wieviel Zeit hat die Datensicherung dafür? Zeitfenster?

Ergebnis ist jedoch, dass die Übertragung über ein 1 Gbit/s Netzwerk unter Verwendung von NFS einfach zu lange dauert.

das heißt konkret wie lange dauert es aktuell? Welchen durchschnittlichen Durchsatz hast Du dann bei einem 1 Gbit/s Netzwerk?

Wie sieht es bei der Übertragung der Sicherung mit der CPU Auslastung aus?

Wie schnell sind die Platten bzw. das RAID lokal gemessen? (Laufwerksverwaltung, Geschwindigkeitstest)

Gibt es z.B. die Möglichkeit mit mehreren Netzwerkkarten den sync zwischen den beiden Backupservern über ein eigenes LAN abzuwickeln?

Leider mussten wir feststellen das rsync bereits beim Aufbau der Dateiliste abbricht.

Lässt sich die Sicherung u.U. auch in mehrere Sicherungsjob aufteilen?

Gruß

Tom

Tronde schrieb:

Hast du evtl. eine Quelle wo die Konfiguration eines rsync daemons erklärt wird, bevor ich jetzt wild drauf los suche?

Hallo Tronde,

Schau mal im wiki rsync - ich habe hier eben einen ersten Wurf für den daemon Modus geschrieben - würde mich freuen, wenn du testest und ggf. korrigierst.

Hallo.

Im Web habe ich zum Thema RSYNC Daemen folgendes Tutorial gefunden → http://www.fredshack.com/docs/rsync.html. Zum Test bin ich leider noch nicht gekommen. Ich werde es jedoch zuerst nach deinen Ergänzungen im Wiki Artikel versuchen....also wohl eher im Laufe der nächsten Woche. 😉

Bei der Suche nach dem Flaschenhals habe ich zuerst einmal die Netzwerkverbindung zwischen unseren beiden Servern gemessen. Hier sind die Ergebnisse:

1
2
3
4
5
6
7

screen -r iperf
------------------------------------------------------------
[  4] local 10.0.0.242 port 5001 connected with 10.0.0.240 port 43677
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.06 GBytes   911 Mbits/sec
[  5] local 10.0.0.242 port 5001 connected with 10.0.0.240 port 43707
[  5]  0.0-10.0 sec  1022 MBytes   857 Mbits/sec

Momentan versuche ich die Lesegeschwindigkeit des Servers zu ermitteln, von dem ich kopieren möchte. Hier habe ich aktuell noch ein Problem. Liefert mir ein

1

sudo hdparm -t /dev/md0

belastbare Werte oder handel ich an dieser Stelle mit Bananen?

MfG

Tronde

Hi.

Hier kommen die Ergebnisse der Geschwindigkeitsmessung. Ich habe die Werte mit hdparm ermittelt.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

sudo hdparm -t /dev/md0

/dev/md0:
 Timing buffered disk reads: 1638 MB in  3.00 seconds = 545.35 MB/sec

/dev/sde1:
 Timing buffered disk reads: 370 MB in  3.01 seconds = 122.76 MB/sec

/dev/sdd1:
 Timing buffered disk reads: 378 MB in  3.01 seconds = 125.59 MB/sec

/dev/sdc1:
 Timing buffered disk reads: 390 MB in  3.00 seconds = 129.93 MB/sec

Die Werte der übrigen am Raid beteiligten Festplatten liegen ebenfalls in dem oben angegebenen Bereich, weshalb ich sie nicht alle aufgeführt habe. Soweit ich sehe sollten weder Netzwerk noch Festplatten einen Flaschenhals darstellen. Ich weiss jedoch nicht wie ich die Schreibgeschwindigkeit messen kann. Ist hdparm -w destruktiv?

Als nächstes werde ich mal den Ansatz mit dem RSYNC Deamon testen.

Schönes Wochenende

Tronde

Hallo Tronde,

folgende Überlegung: Wenn Du die Daten von einem Backup Server auf den zweiten replizierst, dann replizierst Du auch eventuelle Fehler (von der Übertragung, vom Filesystem, was auch immer).

Ich würde darüber nachdenken, ob es nicht besser ist, das Backup einfach zweimal laufen zu lassen, falls das Netzwerk das hergibt. Die Platten würden nicht sonderlich belastet, da bei einem parallelen Lauf des Backuptools die zu lesenden Daten nach dem ersten Lesen im Cache stehen dürften.

–

Ansonsten:

rsync über den rsync Daemon zu betreiben sollte klar performanter sein als über NFS. Hier ist ein kleine Beispielkonfiguration, wie ich sie (nur für den Transport von ein paar Dateien) verwende. Die Konfiguration sollte als Start dienen können:

Auf dem Server, /etc/rsyncd.conf:

# /etc/rsyncd.conf

# Minimal configuration file for rsync daemon
# See rsync(1) and rsyncd.conf(5) man pages for help

# This line is required by the /etc/init.d/rsyncd script
pid file = /var/run/rsyncd.pid
use chroot = yes
read only = yes

# Simple example for enabling your own local rsync server
#[gentoo-portage]
#	path = /usr/portage
#	comment = Gentoo Portage tree
#	exclude = /distfiles /packages

max connections = 5
uid = nobody
gid = nobody

hosts allow = 192.168.172.0/24 10.8.19.0/24
hosts deny  = *

[data]
path=/disk1/rsync
comment=fuer Uebertragungen

[data-in]
path=/disk1/rsync-in
comment=fuer Uebertragungen
read only=no

Mein Server heißt aus historischen Gründen lotte 😎 .

Vom Client:

rsync --list-only rsync://lotte/data
rsync -av --progress --partial rsync://lotte/data .

–

Alternative:

An Deiner Stelle würde ich mir das Tool http://www.storebackup.org/ ansehen. (Klick auf 'Startseite des Projekts') Es ist bei ubuntu in der Distribution enthalten. Es beinhaltet dürfte für Dich folgende Vorteile gegenüber rsync bedeuten:

- kürzere reine Backup-Zeit, falls Du die Option lateLinks / lateCompress verwendet (das allererste Backup dauert aufgrund von Kompression allerdings idR. sehr lange)

- benötigt eventuell deutlich weniger Platz im Backup, da die Daten komprimiert werden können

- es beherrscht Deduplikation mit festen Blockgröße, was Dir bei Datenbanken oder VMs sehr viel Platz (und Zeit) sparen kann, wenn Du es richtig anfängst (bzw. anfangen kannst)

- Änderungen in Pfaden oder Dateinamen (ohne Datenänderungen) bedeuten keinen zusätzlichen Platz im Backup

(- Es gibt die Möglichkeit der Integrationsprüfung des Backups (dauert lange). Die aktuelle Version ist da nicht brauchbar, die nächste, die bald kommt schon.)

Grüße, ixo

ixo schrieb:

Ich würde darüber nachdenken, ob es nicht besser ist, das Backup einfach zweimal laufen zu lassen, falls das Netzwerk das hergibt. Die Platten würden nicht sonderlich belastet, da bei einem parallelen Lauf des Backuptools die zu lesenden Daten nach dem ersten Lesen im Cache stehen dürften.

Hallo,

hier muss ich anmerken, dass besser wäre die Backups nicht gleichzeitig sondern im zeitlichen Wechsel auf die Backup Server zu machen.

Tag 1 --> Backup Server 1
Tag 2 --> Backup Server 2
Tag 3 --> Backup Server 1
...

Oder auch vormaittags-->Backup Server 1 und nachmittags-->Backup Server 2.

Ist natürlich auch eine Möglichkeit. Es hängt von seinen Anforderungen / Möglichkeiten ab.

Übrigens habe ich mich unklar ausgedrückt: Ich meinte zwei Backups zu den beiden Servern gleichzeitig anzustarten.

Aber wie schon geschrieben - was optimal wäre, ist mit den bekannten Fakten kaum zu beurteilen.

Grüße, ixo

Hallo.

Ich möchte euch hier mal das Ergebnis eines Test posten. Diesen Test habe ich bisher zweimal mit gleicher Datenmenge durchgeführt. Beide Tests lieferten die gleichen Ergebnisse im Hinblick auf die Übertragungsrate.

Der verwendete Befehl lautete

1

time rsync /media/backupserver/Quellverzeichnis Backupserver2::backups

Auf Backupserver2 wurde RSYNC als Deamon gestartet. Von Backupserver1 wurde das Verzeichnis /media/backupstorage/Quellverzeichnis via rsync auf Backupserver2 repliziert. Dem RSYNC Befehl auf Backupserver1 wurde dabei der time Befehl vorangestellt.

sent 529882624908 bytes received 56271410 bytes 33315870.64 bytes/sec total size is 531788511912 speedup is 1.00 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1060) [sender=3.0.7]

real 265m6.240s user 35m28.200s sys 27m16.860s

Aus dem Ergebnis lassen sich folgende Erkenntnisse ableiten.

Die reale Datenübertragungsrate beträgt 32 MB/s und liegt damit weit unter den mit iperf ermittelten Werten. Ein du -sh Quellverzeichnis auf Backupserver1 ergab, dass das Quellverzeichnis 20 GByte belegt. Beim kopieren auf Backupserver2 werden nun jedoch nicht die Hardlinks kopiert, sondern für jedes Unterverzeichnis (01-31) werden sämtliche Daten kopiert, was zum dem ca. 30-fachen Datenvolumen führt.

Nach einem Tipp hier aus dem Forum habe ich auch einmal folgende Schreibweise des rsync commands versucht:

1

rsync -av /media/backupstorage/Quellverzeichnis rsync://user@Backupserver2/backups

Die Übertragungsrate konnte dadruch jedoch nicht gesteigert werden.

Die Geschwindigkeit finde ich nicht wirklich überragend. Da haben wir zwischen anderen Server via NFS schon wesentlich höhere Geschwindigkeiten (55 - 70 MB/s) geschafft.

Ich vermute den den Flaschenhals momentan bei der Schreibgeschwindigkeit des Software-RAID 5 auf dem Zielserver. Jedoch weiss ich nicht, wie ich die Schreibgeschwindigkeit ermitteln soll. Kann ich ein hdparm -w /dev/md0 ohne Datenverlust ausführen, oder werden dabei Daten auf dem Volume überschrieben?

MfG

Tronde

Tronde schrieb: Kann ich ein hdparm -w /dev/md0 ohne Datenverlust ausführen, oder werden dabei Daten auf dem Volume überschrieben?

keine Ahnung. Die man-page von hdparm sagt:

      -w     Perform a device reset (DANGEROUS).  Do NOT use this option.  It
              exists for unlikely situations where a reboot might otherwise be
              required to get a confused drive back into a useable state.

Kannst ja berichten 😈

Die Performance hängt natürlich auch vom Dateisystem und von der Größe der zu schreibenden Dateien ab. Der einfachst Test wäre mit dd ein große Datei zu schreiben. Das Ergebnis sagt dann natürlich wenig über kleine Dateien aus. Ansonsten gibt's z.B. Benchmarks wie iozone oder bonnie++.

Grüße, ixo

Tronde schrieb:

u1000 schrieb:

Hallo Tronde,

Wieso NFS ? Ist das ggf der Flaschenhals ? Auf dem Server sollte rsync als daemon laufen, und auf Client Seite läuft der rsync Backup Prozess (oder umgekehrt). So braucht mann kein NFS.

rsync über smb oder nfs ist der falsch weg.

Hi.

Das verstehe ich nicht ganz. Ich benutze NFS, da ich die Daten ja irgendwie über das Netzwerk kopieren muss. Benutzt rsync ein eigenens Protokoll zur Netzwerkübertragung wenn ich einen rsync daemon verwende?

Hast du evtl. eine Quelle wo die Konfiguration eines rsync daemons erklärt wird, bevor ich jetzt wild drauf los suche?

1
2
3
4
5

vom Client aus:
rsync -options  /source/folder/ user@BackupServer:/backup/folder
oder
vom Server aus:
rsync -options  user@Client:/source/folder/ /backup/folder

Steht in 'man rsync'.

So kann man mit rsync die Daten in alle Welt kopieren, auch auf den Backupserver oder umgekehrt, der Server holt sich das ab.

Mit der Option '-e ssh' geht das auch mit SSH und man benötigt kein Passwort, wenn SSH entsprechend konfiguriert ist.