Probleme mit Backup (dump)

[arcdes]

Hallo zusammen,

ich habe einen FreeBSD-Server, der als Domaincontroler dient (OpenLDAP, Samba). Das funktioniert auch alles wunderbar, doch leider habe ich Probleme ein Backup über das Netzwerk zu fahren.

Zur Situation:
FreeBSD 7.0 Release p1
zu sichernde Daten: ca. 200 GB ( /, /var und /usr)
Backup muss im laufenden Betrieb erstellt werden
Backup mittels dump
Backupziel: NAS (Buffalo TeraStation Pro II)
Netzwerk: Uni-Netzwerk (alles im selben Gebäude; läuft jedoch über mehrere Switches)

Wie das Backup durchgeführt wird:
Ein Skript mountet (mount_smbfs) eine (Samba-) Freigabe auf der TeraStation nach /mnt und führt anschließend ein Level0-Dump auf die Freigabe aus.

Das Problem:
Es funktioniert zuerst alles wunderbar. / und /var, also recht kleine Partitionen werden stets zuverlässig gesichert.
Dann kommt die große /usr-Partition. Nach unterschiedlich langer Zeit, bricht dann die dump-Sicherung ab. Bestes Ergebnis waren bisher knapp 90%, schlechtestes 7%.

Zuerst kommen ein paar (3-5) Meldungen à la

smb_iod_recvall: drop resp with mid 31454

dann lese ich im Logfile

DUMP: dumping (Pass IV) [regular files]
...
DUMP: 88.09% done, finished in 3:52
DUMP: Broken pipe
DUMP: The ENTIRE dump is aborted.

Bisherige Fehlersuche:

• Das Problem trat auch schon bei FreeBSD 6.2 auf, scheint also nicht an dem Upgrade auf 7.0 zu liegen.

• Ich habe die Firmware der TeraStation auf den neuesten Stand gebracht (Logfiles der TeraStation melden allerdings keine Fehler).

• Ich habe die TeraStation direkt an eine zweite Netzwerkkarte des Servers angeschlossen. So entstehen keine Fehler! Backup läuft durch!

• Mit dem Schalter -I wollte ich die Fehlertoleranz der dump-Sicherung erhöhen (Standard: 32 Lesefehler). Leider unterstützt FreeBSD das nicht.

Kennt jemand diese Probleme und weiß eine Lösung?
Gibt es vielleicht eine bessere und schnellere Methode eines Level0-Backups?

Bin für jeden Tip sehr dankbar! :-)

arcdes

 

[CommanderZed]

Bisherige Fehlersuche:

• Ich habe die TeraStation direkt an eine zweite Netzwerkkarte des Servers angeschlossen. So entstehen keine Fehler! Backup läuft durch!

Kannst du dir ganz sicher sein das es auf dem weg kein Problem gibt? Evtl. Ein defekter Switch, Kabel oder sowas?

 

[nakal]

Also, der Erfahrung nach würde ich sagen, dass es eher nicht an dump liegt, sondern an der Verbindung oder dem unheiligen Samba-Schrott.

Du kannst ja versuchen, das Backup nach /dev/null zu machen. So kannst Du dump, als Verursacher ausschließen. Ich mache dump per ssh und ich hatte noch keine Probleme damit.

 

[arcdes]

Vielen Dank für die schnellen Antworten :-)

Kannst du dir ganz sicher sein das es auf dem weg kein Problem gibt? Evtl. Ein defekter Switch, Kabel oder sowas?

Jein. Es gab Netzwerkprobleme. Die Netzwerktechniker haben diese aber (angeblich) behoben (lag an den Security-Einstellungen der Switchs). Seit dem läuft alles eigentlich problemlos. Das Problem liegt wahrscheinlich daran, dass die ganze Backup-Geschichte so lange dauert. 24 Stunden sinds schon.

Was mich wundert sind diese komischen Samba-Fehlermeldungen à la

smb_iod_recvall: drop resp with mid 31454

Die treten auch bei einem anderen Server (auch FreeBSD) auf, bei dem ein Level0-Dump nur 3 Stunden dauert (dort läuft das Backup aber dennoch durch).
Über diese Fehlermeldungen habe ich leider bei Google etc. nichts brauchbares gefunden. Scheint sehr selten aufzutreten.

Leider müssen Server und Backupziel in getrennten Gebäudeteilen sein (aus Sicherheitsgründen; Brand etc.). Vielleicht muss die Backup-Strategie geändert werden, was aber sehr ungünstig wäre...

@nakal: dump schließe ich eigentlich ebenfalls als Fehlerquelle aus, sonst würde es bei der Direktverbindung auch Probleme geben.

Ich vermute, dass die Sambaverbindung etwas empfindlich ist. Gibt es da irgendwelche (versteckten) Feineinstellungen?

Vielleicht hat ja jemand noch eine Idee? Dankeschön :-)

 

[nakal]

Ich erinnere mich, dass smbfs etwas schrottig war, als ich es ausprobiert habe. Das konnte damals das System ziemlich durcheinanderbringen bis hin zu einem Panic.

Wenn Du unbedingt auf ein Samba-Share Backups ziehen willst, dann versuch es lieber mit dem "richtigen" Samba aus den Ports. Leider weiß ich jetzt keinen Weg, um aus einer Pipe auf ein Share zu speichern.

 

[arcdes]

Problem gelöst!

Hallo,

falls jemand mal das gleiche Problem hat, hier eine Lösung, die bei mir funktioniert hat:

Einfach beim Befehl mount_smbfs zwei zusätzliche Optionen verwenden:

-R retrycount
How many retries should be done before the SMB requester 
decides to drop the connection.  Default is 4.

Habe ich testweise bei mir auf 50 gestellt.

-T timeout
Timeout in seconds for each request.  Default is 15.

Habe ich testweise bei mir auf 720 gestellt (180 war zu wenig).

Der ganze Befehl lautet dann z.B.:

mount_smbfs -R 50 -T 720 -I XXX.XXX.XXX.XXX //user@TeraX/backup /mnt

Mit diesen Einstellungen läuft ein Backup problemlos durch (bis jetzt 2 Testläufe), auch wenn länger als 24 Stunden dauert. Danke an alle die geantwortet haben :-)

Viele Grüße
arcdes