Hallo Leute,
mit einem Shellscript mache ich ein Backup: 
#!/bin/bash
# Doku sichern
#mounten des serversxy.de nach /mnt/privat-fs
echo "***************** Doku sichern ******************"
sudo mount.cifs //Serverxy.de/userverzeichnis/ /mnt/privat-fs/ -o noserverino,vers=1.0,uid=1000,gid=100,rw,user="ichderuser",password="geheim"

rsync -rluvh --delete --numeric-ids --exclude=.Trash-1000 --exclude=lost+found /mnt/Doku/  /mnt/privat-fs/Doku/
echo "************* Doku wurde gesichert **************"
sudo umount /mnt/privat-fs
Das funktioniert soweit sehr gut. Aber, wenn es sehr viele kleinere Dateien sind die neu übertragen werden müssen, dann wird die Übertragung unterbrochen. Ab ca. 35MB.
Ein Gespräch mit einem IT-Mann der für den Server zuständig ist, sagte das kenne er so noch nicht.
Dann hat er mal das Gleiche gemacht und hatte tatsächlich den gleichen Fehler gehabt. (Der hatte auch zufällig Arch-Linux).
Ein Testen nach vers=2.0 oder vers= weglassen hat nicht funktioniert. Muss vers=1.0 bleiben. (Alter Server mit alten Windoof??).
Die Fehlermeldung war wie folgt: 
Mai 07 11:38:00 zat264 kernel: CIFS: Attempting to mount //Serverxy.de/userverzeichnis/
Mai 07 11:38:00 zat264 kernel: CIFS VFS: Autodisabling the use of server inode numbers on \\Serverxy.de\userverzeichnis.
Mai 07 11:38:00 zat264 kernel: CIFS VFS: The server doesn't seem to support them properly or the files might be on different servers (DFS).
Mai 07 11:38:00 zat264 kernel: CIFS VFS: Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.
Die Option noserverino habe ich nachträglich zum Mounten hinzugefügt, so das die eine Meldung jetzt weg bleibt. Auch auf Anraten des IT-Manns.
Brachte aber keine Änderung in der Verbindungsstabilität.
Kennt Jemand von Euch das Phänomen? Gibt es hier schon einen Lösungsansatz?

Der IT-Mann sagte mir dann noch, dass der Server ca. im August 2019 neu aufgesetzt wird. Villeicht läufts dann mit vers=3.1.1 .
Als Schnellhilfe meinte er dann, ich könnte es mit smbclient machen. Das hat er mal mit ca. 10000 Dateien ausprobiert und es hat bei ihm zu keiner Serverunterbrechung geführt.
Gut, ich habe mich mit smbclient mal befasst.
Mit 
smbclient //Serverxy.de/userverzeichnis -W Domeinname-Workgroup -U ichderuser%geheim -c 'recurse; prompt; lcd /home/gl; cd ichderuser; mput temp'
habe ich dann mal das temp Verzeichnis in den Server übertragen können.
Frage,
Werden die Daten erneut übertragen auch wenn diese schon vorhanden sind wenn ich den Befehl widerhole oder wird vorher verglichen was neu übertragen werden muss?
Weitere Frage,
Wie könnte man smbclient und rsync kombinieren?
Also den Mechanismus wie es bei rsync ist, nur veränderte oder neuere Daten übertragen, nicht mehr lokale Daten auch auf dem Server wieder löschen.

Uff,
das wars erst mal.
Ich hoffe ihr müßt nicht zuviel knobeln.
Ich als Antinetzwerker habe mich einfach kaum bisher damit befassen müssen. Daher frage ich doch gleich mal die Spezialisten unter Euch.

Ich bedanke mich im Voraus!!!

Gruß aus DN
Greg
Was sagen denn die Server Logfiles?
Ist es vielleicht möglich, dass der Prozess irgendwelche speziellen Dateien (FIFOs, Sockets) synchronisiert, die den Server aus dem Tritt bringen?
Ich selbst habe sowas noch nicht erlebt. Benutze zuhause den smb.service von Samba um von meiner Windows 10 Kiste auf meinen Homeserver zugreifen zu können.
Bezüglich der Protokollversionen kannst du ja mal durchtesten, welche unterstützt werden. Ich würde die jüngste nehmen.
Zudem ist Version 1.0 von SMB für EternalBlue (WannaCry, und anderer Mist) anfällig.
OT: Melde dich mal bitte per E-Mail bei @matthias.
Hallo schard,
danke für deine Antwort!!
Was den Server betrifft, da bekomme ich keinerlei weitere Infos. (Bis jetzt, muss ich mal versuchen da nachzubohren). Die IT-Leute sagen nur das der im Sommer neu aufgesetzt werden soll.
Sozusagen et is wie et iss. Aber ich versuche den IT-Mann mal zu fragen wegen der Serverlogs. Wenn ich die bekomme schreibe ich die natürlich hier rein.
Mit den Versionen von 1.0 bis 3.1.1 habe ich schon durchgetestet. Nur 1.0 funktioniert.
Ich bin ja schon froh, dass dem IT-Mann bei seinem Rechner auch zu Verbindungsunterbrechung kommt.
Mittlerweile habe ich mal per smbclient ca. 60000 kleinere Daten insgesamt ca. 110MB übertragen. Das hat funktioniert. So wie der IT-Mann es schon angeraten hatte, als Workaround.
Zum Glück kommt es nicht allzu häufig vor, dass ich soviel auf einmal übertragen muss. Von dem her kann ich damit leben.

So, mal sehen was ich noch herausbekommen kann.
Besten Dank nochmal.
Ich schreibe gleich ne Mehl an Matthias.
Bis denn..
Gruß aus DN
Greg
Ich hatte das vor einigen Jahren auch mal, als ich per rsync initial einen großen Datenbestand vom Client (Linux oder BSD?) zu meinem damaligem Server(BSD) im LAN übertragen habe. Nach ungefähr der gleichen Datenmenge wie bei Dir gab es dann auch Probleme, soweit ich mich erinnere ebenfalls als viele kleine Dateien übertragen werden sollten. An die Symptome (ob Abbruch, Segfault oder Stocken) kann ich mich nicht mehr genau erinnern.

