Hyperbackup Sicherung verursacht schreiblast auf anderem Laufwerk

[geheim5000]

Hallo

Habe eine DS918+ bestückt mit 2 mal 10TB und 2 mal 16TB im SHR und 2 NVME 1TB im Raid 1. Ram sind 16GB verbaut

jetzt fahre ich mit Hyperbackup (rsync) grad ein Backup von Dateien die auf dem großen Pool liegen. Das ganze stockt aber immer wieder (Übertragung wartet auf Daten)

Jetzt Ist die Auslastung der NVMEs um 100% und es wird permanent dadrauf geschrieben.

Versteh nicht ganz warum.

Software alles aktuell usw.

Hyperbackup ist auf der NVME installiert

Jemand eine Idee was da los ist?

 

[dil88]

Läßt Du Hyperbackup ein Logfile schreiben? Wenn ja und wenn Du viele kleine Dateien sicherst, dann schreibt der permanent in sein Systemverzeichnis - also auf die NVME.

 

[Elrob]

Hallo
Denke dies scheinen die gleichen Probleme zu sein die ich mit Hyperbackup und der Maria10Db habe (siehe Maria10Db Probleme)
Die Maria10Db hat nur 4GB....
Backup der Datenbank ist in 2 Minuten erledigt.
Restore der Datenbank dauert 11 Stunden.

 

[geheim5000]

Läßt Du Hyperbackup ein Logfile schreiben? Wenn ja und wenn Du viele kleine Dateien sicherst, dann schreibt der permanent in sein Systemverzeichnis - also auf die NVME.

Detailiertes Logfile Nein. Ansonsten kann man da nichts einstellen oder?

@Elrob ich hab das Problem beim Backup erstellen.

 

[Elrob]

Hallo
Viel helfen kann ich da leider nicht... aber wenn ich mir die Daten da anschaue dann ist das System dicht...
99% und 98% Auslastung sieht nicht gut aus...
Selbst bei der USB Disk mit 67% gefällt mir nicht...
Ich weiss nicht was Synology macht... aber eines weiss ich aus Erfahrung... Permanente Auslastung von über 75 %, da ist was faul...

So wie es aussieht wird versucht von Drive 1 bis 4 zu lesen ... dann geht es via den beiden Cache zur USB-Disk...
Ungewöhnlich ist meiner Meinung nach, warum von 4 Drives gelesen wird? Sind die vier Drives nicht ein einzelnes Volume!

 

[Elrob]

Sorry, habe nachgeschaut... es sind ja zwei Volumes!

 

[geheim5000]

Also das USB Drive ist normal, da wird grad drauf kopiert. Was auch noch 4 Tage dauert.

Drive 1 bis 4 ist ein Volume. Also auch da normal das gelesen wird weil grad ein Hyperbackup gefahren wird.

Nur haben die NVMEs normalerweise damit nix zu tun. (Sind als Laufwerk eingerichtet, nicht als Cache)

Sobald ich das Backup pausiere oder abbreche ist bei den NVMEs auch alles wieder TOP

 

[Elrob]

Wenn du die einzelnen Posten so durchrechnest... Summe von Drive 1 bis 4 lesen, entspricht in etwa Der Jeweiligen Summe der Caches beim Schreiben und entspricht wiederum in etwa dem Schreiben auf die USB-Disk...
Die werte werden nie genau exact sein, das liegt in der Natur der Sache...

Zum weiteren Verständnis. Was versucht du zu Backupen? Von allen Laufwerken gleichzeitig...

Zur Erklärung: Bei mir ist es die Maria10Db die Ressourcen frisst... Das Backup dieser Datenbank haben nun als alleiniges Backup in der HyperBackup Task separiert (war ein Tip von Synology Support)....
Habe nun folgende Einstellung....
System und alles andere (ohne Maria10Db) findet alle 2 Tage um Mitternacht statt... (Zeit 10Minuten)
Die Maria10 DB sichere ich täglich um 3 Uhr morgens... (Zeit 2 Minuten)

 

[geheim5000]

Die USB Disk hat mit dem Backup nichts zu tun.

Das Backup läuft auf eine andere Maschine (OMV läuft dadrauf)

Hatte auch erst den verdacht das auf den NVMEs irgendwas gecached wird. Hab das aber beobachtet, von denen wird nicht in dem Umfang gelesen

Das die Werte jetzt zufällig zur Schreiblast auf der USB Disk passen ist wie gesagt zufall

Bei mir ist auch viel separiert. in dem Fall handelt es sich um einen Ordner wo die Dateien ca 600MB bis 1GB haben insg. ca 3TB

