[Eisfair] Fehlermeldung beim Einsatz von rsync - NEU

[Jürgen Witt]

Hallo Hilmar,

Am 13.03.2019 um 18:22 schrieb Hilmar Böhm:
>
> ...ich verstehs noch nicht:
> 
> - Der Backupserver (eis) hat: 10.20.3.100 ?

genau

> - Der Prod.Server (debian/eis) hat: 10.20.3.101 ?

auch richtig

> Das Backup-Script wird auf dem Backup-Server gestartet?!

ja

> Einer der rsync-Befehle lautet:
> rsync -avzu --delete 10.20.3.101:/public /data >/var/log/rsync-public_log
> 
> /data ist ein Verzeichnis auf dem Backup-Server und eine Partition eines 
> Software-RAID-Verbunds

ja

> Was ist (fstab/BackupServer):
> 10.20.3.100:/mountpoint/data /backup nfs defaults,noauto 0 0

das ist eine weitere eingehängte Festplatte auf die die herüber 
gezogenen Daten in einer Rotationssicherung gesichert werden. Habe ich 
hier schon einmal vor längerer Zeit ausführlich in einem Howto (Backup 
mit Snapshot auf Eisfair-1) beschrieben.

> Da ist offensichtlich ein NFS-Mount im Spiel. Hat der was mit dem o.g. 
> rsync zu tun, evtl. auch nur indirekt?

Nein, die in der Nacht 23:30 Uhr herüber gezogen Daten werden am 
nächsten Vormittag auf dem Backup-Server in meine Rotationssicherung auf 
einer weiteren internen Platte übernommen.

> Kann es sein, dass (auf dem Produktions-Serve) eine Datei oder ein 
> Verzeichnis in dem Baum /public/TDAMP/ defekt ist. Was sagt fsck dazu 
> (Hast Du aber sicherlich schon gemacht).

Daran habe ich natürlich auch schon gedacht, aber noch nicht gemacht. In 
der Praxis wird von 6:30 Uhr bis oft nach 22:00 Uhr gearbeitet und um 
23:30 Uhr werden die Daten per rsync abgeholt. Ich finde kein 
Wartungsfenster. Ein 1TB großes Hardware-Raid-1 ist ja auch nicht 'mal 
eben durch getestet.

In diesem TDAMP-Verzeichnis ist eine Zahnarztpraxis-Software, die rein 
dateibasiert angelegt ist. Diese zerlegt sich regelmäßig und keiner kann 
mehr arbeiten. D.h. ich ziehe mir dann den TDAMP-Ordner per Freefilesync 
auf einen Windows-PC, lasse die Dateiüberprüfung drüber laufen und 
schiebe die reparierten Dateien per FreefileSync wieder zurück auf den 
Linux-Server (das Produktiv-System). Das sind dann immer so 10 GB die 
hin und her geschoben werden. Ein Lesefehler wird mir von Freefilesync 
nicht ausgegeben.

Gruß
Jürgen
> Man könnte mal zum Test auf dem Produktionsserver den gesamten /public - 
> Tree aufs Null-Device kopieren, um zu sehen, ob es ein Problem mit der 
> rsync-Quelle  gibt. Etwa:
> # cp -a /public /dev/null

Bei einem zu über 60% belegtem /-Verzeichnis (der Produktiv-Server hat 
keine Extra-Datenpartition) auf dem dann auch public liegt, dürfe der 
Vorgang auch nicht 'mal eben gemacht sein. Aber Du hast natürlich Recht.

Danke
Jürgen