Ich habe dann ein anderes Tool zum Syncen verwendet, damit ging es dann problemlos
(cpdup, kommt aus dem BSD-Lager, kann allen "Standardkram" den rsync auch bietet (inkl. Hardlink-Kopie als Ziel für effizientes Generationenbackup. Es gibt auch einen Linux-Port, im AUR ist das Paket verwaist, ich habe k.A. ob es aktuell noch baut/funktioniert). Rsync hat zudem bei vielen BSD-Leuten nicht den besten Ruf bzgl. Stabilität, "Seiteneffekten" und Code-Qualität. Was ich im Detail nicht beurteilen kann, lediglich durch obige Erfahrung.

Generell: viele kleine Dateien sind der Bandbreite Tod, gerade wenn noch ob der gleichzeitigen Menge exorbitant großer "Aufwand" für Transport(Netzprotokoll) und Ablage(Dateisystem) betrieben werden muß. Die Systemlast steigt dann gleichzeitig oft so an, das das System / die Systeme quasi "unbenutzbar" sind aus Sicht des Userprozesses, bishin zum ggf. Abbruch des Prozesses(Timeouts) bzw. der Netzverbindung(Netzprotokollebene oder Netzwerkstack). Wiederanforderungen(Retransmissions) steigern das Erscheinungsbild ggf. noch.
Insofern kann die Wahl des Werkzeugs (hier rsync, was ja zusätzlichen Aufwand bzgl. evtl. Synchronisation betreiben muss, suboptimal sein im Gegensatz wie z.B. einem einfachen cp).
Greg schriebAber ich versuche den IT-Mann mal zu fragen wegen der Serverlogs. Wenn ich die bekomme schreibe ich die natürlich hier rein.
Ich bin ja schon froh, dass dem IT-Mann bei seinem Rechner auch zu Verbindungsunterbrechung kommt.
Mittlerweile habe ich mal per smbclient ca. 60000 kleinere Daten insgesamt ca. 110MB übertragen. Das hat funktioniert. So wie der IT-Mann es schon angeraten hatte, als Workaround.
Du schriebst ja in deinem ersten Beitrag, daß die rsync-Übetragung ab Punkt X "unterbrochen" wird. Der Prozeß steigt aber nicht mit einer Fehlermeldung aus? Bei lediglicher "Unterbrechung (passiert nix mehr!)": Sicher, daß nach einer vetretbaren Zeitspanne die Übertragung nicht doch weitergeht? Und: wie beendest du diesen Zustand? Brichst du das Skript (rsync) per STRG-C oder kill ab?
Deine geposteten Meldungen treten ja wohl sofort bei Start deines Skripts auf: die CIFS/SMB-Mountmeldung und die 3 anderen Zeilen durch den Rsync-Vorgang (die besagen, daß aufgrund des Netzprotokolls bzw. Zieldateisystems bestimmte Eigenschaften nicht gesynct werden können).
Beim "Unterbrechen" ab dem ominösen Zeitpunkt X gibt es aber keine (weiteren) Meldungen? Hast du zu dem Zeitpunkt mal in dein Journal geschaut, ob dort Einträge bzgl. des rsync-Prozesses bzw. zu CIFS-Verbindung bzw. (Kernel)Trap bzgl. des Netzkarte auftauchen?

So wie ich deine Ausgangslage verstanden habe, wäre es ja unerheblich gewesen ob du zur Übertragung nun rsync oder cp (oder letztendlich mput) verwendest - der Großteil der Daten mußte ja wohl sowieso initial (neu) übertragen werden.
Da wäre es ja jetzt mal interessant, den gleichen Rsync-Lauf nochmal zu tätigen, ob dieser nun bei seinem "Hauptanliegen" (Synchronisation) auch abbricht/unterbricht.

An deinen Rsync-Parametern sehe ich kein Problem (eventuelle Hardlinks, FIFOs, Devices) werden per se nicht übertragen (und sind in einem Doku-Verzeichnissbaum auch weniger zu erwarten). Unsicher bin ich mir ad hoc bei den Softlinks (Parameter -l, kleines L): Ich weiß nicht, ob CIFS/SMB bzw. NTFS etwaig vorhandene Links korrekt überträgt. Das Defaultverhalten von rsync bzgl. Softlinks ist AFAIK diese einfach zu ignorieren, also ohne explizites -l. Das würde ich ggf. mal weglassen (oder per find in deinem Quell-Verzeichnis rausfinden, ob darin überhaupt Softlinks vorhanden sind die dann zu einem eventuellen Problem werden könnten).
Ebenfalls könnte ein zweites Verbose-Argument (also -vv) hilfreich sein.

Was weiterhin interressant wäre (bzw. gewesen wäre):
Von deinem Client aus ein: 
netstat -s
(bzw. und/oder) ein: ethtool -S deinNetkartenbezeichner
und zwar einmal während des problemlosen Transfers per rsync und einmal nach/während der "Problemphase" (also wenn es stockt, abbricht, explodiert,...).
Hintergrund: in dem Fall hat es IMHO weniger was mit gewähltem Netzprotokoll bzw. (Ziel)Dateisystem zu tun als "Ursache". Selbst rsync als Werkzeug muß es nicht sein, außer ggf. das durch den Vorgang "Synchronisation" immens hohe Anzahl an (ggf. fragmentierten) Datenpaketen zwischen den Netz-Stacks ausgetauscht werden müssen. "Billige" Hardware (Netzkarten) stoßen da oftmals an ihre Grenzen. Ebenfalls bist Du ja zum Problemzeitpunkt evtl. nicht allein auf dem Server, sodaß Antwortpakete auf deine Pakete so zeitversetzt zurückkämen daß vorher ein Timeout(TTL) greift und das ganze Paket nochmal auf die Reise geht.

Wenn du die Möglichkeit findest, das Problem nochmal reproduzierbar nachzustellen (das wird die Schwierigkeit sein), dann könntest Du auf deiner Client-Seite nochmal an den IP-Netzwerkparametern "schrauben", ob sich da ein Unterschied ergäbe. Und zwar konkret an den Werten: 
(Das sind eigentlich die Standardwerte)
# sysctl -a |grep -e sack -e timestamp
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1

Timestamps und Sack würde ich mal testweise ausschalten;

# sysctl net.ipv4.tcp_timestamps=0
# sysctl net.ipv4.tcp_sack=0
# sysctl net.ipv4.tcp_dsack=0
Das wäre ein Ansatz um den "Overhead" beim Transfer per Paket etwas zu minimieren, den Vorgang also ggf. stabiler zu machen.
Hallo Gerbra,
danke für deine Antwort!!
Ich werde deine Punkte durchgehen. Kann ich aber frühstens erst Montag machen. Heute komme ich nicht mehr dazu.

Hallo Schard,
Hier ist noch eine Info vom IT-Mann zwecks Logfiles:
===
> Momentan ist der Speicher eine Storagelösung von Netapp. Die sind da leider
> etwas geizig mit Logging, da kann ich nichts rausholen. In der
> Samba-Implementierung von Netapp sind auch Bugs drin (Netapp kennt diese und
> ignoriert sie bewusst), deshalb klappt von Linux aus auch nur SMB v1.
> Wie gesagt, mit der Umstellung auf das neue Storagesystem sollte das dann
> deutlich besser werden.
===
Netapp? Damit kann ich jetzt nichts anfangen, ausser et iss wie et iss.
Sieht so aus, dass man einfach abwarten muss bis der neue Server hoffentlich diese Probleme nicht mehr hat.
Da stecken halt noch andere Leute oder Firmen drin, die einfach nichts machen wollen.
Bei uns gibt es wohl zu wenig Linuxuser die das Problem sicherlich alle haben. Eine Abteilung kenne ich noch die fast alle Linux haben. Allerdings haben die garantiert ihren eigenen Server.


Ein schönes WE
Gruß aus DN
Greg
IT-Typ schrieb In der Samba-Implementierung von Netapp sind auch Bugs drin (Netapp kennt diese und ignoriert sie bewusst), deshalb klappt von Linux aus auch nur SMB v1.
Wie gesagt, mit der Umstellung auf das neue Storagesystem sollte das dann deutlich besser werden.
Dann würde ich ehrlich gesagt keinen Aufriss machen, sondern auf das Update warten. :/
Jetzt habe ich doch noch die Werte auslesen lassen die GerBra meinte: 
# sysctl -a |grep -e sack -e timestamp
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.netfilter.nf_conntrack_timestamp = 0
[root@zat264 gl]# netstat -s
Ip:
    Forwarding: 2
    208792 total packets received
    84534 with invalid addresses
    0 forwarded
    0 incoming packets discarded
    104638 incoming packets delivered
    80757 requests sent out
    20 outgoing packets dropped
Icmp:
    49 ICMP messages received
    0 input ICMP message failed
    ICMP input histogram:
        destination unreachable: 40
        echo requests: 4
        echo replies: 5
    49 ICMP messages sent
    0 ICMP messages failed
    ICMP output histogram:
        destination unreachable: 40
        echo requests: 5
        echo replies: 4
IcmpMsg:
        InType0: 5
        InType3: 40
        InType8: 4
        OutType0: 4
        OutType3: 40
        OutType8: 5
Tcp:
    951 active connection openings
    138 passive connection openings
    8 failed connection attempts
    15 connection resets received
    2 connections established
    103311 segments received
    86099 segments sent out
    102 segments retransmitted
    0 bad segments received
    122 resets sent
Udp:
    1252 packets received
    40 packets to unknown port received
    0 packet receive errors
    1300 packets sent
    0 receive buffer errors
    0 send buffer errors
UdpLite:
TcpExt:
    577 TCP sockets finished time wait in fast timer
    290 delayed acks sent
    1 delayed acks further delayed because of locked socket
    Quick ack mode was activated 158 times
    82981 packet headers predicted
    9217 acknowledgments not containing data payload received
    16414 predicted acknowledgments
    TCPSackRecovery: 7
    24 congestion windows recovered without slow start after partial ack
    TCPLostRetransmit: 42
    7 fast retransmits
    TCPTimeouts: 78
    TCPLossProbes: 26
    TCPLossProbeRecovery: 11
    TCPBacklogCoalesce: 16
    TCPDSACKOldSent: 158
    TCPDSACKRecv: 12
    62 connections reset due to unexpected data
    5 connections reset due to early user close
    6 connections aborted due to timeout
    TCPDSACKIgnoredNoUndo: 1
    TCPSackShiftFallback: 7
    TCPRcvCoalesce: 12431
    TCPOFOQueue: 45
    TCPSpuriousRtxHostQueues: 2
    TCPAutoCorking: 1050
    TCPWantZeroWindowAdv: 1
    TCPSynRetrans: 24
    TCPOrigDataSent: 34334
    TCPHystartTrainDetect: 6
    TCPHystartTrainCwnd: 112
    TCPWinProbe: 10
    TCPKeepAlive: 669
    TCPDelivered: 35045
IpExt:
    InBcastPkts: 5683
    OutBcastPkts: 6
    InOctets: 113589918
    OutOctets: 23510731
    InBcastOctets: 453243
    OutBcastOctets: 468
    InNoECTPkts: 212013
[root@zat264 gl]# 
[root@zat264 gl]#

[root@zat264 gl]# ethtool -S enp3s0
NIC statistics:
     tx_packets: 84747
     rx_packets: 417131
     tx_errors: 0
     rx_errors: 0
     rx_missed: 0
     align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 105130
     broadcast: 296855
     multicast: 15146
     tx_aborted: 0
     tx_underrun: 0
[root@zat264 gl]#
Ich danke Euch nochmals, ich denke das kann man als ungelöst so stehen lassen.
Nee, ich trag das jetzt nicht oben als ungelöst rein.
Wenn ich dran denke, werde ich das Nachtragen wenn der neue Server drin ist.

Gruß aus DN
Greg

Nachtrag:
Ähh, das ist jetzt der Fall wo die Serverunterbrechung nicht da war. Ich mache mal am Montag das Gleiche, wenn der Server sich ausgeklinkt hat. Und ich werde nochmal GerBras Punkte Schritt für Schritt durchgehen.
Schon fast amüsant (wenns nicht so traurig wär) dass es immer noch Firmen gibt die sich an SMBv1 festklammern. AVM als prominentes Beispiel.
Das ist schon gut 30 Jahre alt. Microsoft listet das schon seit 2012 als Deprecated, bei neueren Windows10 Versionen muss es explizit installiert werden (glaube seit 1709).
Ist für zig Fehler/Schwachstellen bekannt...

Übrigens kennen alte WinDOSer das SMB-Protokol wohl noch als LAN-Manager- oder NetBIOS-Protokoll.
Da kommen bei mir die Erinnerungen an die LAN-Partys meiner Jugend wieder hoch, wo man ca 50-80% der Zeit gebraucht hat mit allen Windows Rechnern eine Netzwerkverbindung zu bekommen :p.
Später hatte ich dann auf einem alten PC dann Suse Linux mit DHCP und Samba installiert, wo es dann auch auf Anhieb klappte. Das waren noch Zeiten....
Greg schriebJetzt habe ich doch noch die Werte auslesen lassen die GerBra meinte:
...
Nachtrag:
Ähh, das ist jetzt der Fall wo die Serverunterbrechung nicht da war. Ich mache mal am Montag das Gleiche, wenn der Server sich ausgeklinkt hat. Und ich werde nochmal GerBras Punkte Schritt für Schritt durchgehen.
Diese Ausgaben von netstat/ethtool machen wirklich nur Sinn, wenn diese im Vorgang des Problems ausgelesen werden. (Der Ingeniör braucht was zum, Messen... <g>)
Die Werte werden für deinen IP-Verkehr ja seit dem PC-Boot "gesammelt". Um daraus nun konkret etwas ablesen zu können braucht es im Prinzip drei Ausgaben:
a) Vor dem Einleiten des Doku-Backups/rsync
Das wäre der Ausgangsstand.
b) Einen Lauf während rsync normal seinen Dienst tut
Damit würde man das Ansteigen bestimmter Werte (Infos+Fehler) im Normalbetrieb einschätzen können.
c) Und zum Dritten dann während deine rsync-Verbindung problematisch wird, also stockt usw.
Da könnte man dann !eventuell! rauslesen, daß neben dem normalen Anwachsen der gesendeten/empfangenen Paketen z.B. eben auch Werte steigen, die auf Fehler hindeuten.
Als Bsp. nehmen wir mal die ethtool Ausgabe:
tx_packets: 84747
rx_packets: 417131
tx_errors: 0
rx_errors: 0
tx/rx_packets wird zu jedem Zeitpunkt ansteigen, die errors bleiben während des normalen rsync bei 0 - aber steigen ggf. in der Phase der "Unterbrechung". netstat bietet da u.U. noch detailliertere Infos (wobei mir da auch nicht alles etwas sagt).