Und klar von Disk 1 bis 4 gleichzeitig, ist ja ein SHR. Hab ich ja keinen Einfluss drauf.

 

[Elrob]

Also ich weiss nicht...
Wenn dies alles über einen IO-Chip läuft, dann hat dies Auswirkungen auf das ganze System...
Beispiel: Der SATA-Bus... auf meinem PC gibt es 6Interfaces dazu und kann 5 Platten anschliessen... Habe es schon erlebt dass eine Platte die eigentlich nichts mit dem Betriebsystem zu tun hat, plötzlich seinen ganzen IO ausnutzt und die anderen Platten kommen zu kurz...

Da Synology zum Glück auch nur mit Wasser kocht, vermute ich dass da bei denen gleiches passiert

 

[metalworker]

moment mal .

du nutzt die NVME als Cache ?
Aber wie kannst du dann drauf das HB Packet installiert haben?

 

[geheim5000]

@metalworker

Nur haben die NVMEs normalerweise damit nix zu tun. (Sind als Laufwerk eingerichtet, nicht als Cache)

zitiere mich mal selbst. Sie sind als Laufwerke eingerichtet.

@Elrob

Die NVMEs haben mit dem Backup und dem kopiervorgang nichts zu tun. Warum sollte da dann Schreiblast drauf sein?

ich nutze die NVMEs jetzt ca. 2 jahre. und hab nen verschleißgrad von 30% gehabt.

Durch diese mMn sinnlose schreiberei hab ich in unter einer woche jetzt einen Anstieg auf 33%

 

[ctrlaltdelete]

Weil du dort Hyper Backup installiert hast und dort wohl während des Backups Daten zwischengespeichert werden. Ich habe das auch gerade mal getestet, allerdings geht meine Auslastung bei weitem nicht so hoch auf den NVMEs. Waren allerdings auch nicht so viele neue Daten, bzw. veränderte Daten im Backup.

 

[metalworker]

Ah das mit dem nicht als Cache hab ich überlesen.

Also hab bei mir Daheim das HB Packet auf ner SSD ( kein NVME) , da macht er das auch .
Aber komme bei der auslastung auf vieleicht 10 Prozent

 

[Elrob]

Also echt da habe ich auch keine Idee ...
Wobei ich feststellen muss , dass vor einer Stunde ein DSM update für die DS224+ eintrudelte nun DSM 7.2.1-69057 drauf....
Obwohl bei den Updates HB nicht upgedatet wurde, haben die was beim Speicherzugriff geändert.... Meine Platten brummen nicht mehr...

Oder meinte ich kreischen?

 

[Elrob]

Aha :

Version: 7.2.1-69057 Update 2​

Fixed Issues​

1. Fixed an issue where certain models might experience abnormal shutdown after updating to DSM 7.2.1.
2. Fixed an issue where files deleted locally might still exist on the Hyper Backup destination server.
3. Fixed an issue where file access failed due to errors during soft link creation in Btrfs file systems.
4. Fixed an issue where backing up WriteOnce shared folders in Hyper Backup might cause space consumption.
5. Fixed an issue where SSD read-write cache might cause unexpected restarts of DSM on SA3200D and SA3400D.

Da scheint sich was zu tun ... HB und SSD

 

[Benares]

Wo liegt Drive und seine Datenbank? Auf dem NVME-Volume? Das könnte die Schreibzugriffe erklären, auch wenn du selbst dorthin nicht schreibst.

Edit: Klick einfach im Speicher-Manager auf die 3 Punkte hinter Volume 1/2, Nutzungsdetails.

 

[geheim5000]

@ctrlaltdelete
Ist ein initial Backup, könnte also durchaus dadran liegen. Frag mich zwar wieso dadrauf gecached werden muss aber gut.

Bei 10% währe es mir nichtmal aufgefallen. Die 100% sind halt nur ungewöhnlich

@Benares
Drive liegt auf den NVMEs. synct einen Ordner mit einem entfernten Nas, mehr nicht.

Aber was hat das mit Hyper Backup zu tun?

 

[Benares]

Gestern gab es hier einen Fall, wo jemand sein NAS ganz normal (nicht über Drive) betrankt hat. Am Ende war das Volume voll, verursacht durch eine aufgeblasene Drive-Datenbank. Die wuchs schneller an als die Nutzdaten reinkamen. Wie groß ist die jetzt bei dir?
Ist dein Sicherungsziel evtl. ein Drive-Teamordner?

 

[geheim5000]

Mein Datenbestand hat sich in den letzten 4 Wochen nicht verändert. Das mit der aufgeblasenen Datenbank hatte ich aber auch schonmal.

ich schaue das nachher nochmal nach