Hyper Backup Fehler: Sicherung startet nicht wegen zu wenig Speicher in root

[RalfPeter]

Übrigens, laut speicher.de ist "overraming" kein Problem.

Ja gut, kann schon sein, daß da am Ende Hyperbackup immer auf irgendeinem Weg zumindest wärend dem Backup Temporär in die Systempartition hinein bieselt

Dann wäre es eine Lösung eine 7.9GB root Partition zu haben.

 

[RalfPeter]

Hier die Ausgabe von df -hl:

 

[maxblank]

Hier mal als Vergleich eine DS923+ mit 64 GB Kingston ECC RAM



Bei mir läuft seit über 2 Jahren täglich zwei versionierte Hyper Backup Job zur Hetzner Storage Box und auf eine externe HDD, noch nie Probleme gehabt.

Infos zum RAM:

Mit df -hl sehe ich aber, dass /dev/md0 2.3GB groß ist und 1.6GB belegt. Also zu 74% belegt ist. Ich habe mir die log Dateiengröße angesehen. Einige habe ich geleert, da sie sehr alte Informationen enthielten.

Hast du das auch mal gemacht, kurz nachdem die Fehlermeldung kam oder mal generell während das Backup lief? Nicht, dass dort während dem Backup Daten reingeschrieben werden und danach autimatisch wieder gelöscht werden, wenn das Backup vorbei ist - egal ob das erfolgreich lief oder abgebrochen ist.

 

[RalfPeter]

Hi,
Wie hast du die Daten zum RAM bekommen? Welches Kommando. Danke

Das Problem tritt nicht während des Backup auf, sondern das geplante Backup startet erst gar nicht.

 

[maxblank]

Daten zum RAM bekommst du über "dmidecode command".

dmidecode --type 17
dmidecode --type memory
dmidecode -t 17

Ich glaube nicht, dass dein Problem mit dem erweiterten RAM alleine zusammenhängt, wenn der RAM-Test erfolgreich war. Das sind in meinen Augen irgendwelche Nebeneffekte. Als erstes mal eine manuelle Datenbereinigung auf allen Speicherpools bzw. Volumes manuell anstoßen und durchlaufen lassen.

Ich würde danach wie folgt vorgehen:

1. Hyper Backup Job löschen (nicht das Backup an sich, nur den Job) und vorher Screenshots von den Job-Einstellungen machen
2. Hyper Backup Job neu anlegen, mit den bestehenden Backup-Daten verknüpfen und testen
https://kb.synology.com/de-de/DSM/tutorial/How_to_relink_to_existing_backup_tasks_of_Hyper_Backup
3. Wenn das nicht hilft, nur ein einzelnes, der bereits vorhandenen, 32 GB Modul einbauen und Backup erneut testen
4. Schlägt auch das fehl, das andere 32 GB Modul im anderen RAM-Slot verbauen und erneut testen
5. Wenn auch das nicht läuft, RAM in den Slots nochmals quertauschen
6. RAM zurückgehen lassen und anderen testen

 

[RalfPeter]

Den Speicherpool habe ich natürlich vor dem RAM Tausch bereinigt. Was ich nicht gemacht habe (fällt mir eben so ein): den Schreib- / Lesecache (M.2 NVME Module) zu bereinigen.

Es ist kein spezifisches Backup, sondern immer das erste auf ein Gerät (also entferntes NAS, USB1, USB2). Alle darauffolgenden Backups (meist innerhalb von wenigen Minuten) starten und laufen alle ohne Fehler durch. Ich habe meine Backups kurz hintereinander getaktet, damit es keine Wartezeiten gibt (wenn ein Backup länger braucht wird ja das folgende automatisch verzögert). Die Backups starten meist ab 1:30 bis maximal 3:00 Uhr.

 

[maxblank]

Ist dann vielleicht das Ziel-NAS, welches das Backup empfangen soll, noch nicht bereit (Hochfahren über Zeitplan, Datenträger dort im Hibernation Modus, usw.).

Infos mit dem Read / Write-Cache taucht in diesem Thema auch das erste Mal auf, wenn ich es nicht überlesen habe und in der Signatur steht es auch nicht.

 

[RalfPeter]

Ist dann vielleicht das Ziel-NAS, welches das Backup empfangen soll, noch nicht bereit (Hochfahren über Zeitplan, Datenträger dort im Hibernation Modus, usw.).

Nein. Das war noch nie der Fall. Es tritt ja nicht nur beim entfernten NAS auf, sondern auch bei den lokalen USB Platten. Der Fehler ist dann auch ein anderer (nämlich genau, dass das Zielsystem nicht erreichbar ist). Hatte ich schon.

Infos mit dem Read / Write-Cache taucht in diesem Thema auch das erste Mal auf, wenn ich es nicht überlesen habe und in der Signatur steht es auch nicht.

Stimmt. Das ist nachlässig von mir und fiel mir eben erst auf. Das werde ich nachtragen.

 

[Benares]

Lies mal ab hier und hangle dich die fettesten Pfade herunter. Da wird sich was zum löschen finden lassen. Normal sind etwa 65-67%

 

[RalfPeter]

Danke für den Tipp. Ich habe mal Screenshots gemacht. Ich konnte jetzt nichts besonderes entdecken. Am größten ist die GeoID DB mit 70M und python 3.8 mit 70M.

 

[Ronny1978]

Hast du denn mal den Cache deaktiviert? Nicht, dass hier schon ein Fehler auftaucht, was gar nichts mit dem RAM zu tun hat. Oder wie sehen das die Anderen?

 

[maxblank]

Ich habe meins dazu oben geschrieben. Ob es durch @RalfPeter umgesetzt wird, ist seine alleinige Entscheidung.

 

[RalfPeter]

Hallo zusammen
Danke für eure Hilfe und die vielen Tipps.
Ich bin die Ordner durchgegangen und habe ein paar größere und ältere logs gelöscht.
Den Cache habe ich zur Sicherheit gelöscht und neu angelegt.
Heute Nacht laufen wieder Backups. Ich bin gespannt.

 

[Benares]

Bei welchem %-Stand bist du jetzt?
Ich denke, bei dir ist es Kleinkram, der sich läppert.
Du weißt, bei Neuaufsetzen werden die Systempartitionen inzwischen 7,9 statt 2,3 GB groß. Synology hat wohl selbst gemerkt, dass das etwas knap bemessen war.

 

[RalfPeter]

Die root Partition hat jetzt 73%. Es ist ausser der Geo Datenbank nichts größeres mehr vorhanden.

 

[Benares]

Na ja, m.E. noch viel zu viel, 65-68% wären normal.
Was ist mit /usr/syno/synoinstall/space-preserve, gibt's die Datei bei dir noch? Wenn ja, weg damit.

 

[RalfPeter]

Guten Morgen,

@Benares : es gibt einen Ordner space-preserve-for-configs:

 

[RalfPeter]

Das habe ich gefunden:



Was macht diese spk Datei im root?

 

[Benares]

Beides normal und bei mir auch so.

 

[RalfPeter]

Hier ist noch ein möglicher Kandidat:

Ist das nur das Handbuch? Kann das weg?