Wie bei allen "Messungen": Kann sein, daß der ganze Aufwand darauf hinausläuft: Wir haben viel gemessen, und ja - da ist wohl irgendein Problem, ich kann's beweisen.... ;-)

Schards Hinweis ist IMHO erfolgreicher: Wenn der "Server" (oder was es auch ist) neu aufgesetzt wird, dann hast du zumindest eine mögliche Ursachenseite weniger, wenn es weiterhin das Problem gäbe. V.a. eine Ursachenseite, die du ja nicht wesentlich kontrollieren/verändern kannst.
Galde75 schriebSchon fast amüsant (wenns nicht so traurig wär) dass es immer noch Firmen gibt die sich an SMBv1 festklammern....
Gerade bei dem Laden wo ich hier bin ist es besonders traurig.
Da sollten eigentlich jedemenge IT-Leute geben die sowas vermeiden könnten oder wenn der Dienst Netapp so schrottig ist, hätte ich den schon längst quittiert.
Keine Ahnung warum das so ist. Da habe ich den geringsten Einfluss drauf zumal der IT-Mann der an der besseren Quelle sitzt auch nichts machen kann.
Aber immerhin es soll sich ja was ändern.

GerBra, ich habs schon bemerkt, die Messungen logischerweise dann machen wenns klemmt. Also von dir vorgeschlagenen a, b, c Situationen.
Uuuund danke für die ausführliche Erklärung.
Bis Montag.
Gruß aus DN
Greg
Greg schrieb Da sollten eigentlich jedemenge IT-Leute geben die sowas vermeiden könnten oder wenn der Dienst Netapp so schrottig ist, hätte ich den schon längst quittiert.
Auch wenn es nichts zur Sache tut:
Das ist die Sicht eines Anwenders. Augenscheinlich wurde ja schon ein Problem erkannt und die NetApp wird ersetzt. Hier sollte man nie aus der Sicht des Endanwenders drauf schauen. Vielleicht ist es "nur ein Filer" der stressfrei an einem Abend umgezogen werden könnte. Vielleicht ist es aber auch ein Filer auf den Tools zugreifen die genau den Hostnamen/Ordnerstruktur erwarten die gegeben ist, oder Verzeichnisrechte gesetzt sind die über Jahre gewachsen sind - oder noch schlimmer - beides zusammen. Dann noch 10k-Links zwischen Tools, Dokumentation, Anwendern und weis der Geier noch was. Das alles kann durchaus dazu führen das es eben nicht nur ein Copyjob ist und durchaus zwischen "nur Bauchschmerzen" und "Missioncritical" (==viel Geld) alle Möglichkeiten beim Umzug drin sind.

