rootfs läuft bei rsync übertragungen voll

[Easy Tec]

Hallo liebes Unraid Forum.

 

Mein Unraidserver hatte sich vor ein paar Tagen aufgehängt.
Nachdem ich diesen Force-restarten musste, -weil er nicht auf die befehle der GUI gehört hat-
wurden nahezu alle Docker auf Werkseinstellungen zurückgesetzt.
Da ich ein Backup jedes einzelnen Dockers habe, konnte ich diese Daten relativ einfach per rsync
zurück auf meinen Server holen.

 

Doch genau hier liegt das Problem:
Wenn die Rsync übertragung läuft bricht sie manchmal ab und gibt mir den Fehler "(28) No space left on device" aus.
Nach kurzer Fehlersuche fiel mir auf, dass das Verzeichnis "rootfs" dann immer voll läuft. (siehe Anhang)
Meine Ramauslastung steigt hierbei von 10-20% auf 50-60%.

Ich habe Momentan 16GB Arbeitsspeicher verbaut, das Verzeichnis "rootfs" hat 8GB zur Vefügung.
Neuer RAM ist schon bestellt.

 

Jetzt meine Frage:
Wie kann man das Problem lösen, dass bei einem RSYNC das Verzeichnis "rootfs" vollmüllt lösen?

 

Vielen Dank im Vorraus.

[ChatNoir]

I move this to the German subforum, if you really want to post in General, please use English.

[mgutt]

Wenn nach einem erzwungenen Neustart deine Docker weg sind, dann a) weil dein Datenträger defekt ist oder b) du die Dockerdaten irgendwo hinschreiben lassen hast, wo sie nach einem Neustart verloren gehen und das wären ALLE Unterverzeichnisse außer das was in /mnt/(user|diskX|cache|poolname)/ liegt, da unRAID im RAM läuft. Wenn du also etwas nach / schreibst, landet das in deinem RAM. Schreibst du was nach /docker, landet es im RAM.

 

Auch dein rsync Befehl scheint genau das zu versuchen. Da wäre es natürlich hilfreich gewesen, wenn du uns den mal gezeigt hättest bzw auch deine Pfade der Container und den Docker Einstellungen zeigst.

 

Nur wenn du zb nach /mnt/user/appdata/containername schreibst, landet es auf deinem Datenträger.

[Easy Tec]

32 minutes ago, mgutt said:

rsync Befehl

(Dieser rsync befehl würde jetzt z. B. den ganzen WordPress Container vom backupserver zum Unraid server schreiben:)

sudo rsync -az --progress USER@IP:/BACKUPDISK/Unraid-Backups/AppData/wordpress /mnt/user/appdata/

 

Alle meine Docker befinden sich in /mnt/user/appdata/.

 

Ich schicke auch mal die konfiguration des Dockers wordpress (als beispiel) mal als anhang:

[mgutt]

Die Konfiguration deines Containers ist korrekt.

 

Kann es sein, dass dein Array nicht gestartet ist und du dann von Hand /mnt/user/appdata erstellt hast oder rsync lief als du das Array gestoppt hast?

 

Dieser Mount auf deine Disks existiert nämlich erst, wenn das Array gestartet wird und bei dir scheint es ein normaler Ordner zu sein = RAM.

 

Versuch jetzt bitte nicht dein Array zu starten, falls das der Fall ist. In /mnt darf nur der Ordner disks und remotes liegen, wenn das Array gestoppt wurde. Kannst du mit "ls /mnt" prüfen.

 

[Easy Tec]

 

17 minutes ago, mgutt said:

Kann es sein, dass dein Array nicht gestartet ist und du dann von Hand /mnt/user/appdata erstellt hast oder rsync lief als du das Array gestoppt hast?

Nein, mein Array war online, nur der Docker war bei manchen übertragungen gestoppt. Dannach wurde er (also der Docker) wieder hochgefahren, bzw. neu gestartet.

 

(Im Anhang sieht man den status, den das Array immer hat.)

Edited December 18, 2021 by Easy Tec

[Easy Tec]

Just now, hawihoney said:

Quelle und Ziel vertauscht?

Mit diesem Befehl ziehe ich ja mein Backup-file vom Backupserver auf meinen Unraidserver.

Hierbei habe ich folgenden Befehl auf meine gegebenheiten angepasst:

 

rsync --delete -avzb [email protected]:/var/www /home/benutzer/webserver --backup-dir=~/old

