Verhalten von Borgbackup mit Netcup Storagespace

Moin Gemeinde,

ich habe vor einigen Tagen einige Server in mein Monitoring aufgenommen und habe eine Interessante Feststellung gemacht.

Gegeben sind mehrere homogen aufgebaute Rootserver unterschiedlicher Größe mit Debian 11 und mit einem LAMP Stack. Einer dieser Server wurde, aufgrund von Storagemangel, mit einem Netcup Storagespace erweitert. Dieser ist per NFS eingehangen - alles soweit unspektakulär.

Gesichert werden alle diese Server per Borgbackup auf ein Offsite Ziel (per SSH). Im Normalfall geht das alles recht zügig, da die Backups inkrementell sind und es nur wenige Veränderungen auf den Systemen gibt. Trotzdem dauert das Backup auf diesem einen Server mit dem Storagespace sehr lang, was sich in einem mehrere Stunden langen Zeitfenster mit sehr viel iowait äußert.

pasted-from-clipboard.png

pasted-from-clipboard.png

Zum Vergleich hier nochmal zwei Screenshots von einem bedeutend größeren System:

pasted-from-clipboard.png

pasted-from-clipboard.png

Ich bin mir sehr sicher, dass der Storagespace als NFS Mount ein Problem darstellt. Allerdings habe ich keine Idee, warum das Ganze auf einer normalen lokalen Platte so "flawless" durchläuft und beim NFS so massiven I/O erzeugt. Der Borg Cache sollte ja eigentlich auch für den NFS Mount greifen. Hat jemand von euch eine Idee, woran das liegen könnte?

Das Ganze ist für die Nutzer der Applikation recht unschön, weil ich die Applikation für ein konsistentes Backup natürlich für den Zeitraum des Backups sperren muss. Gerade die Frühaufsteher freuen sich da mächtig drüber.

Zitat von lindesbs

Schonmal mit iostat oder nfsiostat geschaut?

Was sagen die CPUs. Ist das Netz da?

Ich habe auch einen 10TB storage ueber vlan angebunden. 3 von 14 Servern haben Probleme, weil das vlan intern mit vxlan emuliert wird. Paketverluste von 80%. Unvorhersagbar. Ich weiss nicht, wie borgbackup damit klarkommt.

Noch nicht, nein. Was ich sagen kann: Das Netz ist definitiv durchgehend da und der NFS Storagespace durchgehend erreichbar. Die CPU Last ist, abgesehen vom iowait, fast durchgehend Null.

Der Storagespace ist über das normale WAN Interface angebunden - das ist ja eine NetApp von Netcup, die eine öffentliche IPv4-Adresse hat.

Zitat von H6G

Borg Cache?

Es wird doch dennoch für jede Datei eine Prüfsumme berechnet - somit der gesamte Storagespace eingelesen.

Ja aber nein. Dann müsste ja auf dem großen Server jedes mal so 1,5TB+ vom SAS Storage gelesen werden, was recht offensichtlich nicht der Fall ist. Die Doku sagt dazu:

Zitat

Backup speed is increased by not reprocessing files that are already part of existing archives and weren’t modified. The detection of unmodified files is done by comparing multiple file metadata values with previous values kept in the files cache.

This comparison can operate in different modes as given by --files-cache:

• ctime,size,inode (default)

Interessanterweise ist das ganze letzte Nacht nicht aufgetreten, die Nächte zuvor allerdings immer. Und ja, das Backup ist gelaufen lol.

Ich werde weiter beobachten.

Ich habe jetzt mal etwas getestet und seit zwei Tagen ist Ruhe.

Ursprünglich hatte ich den NFS Share einfach mit dem Parameter "defaults" in der /etc/fstab eingehangen.

So ganz sinnvoll ist das nicht, musste ich feststellen.

Aus verschiedensten Quellen habe ich mir jetzt die Parameter "auto,noatime,nolock,intr,tcp,actimeo=5184000,fsc" zusammengestoppelt.

Das funktioniert allerdings nur, weil ich den Storagespace ausschließlich für einen Server nutze. Denn actimeo sagt, dass ich am Host z.B. die Attribute von Dateien im NFS für bis zu 60 Tage cache. Und auch der Parameter "fsc" aktiviert den Cache für Dateien im NFS. Das ist natürlich alles problematisch, wenn man mit mehreren Hosts arbeitet, denn ein anderer Host könnte ja derweil eine Datei im NFS modfizieren.

Ich beobachte das ganze mal noch einige Tage und hoffe, dass nun Ruhe ist.

Zu früh gefreut...

pasted-from-clipboard.png

Ich verstehe das nicht... das ergibt überhaupt keinen Sinn. Mal passiert es, mal nicht.

Kann sich das hier jemand erklären?

pasted-from-clipboard.png

Offensichtlich scheint es so zu sein, dass Borgbackup immer das komplette NFS ausliest, wenn es Änderungen auf diesem gab. Wie im Graph zu sehen, ist das zwar nicht viel, was sich da ändert, aber es reicht offensichtlich als Anlass, um alles auszulesen. Auf normalen, lokalen ext4 Dateisystemen passiert das nicht.