Sorry, musste ich loswerden. Das ist ein täglicher Kampf zwischen IT und Anwender 🙂
Greg schriebDa sollten eigentlich jedemenge IT-Leute geben die sowas vermeiden könnten
Kenn eihc nur zu gut, aber glaub mir, das liegt nicht an der IT, sondern an den Managern. Die sehen den Preis. Darum wird eben NetApp genutzt, und uralte Server. Das ist alles nur leidlich zuverlässig (da aber hinter einer Firewall noch halbwegs vertretbar). Einzig aus Kostengründen wird noch Windows Server 2008 eingesetzt und muss überall auf den Windows 10 Clients händisch SMB-1-Support aktiviert werden.
chepaz schrieb....Sorry, musste ich loswerden. Das ist ein täglicher Kampf zwischen IT und Anwender 🙂
Ich wollte jetzt nicht auf die IT-Leute rumhacken.
Ich selber habe nicht das nötige Wissen warum gerade das benutzt wird. Das da im Hintergrund viel rumwerkelt kann ich mir schon vorstellen. Rechteverwaltung rsynckram. Mit dem IT-Mann mit dem ich kontakt hatte, der war schon hilfsbereit und wenn er gekonnt hätte, dann wäre da auch mehr drin gewesen.
Wenn aber das Problem bei netapp liegt dann kann er wohl daran nichts machen.
Für die täglichen Backups mit relativ wenigen Daten reicht es noch. Nur wenn ich ganze Projekte mal eben sichern muss, dann klemmts. Dann werde ich wohl den smbclient benutzen. Das war auch ein Tip vom IT-Mann.
Ab August ist das dann hoffentlich Geschichte.