(Quelle: https://wiki.ubuntuusers.de/rsync/ )

[hawihoney]

8 minutes ago, Easy Tec said:

Mit diesem Befehl ziehe ich ja mein Backup-file vom Backupserver auf meinen Unraidserver.

 

Ich hatte meinen Post gelöscht, da ich erst beim zweiten Blick gesehen hatte, dass Du damit einen Backup zurückspielst.

 

Wie auch immer: Irgendetwas schreibt ins RAM. In nahezu 100% der Fälle ist das /mnt oder /tmp. Das können fehlkonfigurierte Container oder eben rsync sein. Da musst Du ansetzen. Schau genau in /mnt bzw. /tmp rein. Alles was z.B. unter /mnt nicht wie ein Disk/User/Pool/Share unter user oder disks oder remotes lautet ist falsch. 

 

Da es meist bei rsync passiert ist das wohl der Auslöser.

 

Edited December 18, 2021 by hawihoney

[Easy Tec]

3 minutes ago, hawihoney said:

Schau genau in /mnt bzw. /tmp rein. Alles was z.B. unter /mnt nicht wie ein Disk/User/Pool/Share unter user oder disks oder remotes lautet ist falsch. 

In meinem /mnt ist folgendes drinnen:
- /cache

- /disk1

- /disk2

- /disks

- /remotes

- /user

- /user0

 

In meinem /tmp ist folgendes drinnen:

- /community.applications

- /emhttp

- /notifications

- /plugins

- /unassigned.devices

- /user.scripts

[hawihoney]

21 minutes ago, Easy Tec said:

In meinem /mnt ist folgendes drinnen

 

In Deinem / sind 7,6 GB. In meinem 2 GB und mein Server wird wahrscheinlich ungleich fetter sein. Da musst Du suchen.

 

Fang mit Deinen rsync Skripten an.

 

[mgutt]

Stopp bitte das Array und prüfe erneut welche Ordner noch da sind.

[Easy Tec]

6 minutes ago, hawihoney said:

Da musst Du suchen.

Okay. Ich habe als erstes mal den /cache im /mnt geprüft, da ich diesen schon in verdacht habe.

Ist es hierbei normal, dass in dem Ordner /mnt/cache sich (fast) jeder Docker der gerade aktiv ist, befindet?

 

9 minutes ago, hawihoney said:

Fang mit Deinen rsync Skripten an.

Und was genau ist damit gemeint, "Mit meinen rsync Skripten anzufangen"? Soll ich meine pfade kontrollieren?

 

[Easy Tec]

26 minutes ago, mgutt said:

Stopp bitte das Array und prüfe erneut welche Ordner noch da sind.

Nach einem Array-stopp ist in /mnt nur noch folgendes drinnen:

- /cache

- /disks

- /remotes

 

Kann ich das Array wieder starten?

[mgutt]

Führe mal das aus:

du -shx /*

 

/mnt muss 0 zurückgeben bzw es darf grundsätzlich kein Ordner über 1GB zurückgeben.

[mgutt]

6 minutes ago, Easy Tec said:

Kann ich das Array wieder starten?

Ja

[Easy Tec]

1 minute ago, mgutt said:

Führe mal das aus:

du -shx /*

Ergebnis siehe Anhang

[mgutt]

Du hast 6.8G in /mnt also im RAM. Führe das aus:

du -shx /mnt/*

 

[Easy Tec]

2 minutes ago, mgutt said:

du -shx /mnt/*

Was genau tut dieser Befehl?

 

[Easy Tec]

Löscht der diesen Speicher oder sortiert dieser z. B. unnötige Dateien aus?

 

 

[mgutt]

Ermittelt nur die Größe. du = disk usage.

[Easy Tec]

1 minute ago, mgutt said:

Ermittelt nur die Größe. du = disk usage.

 

12 minutes ago, mgutt said:

du -shx /mnt/*

Okay. Dauert noch etwas, bis es durchgelaufen ist, ich kann aber schon einmal dies hier sagen:

 

6.8G    /mnt/cache
0       /mnt/disk1

 

[Easy Tec]

1 minute ago, Easy Tec said:

Okay. Dauert noch etwas, bis es durchgelaufen ist, ich kann aber schon einmal dies hier sagen:

 

15 minutes ago, mgutt said:

du -shx /mnt/*

Hier das ganze:

 

6.8G    /mnt/cache
0       /mnt/disk1
700G    /mnt/disk2
0       /mnt/disks
0       /mnt/remotes
707G    /mnt/user
700G    /mnt/user0

 

[ich777]

27 minutes ago, Easy Tec said:

Hier das ganze

Hast du deine Diagnostics schon mal gepostet?

[mgutt]

Du hast keine Cache SSD, korrekt? Dann hast du mal einen Docker gehabt, der den /mnt/cache erstellt hat. Vermute ich.

 

Wenn du keinen Cache hast, dann kannst du den Ordner wie folgt löschen:

rm -r /mnt/cache

 

Oder sind da wichtige Daten von Docker drin? Dann auf deine Disk verschieben:

mv -v /mnt/cache/* /mnt/disk1/

rmdir /mnt/cache

[mgutt]

Nur als Info. Sobald der Ordner /mnt/cache existiert und die Shares beim Cache auf Yes oder Prefer stehen, schreiben diese automatisch in den Ordner.

 

Komisch ist allerdings, dass der Ordner erstellt wurde. @ich777 meinte mal, dass wenn ein Container auf /mnt/cache eingestellt ist, dass der Pfad dann automatisch in /mnt/user geändert wird, wenn man keinen Cache hat.

 

Prüf mal bitte alle Container. Auch die versteckten Optionen. Irgendeiner hat als Pfad /mnt/cache eingestellt.