Bis denn..
Greg
Jetzt kommt die Nachlieferung von Logdateien:
zu a Der Server ist gemountet, ohne Übertragung von Daten: 
# sysctl -a |grep -e sack -e timestamp
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.netfilter.nf_conntrack_timestamp = 0

# ethtool -S enp3s0
NIC statistics:
     tx_packets: 12369
     rx_packets: 19413
     tx_errors: 0
     rx_errors: 0
     rx_missed: 0
     align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 16694
     broadcast: 2585
     multicast: 134
     tx_aborted: 0
     tx_underrun: 0
#
zu b: Während ein Backup angestossen wurde. Geringe Dateimengen Übertragung nicht unterbrochen: 
# sysctl -a |grep -e sack -e timestamp
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.netfilter.nf_conntrack_timestamp = 0

# ethtool -S enp3s0
NIC statistics:
     tx_packets: 3691
     rx_packets: 7459
     tx_errors: 0
     rx_errors: 0
     rx_missed: 0
     align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 6981
     broadcast: 454
     multicast: 24
     tx_aborted: 0
     tx_underrun: 0
zu c: Nachdem der Server unterbrochen ist 33MB von 65MB übertragen. 
# sysctl -a |grep -e sack -e timestamp
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.netfilter.nf_conntrack_timestamp = 0

# ethtool -S enp3s0
NIC statistics:
     tx_packets: 56602
     rx_packets: 210361
     tx_errors: 0
     rx_errors: 0
     rx_missed: 0
     align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 50929
     broadcast: 151753
     multicast: 7679
     tx_aborted: 0
     tx_underrun: 0
#
Naja, meine Kenntnisse reichen jetzt nicht um da was zu sehen.
Bei der Übertragung von c habe ich mal 10min. gewartet ob da noch was kommt.
Nichts. bleibt so unterbrochen. Die Übertragung geht nicht weiter.

Nochmals Besten Dank an Euch!!
Gruß aus DN
Greg
Habe eine hoffentlich nicht allzu unbedarfte Idee dazu:

Dazu würde ich die Ausgabe von rsync auch mal loggen.
rsync.....> rsync.log
Hatte schon mal Abbrüche wg. I/O Fehlern.
Nur so, weil es immer nach 35MB passiert.
tuxnix schrieb ...Ausgabe von rsync auch mal loggen. rsync.....> rsync.log..
Hallo tuxnix,
ich danke dir!!
Mit der Option --log-file=FILE für rsync kann ich versuchen mehr raus zu bekommen.
Kann ich erst morgen machen. Bis jetzt habe ich nur das journal vom Anfangspost.

Bis morgen.
Gruß Greg

Nachtrag:
Hier sind die rsync Logdateien:
Zunächst wenn alles funktioniert ohne Serverabbruch: 
$ rsync -rluvh --log-file=/home/gl/rsync.log --delete --numeric-ids --exclude=.Trash-1000 --exclude=lost+found /mnt/Doku/  /mnt/privat-fs/Doku/
2019/05/28 11:24:13 [7622] building file list
2019/05/28 11:25:21 [7622] >f.sT...... bestellungen/Bestellungen.gnumeric
2019/05/28 11:25:55 [7622] *deleting   kicadprj/bessy_analogregler2/shapes3D/testpunkt.wrl
2019/05/28 11:25:55 [7622] *deleting   kicadprj/bessy_analogregler2/shapes3D/spectrol67x.wrl
..
..
2019/05/28 11:25:55 [7622] >f+++++++++ kicadprj/bessy_analogregler2/bessyreglerP3.dxf
..
..
2019/05/28 11:27:00 [7622] sent 18.94M bytes  received 12.49K bytes  113.15K bytes/sec
2019/05/28 11:27:00 [7622] total size is 8.49G  speedup is 448.17
Jetzt die Logdatei mit Serverabbruch Es wurde einfach ein Projekt kopiert mit ca. 170MB (DCS_kopie2). 
$ rsync -rluvh --log-file=/home/gl/rsync.log --delete --numeric-ids --exclude=.Trash-1000 --exclude=lost+found /mnt/Doku/  /mnt/privat-fs/Doku/
2019/05/28 11:30:21 [7676] building file list
2019/05/28 11:30:25 [7676] cd+++++++++ DCS_kopie2/
..
..
2019/05/28 11:30:38 [7676] >f+++++++++ DCS_kopie2/DSP_Per_Ana/H4/bessy_nachbau_2.JPG
Nach 3 min. Abbruch (strg+c). 
2019/05/28 11:33:50 [7676] rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(642) [sender=3.1.3]
2019/05/28 11:33:50 [7676] rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at io.c(504) [generator=3.1.3]
[gl@zat264 ~]$ rsync: [generator] write error: Broken pipe (32)
Gruß aus DN
Greg
Sorry, ich komme auch erst jetzt dazu mich zu melden...
Greg schriebJetzt kommt die Nachlieferung von Logdateien:
zu a Der Server ist gemountet, ohne Übertragung von Daten:
zu b: Während ein Backup angestossen wurde. Geringe Dateimengen Übertragung nicht unterbrochen:
zu c: Nachdem der Server unterbrochen ist 33MB von 65MB übertragen.
a)Die ethtool-Ausgaben sind leider bei deiner Karte nicht sehr informativ, bei meiner z.B. gibt es da viel detaillierteren Output. Sie netstat-Ausgaben wären ggf. wohl sinnvoller, da diese AFAIK uniform (also unabhängig was die Netzkarte/Modul an Infos liefert) aufbereitet werden.
Außerdem vermute ich, daß du die Ausgaben für a) und b) "vertauscht" hast, die Werte für tx-/rx-packets lassen das vermuten.
Aus den Ausgaben ist m.E. nichts Auffälliges auszulesen, einziger Wert der etwas raussticht wäre das ungewöhnlich starke Ansteigen von Broadcast-Paketen in der Anzeige bei c). Aber erhöhte Broadcasts sind gerade in CIFS/SMB-Netzwerken nicht zwangsläufig etwas, was auf einen "Fehler" (außer im Design!, scnr) hinweist bzw. mit deinem Symptom ursächlich zusammenhängen mag.

b) Noch was du den Aktionen mit sysctl:
Da hast du offenbar was falsch verstanden.
# sysctl -a |grep -e sack -e timestamp
Hier ändert sich im laufenden Betrieb *nichts*, was ein fortwährendes Wiederholen anders anzeigen würde. Die Werte, die angezeigt werden sind die Default-Werte, mit denen der Kernel/IP-Stack arbeitet. Bei dir nichts anders als bei mir auch, also SACK und Timestamps sind eingeschaltet (1 statt 0).
Was ich damit in meinem Post #4 unten vorschlug war, diese Werte nun mal testweise/temporär zu ändern.

Du hast ja (dein letztes Post mit der DCS_kopie2) ggf. eine Situation, bei der du den rsync-Abbruch reproduzieren kannst. Der Abbruch erfolgt ja *mit* den gesetzten Default-Werten. Mein Vorschlag war/ist nun, nach einem Abbruch einfach einen erneuten Kopiervorgang zu starten, aber diesmal nachdem du als root SACK und Tiemstamps ausgeschaltet hast, eben mit:
# sysctl net.ipv4.tcp_timestamps=0
# sysctl net.ipv4.tcp_sack=0
# sysctl net.ipv4.tcp_dsack=0
Diese Änderungen greifen sofort und bleiben maximal bis zu nächsten Boot (wenn du sie nicht zurück änderst). Es wäre eine Möglichkeit, daß der nun folgende rsync-Lauf nun nicht abbricht. Ich schätze mittlerweile die Wahrscheinlichkeit zwar als gering ein, aber ein Versuch ist es wert...

c) Logfile aufgrund des Posts von tuxnix
Nur damit ich dein Vorgehen auch halbwegs verstehe:

Du kannst also aktuell zwei Situationen "erschaffen":
1. "Zunächst wenn alles funktioniert ohne Serverabbruch"
Hier lässt du rsync deine Doku-Quelle zum Ziel auf dem CIFS-Mount los. Das Ziel enthält aber nun schon nahezu alles, was deine Quelle auch hat, da du die initialen Nutzdaten ja per smbclient/mput schon kopiert hast. rsync muß hierbei also lediglich Sync-Daten austauschen/prüfen, zumindest entnehme ich das deinen Endausgaben (sent 18.94M bytes received 12.49K bytes 113.15K bytes/sec). Hierbei läuft rsync also durch.
2. "Jetzt die Logdatei mit Serverabbruch "
Hier hast du wohl in deinem Quell-Verzeichnis einfach einen Ordner zuätzlich kopiert. Der anschließende rsync-lauf bleibt hängen, da er ja (neue) Nutzdaten übertragen muß und nicht nur Sync-Daten. Und hier ist dann wieder das Bild: der Kopierprozeß startet, läuft aber bleibt nach einer Anzahl von Datenmengen dann hängen.

Das wäre ja eine Arbeitssituation, also "reproduzierbar". Dazu:
a) Die Unterbrechung würde sicher auch passieren, wenn rsync alle Daten initial syncen müßte. Was dir ja ganz am Anfang passiert ist.

b) Das Hängen vom rsync passiert dir aber in der jetzigen Testumgebung nicht nur wenn du eine Kopie des DCS-Verzeichnisses(DCS_kopie2) nutzt, sondern ebenfalls mit jeder anderen, vergleichbaren Menge an Nutzdaten (also ein anderes Verzeichnis)? Nur um auszuschließen das irgendwas mit/in dem DCS-Dir nicht ok wäre.

c) Auf dem Server (Ziel) ist noch genug freier Speicherplatz?

d) Wenn der rsync wieder hängt: Kannst du währenddessen noch (anderes Terminal) auf den CIFS-Mountpoint zugreifen und auch noch Daten schreiben/lesen? Oder ist die cifs-Verbindung ebenfalls "tot", stale ?

e) Baue und installiere dir mal cpdup
Ich habe mir das AUR-Paket mal angeschaut, es baut weiterhin (lediglich die manpage wird nicht richtig behandelt).
https://aur.archlinux.org/packages/cpdup/
manpage: Ändere im PKGBUILD die Zeile:
install -Dm 644 cpdup.1 "$pkgdir"/usr/share/man/man1
nach
install -Dm 644 cpdup.1 "$pkgdir"/usr/share/man/man1/cpdup.1
Das hätte den Vorteil, eben rsync als möglichen "Verursacher" (erneut, einmal hast du es ja schon durch smbclient/mput getan) auszumachen und eben nicht ursächlich das Netzwerk/Win-Server/Dateisysteme an sich .
Ich würde mit cpdup einfach dein (Quell)Doku-Dir in ein neues Ziel im cifs-Mount syncen lassen, also alles an Daten nochmal (initial) übertragen. Vor allem deswegen, da ich ad hoc nicht weiß ob cpdup ein Verhalten ermöglicht was du mit deinem rsync-Paramater --numeric-ids erreichen willst. Das also dann nach dem Syncen nochmal nachprüfen, aber AFAIK hat cpdup in seinen Default-Einstellungen schon "sinnvollere" Werte als rsync.
Ein möglicher Aufruf bei dir wäre also: 
cpdup -vvI /mnt/Doku/  /mnt/privat-fs/Doku-test/
(oder für weniger verbose-Output)
cpdup -dI /mnt/Doku/  /mnt/privat-fs/Doku-test/
Das Ziel-Verzeichnis mnt/privat-fs/Doku-test/ wird angelegt sofern nicht vorhanden. Ansonsten arbeitet cpdup defaultmäßig ähnlich wie rsync, anhand von Dateigröße/Zeitstempel wird geprüft ob Dateien übertragen/gesynct/gelöscht werden müssen.
Hallo GerBra,
ich danke dir nochmals für deine ausführlichen Infos!!

Zu a):
Ich kann ein Backup nochmal anstossen wo eigentlich nichts mehr übertragen werden muss. Dann läuft alles durch.
Es passiert nur beim Schreiben auf dem Server ab einer Datenmenge von ca. 35MB bestehend aus vielen einzelnen Dateien.
Wenn ich z.B. ein archlinux-2019.03.01-x86_64.iso ca 600MB dort hineinkopiere läuft auch alles durch.

Zu b):
Am Projektordner Projekt DCS_Kopie2 liegt es nicht. Ich kann auf dem selben Server ein anderes Verzeichnis mounten und dort ein beliebiges Projekt kopieren das genauso zum Hänger führt.
Es liegt also nicht an genau diesem Verzeichnis, an diesem Mountpunkt und auch am genauen Server Ziellaufwerk oder Verzeichnis.

Zu c):
Platz genug ist da. Es wird ca. 115GB freier Raum angezeigt.

Zu d):
Ist die Verbindung unterbrochen, so kann ich auch mit einem 2.Terminal nicht mehr auf den Mountpunkt reinsehen. 
$ cd /mnt/privat-fs
hier kein Prompt mehr.
Abbruch mit strg+c geht auch nicht.
Terminalfenster so geschlossen.

Übrigens auch Thunar macht dann nichts mehr. Man kann nichtmal mehr ein weiteres Thunarfenster benutzen.
Erst ein Reboot macht alles wieder in Ordnung. Dabei gibts dann failed unmount /mnt/privat-fs.
Nach 20Sekunden timeout bootet er dann.

Zu e):
Das Paket cpdup gebaut mit Änderung der PKGBUILD
Dann habe ich mal das Werkzeug benutzt. Was dabei rauskam: 
cpdup -dI /mnt/Doku/  /mnt/privat-fs/Doku/
Scanning /mnt/Doku/ ...
Scanning /mnt/Doku//kicadlibbak ...
Scanning /mnt/Doku//kicadlibbak/Seitenlayout ...
Scanning /mnt/Doku//kicadlibbak/components ...
Scanning /mnt/Doku//kicadlibbak/arduino.pretty ...
Scanning /mnt/Doku//kicadlibbak/footprint.pretty ...
Scanning /mnt/Doku//kicadlibbak/models3d ...
Nach ca. 10 Sekunden hing der Server schon wieder.
Übrigens auch bei cp -au .. das Gleiche wie bei cpdup.

Zu deinen anderen Punkten kann ich gerade mich nicht befassen. Das hole ich dann nach.
Nochmals vielen Dank für deine Mühen.

Gruß aus DN
Greg
Greg schrieb Zu d):
Ist die Verbindung unterbrochen, so kann ich auch mit einem 2.Terminal nicht mehr auf den Mountpunkt reinsehen.
Abbruch mit strg+c geht auch nicht.
...
Übrigens auch Thunar macht dann nichts mehr. Man kann nichtmal mehr ein weiteres Thunarfenster benutzen.
Erst ein Reboot macht alles wieder in Ordnung. Dabei gibts dann failed unmount /mnt/privat-fs.
Nach 20Sekunden timeout bootet er dann.
Also diesen Punkt d) halte ich für den entscheidenden (neben den anderen Infos aus deinem Post)...
Es sieht also nach einem reinen Lastproblem zwischen beiden Seiten aus (also CPU+IO+NETIO Last).
Da es immer passiert wenn eine größere Anzahl von kleinen Dateien im Spiel sind würde ich auf (Disk/Dateisystem)-IO-Probleme als Ursache tippen. Für diese Anzahl muß z.B. der empfangende Rechner (der "Server" in deinem Fall) einen immens hohen Aufwand an Rechenzeit und eben Disk-Zugriffe leisten (Daten empfangen,prüfen,Datei anlegen,Daten schreiben,Datei schließen,Dateisystem aktualisieren,...). Das kann sich dann hochschaukeln bis eben dahin daß die Netzverbindung nicht mehr bedient werden können, dein Mount wegbricht da das System nicht mal mehr sagen kann: Hoppla, ich lebe noch! == Timeout. Kann sogar sein, daß noch nicht mal mehr ein ping funktioniert.
Das es wohl eben nicht ursächlich ein Netzproblem ist, dafür spricht daß große Dateien ok übertragen werden, der Aufwand ist geringer. Ebenso zeigt daß IMHO das rsync nicht der Verursacher im Sinne von "Fehler" ist.

Verursacher: Können natürlich beide Seiten sein. Jetzt gehe ich mal davon aus, daß sowohl Du wie auch dein IT-Kollege an einigermaßen "vernünftigen" PCs sitzen, "vernünftige" Betriebssysteme verwendet ihr ja beide schon <g>
Der (Windows)Server: Das scheint ja kein dedizierter, "richtiger" Server zu sein (zumindest was ich an Infos aus dem Thread im Kopf habe). Eventuell eine virtualisierte Lösung mit ggf. virtualisierter Netzkarte und ebensolchem (HD)-Speicherplatz. Nur mal angenommen, der ganze Server wäre eine einzige "Datei", Image, auf einem Host/Wirt-System und würde aus diesem Image auch noch die Freigaben (die du mountest) bereitstellen: beim ständigen Aktualisieren dieses Images - durch massenhafte Kopieraktionen in hoher Anzahl - muß dieses Image in bestimmten Intervallen immens oft neu geschrieben/aktualisiert werden. Was die virtualisierte Lösung, aber auch das Wirt-System "an den Rande der Verzweiflung" bringen kann.
Insofern könnte die "Lösung" wirklich außerhalb deiner Möglichkeiten liegen, würde sich also ggf. erledigen durch eine neue Art/Konzept des "Servers".

Zur Verdeutlichung vielleicht nochmal ein Beispiel: Deine funktionierende Übertragung per smbclient/mput klappte deswegen, weil dieses Verfahren die "Dateien" ggf. auf "sequentielle Art" übertragen hat, also schön "eine nach der anderen", keep slow, "Schneckentempo", Alt-Herren-Art <g>.
Heutige Systeme können zu Recht erwarten, daß jegliche Datenpakete(IO, Input/Output) von jedem beteiligten Subsystem (Net, Disk, CPU) in einer vernünftigen Zeitspanne abgearbeitet werden - daß betrifft dann Timeout-Mechanismen bei Netzpaketen, bei verwendeten Caches und bei Rechenzeit und ebenso beim Lesen/Schreiben auf nicht volatile Speichermedien. Das eben nicht Daten in irgendwelchen Queues verhungern, erneut gesendet oder schlichtweg verworfen werden - bis hin das ein System sagt: Och, jetzt kann ich nicht mehr, ich mach mal Pause, egal was der Rest der Welt von mir will...

Deine Möglichkeiten:
a) nutze top/htop um die Last auf deinem Client zu beobachten. top ist dafür ggf. besser, da es bei den CPUs die Wait-Spalte mitanzeigt. Du kannst/wirst auch eine hohe Last/Load haben, aber ggf. nicht als Verursacher sondern als "Leidtragender".

b) Teste beim Netztransfer wirklich nochmal das Verhalten wenn du auf deinem Client per sysctl SACK und Timestamps für die IPv4-Pakete ausschaltest.

c) Mount-Parameter für cifs/SMB:
Cifs/SMB ist ja nun bekanntlich wirklich nicht das effizienteste Netzwerkprotokoll was jemals in die Welt "reingepresst" wurde. NFS und SMB z.B. sind IMHO so diametral unterschiedlich "bequem", wie durch eine Tür reinzukommen anstatt durch ein "Window"s <g>
man mount.cifs zeigt trotzdem einige Möglichkeiten ggf. daran zu drehen um die Problemursache durch eine Art "Verlangsamung" evtl. zu vermeiden.
Am vielversprechendsten erscheinen mir die Optionen (also bei mount bei -o):
a) cache=none
b) rsize und wsize, hier ggf. mal mit den alten Defaultwerten von 16k oder noch geringer arbeiten.
c) fsc (da bin ich mir am Unklarsten ob das Einschalten was bringt)
d) actimeo (ggf. mal raufsetzen auf 2 oder 3 s ?)
Das erscheinen mir die sinnvollsten Möglichkeiten direkt am Mount der entfernten Freigabe anzusetzen. Um ggf. den Timeout, Zusammenbruch eben auf protokoll-Ebene schon zu vermeiden. Ach so, a) bis d) immer schön eins nach dem anderen ausprobieren, einzel oder in jeweils nachfolgender Kombination, sonst merkt man nicht was eine evtl. Veränderung nun bewirkt hat.

Viel Spaß beim Ausprobieren, Testen. Kostet halt immer eine Menge an Zeit....
5 Tage später
Hallo GerBra,
du bist der Held des Tages, ach was des Jahres!!!
Es klappt.
vor Änderung: 
# sysctl -a |grep -e sack -e timestamp
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.netfilter.nf_conntrack_timestamp = 0
Hier deine Änderungsvorschläge: 
[root@zat264 gl]# sysctl net.ipv4.tcp_timestamps=0
net.ipv4.tcp_timestamps = 0
[root@zat264 gl]# sysctl net.ipv4.tcp_sack=0
net.ipv4.tcp_sack = 0
[root@zat264 gl]# sysctl net.ipv4.tcp_dsack=0
net.ipv4.tcp_dsack = 0
Backup gestartet: 
[root@zat264 gl]# sudo mount.cifs //servername/ZEA-1_Users/ichderuser/ /mnt/privat-fs/ -o noserverino,vers=1.0,uid=1000,gid=100,rw,user="ichderuser",password="geheim"
[gl@zat264 ~]$ rsync -rluvh --delete --numeric-ids --exclude=.Trash-1000 --exclude=lost+found /mnt/Doku/  /mnt/privat-fs/Doku/
sending incremental file list
DCS_kopie2/
DCS_kopie2/256-DOC-20190514-GLang-dcs_kopie_kabelplan.dxf
...
...
sent 187.91M bytes  received 31.89K bytes  631.72K bytes/sec
total size is 8.69G  speedup is 46.24
Trommelwirbel, -- Es läuft einwandfrei durch.
Damit ist erst mal alles gelöst.
In der Hoffnung, dass später mit dem neuen Server alles besser klappt.
Meinen herzlichsten Dank nochmal für deine ausführlichen Erklärungen und der vielen Arbeit die da hintersteckt.
Gruß aus DN
Greg