Hyper Backup Failed to start backup task. (Insufficient space on Synology NAS system root partition)

[Happyboy]

Guten Morgen,

seit dem 22.09. bekomme ich auf meiner RS819 mit DSM7 im Hyperbackup Log folgende Fehlermeldung angezeigt:

Failed to start backup task. (Insufficient space on Synology NAS system root partition. Please contact Synology Technical Support.)

=> Kann ich der Root Partition mehr Speicherplatz zuweisen? Die Platten sind groß genug und nur zu 50% belegt.

Dank & Gruß
Happy

 

[Fusion]

Root Partition bezieht sich eher auf die DSM Systempartition.
Die ist nur 2.3GB groß und nicht sichtbar im DSM Desktop.

Da kommst nur via Support und Ticket ran, oder du wirfst selbst die SSH Konsole an via putty oder eingebauten ssh clients unter linux/win/Mac.

Im Forum gibt es reichlich Threads dazu, meist im Zusammenspiel mit DSM Updates.

Kannst auch gleichzeitig mal im Speichermanager schauen wie die Volume Belegung aussieht.
Wenn sich das eventuell doch auf das normale Volumen bezieht ist vielleicht einfach der Platz über Versionierung / Snapshots zugeballert die nicht unbedingt in der Belegung angezeigt werden.

 

[Happyboy]

Da kommst nur via Support und Ticket ran, oder du wirfst selbst die SSH Konsole an via putty oder eingebauten ssh clients unter linux/win/Mac.

Ich komme schon via WinSCP per SSH auf die Systemebene, aber mit Linux kenne ich mich nicht aus und weiß somit nicht, was ich da tun muss, um Platz freizumachen. Obwohl ich als Admin angemeldet bin kann ich nicht mal nach /tmp wechseln - access denied.

Kannst auch gleichzeitig mal im Speichermanager schauen wie die Volume Belegung aussieht.

Das Volume selbst sieht gut aus, ist nur zu 50% belegt und mehr als 1 TB Platz

 

[Happyboy]

so sieht das Verzeichnis aus:


/$ ls -al
total 68
drwxr-xr-x 22 root root 4096 Jul 5 09:06 .
drwxr-xr-x 22 root root 4096 Jul 5 09:06 ..
lrwxrwxrwx 1 root root 7 Jul 5 09:03 bin -> usr/bin
drwxr-xr-x 7 root root 0 Aug 3 18:29 config
drwxr-xr-x 11 root root 2360 Aug 3 18:29 dev
drwxr-xr-x 53 root root 4096 Sep 23 09:29 etc
drwxr-xr-x 41 root root 4096 Jul 5 09:05 etc.defaults
drwxr-xr-x 2 root root 4096 Jun 24 22:41 initrd
lrwxrwxrwx 1 root root 7 Jul 5 09:03 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Jul 5 09:03 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 7 Jul 5 09:03 lib64 -> usr/lib
drwxr-xr-x 3 root root 4096 Jul 5 09:04 .log.junior
drwx------ 2 root root 4096 Jun 24 22:41 lost+found
drwxr-xr-x 2 root root 4096 Jun 24 22:41 mnt
drwxr-xr-x 3 root root 4096 Jul 5 09:05 .old_patch_info
dr-xr-xr-x 349 root root 0 Jan 1 1970 proc
-rw------- 1 root root 1024 May 31 2012 .rnd
drwx------ 3 root root 4096 Jul 5 09:05 root
drwxr-xr-x 51 root root 3100 Sep 23 09:56 run
lrwxrwxrwx 1 root root 8 Jul 5 09:03 sbin -> usr/sbin
drwxr-xr-x 4 root root 4096 Jul 5 09:05 .syno
dr-xr-xr-x 12 root root 0 Jul 5 09:04 sys
drwxr-xr-x 2 root root 4096 Apr 9 20:00 .system_info
drwxrwxrwt 21 root root 5480 Sep 23 09:57 tmp
drwxr-xr-x 12 root root 4096 Jul 5 09:03 usr
drwxr-xr-x 18 root root 4096 Jul 5 09:05 var
drwxr-xr-x 12 root root 4096 Jul 5 09:04 var.defaults
drwxr-xr-x 41 root root 4096 Jul 5 09:28 volume1

 

[Fusion]

Mach mal "df -lh" und "du -xhd 1 /"

 

[Happyboy]

Mach mal "df -lh" und "du -xhd 1 /"

mit PuTTY hab ich nun auch den root Zugriff:

 

[Fusion]

Noch ein "ls -lah"

Scheint jedenfalls wirklich die root Partition / zusein (dev/md0) die als Raid 1 über alle internen Platten liegt und das DSM Linux System beherbergt.

Komisch ist, dass 'du' eine Belegung im normalen Rahmen (1.4GB) bringt.
Trotzdem das Verzeichnis mit 2.3GB voll belegt ist.

 

[Happyboy]

Noch ein "ls -lah"

Scheint jedenfalls wirklich die root Partition / zusein (dev/md0) die als Raid 1 über alle internen Platten liegt und das DSM Linux System beherbergt.

Komisch ist, dass 'du' eine Belegung im normalen Rahmen (1.4GB) bringt.
Trotzdem das Verzeichnis mit 2.3GB voll belegt ist.

Mit dem /md0 scheinen ja so einige Probleme zu haben. Bleibt die Frage, was es so aufbäst .....

 

[Fusion]

Ja, meist sind es allerdings benutzerfehler, dass über Fehlkonfiguration von Drittpaketen (Bsp JDownloader) oder Scripten in die falschen Pfade geschrieben wird.

Bei dir liegt allerdings keine Datei direkt in root /
Und die Belegung bis in die erste Ebene zeigt mit 1.4Gb auch keine Auffälligkeit.

Vielleicht mal noch ein "du -hd 1" (ohne Grenze auf das Wurzeldateisystem).
Sehe grad nicht wo die restlichen 700MB herkommen zu den 100%

Edit: vielleicht noch ein "mount" ob da was komisch ist.

 

[Happyboy]

Ja, meist sind es allerdings benutzerfehler, dass über Fehlkonfiguration von Drittpaketen (Bsp JDownloader) oder Scripten in die falschen Pfade geschrieben wird.

ich habe keine Drittpakete installiert

Vielleicht mal noch ein "du -hd 1" (ohne Grenze auf das Wurzeldateisystem).
Sehe grad nicht wo die restlichen 700MB herkommen zu den 100%

Edit: vielleicht noch ein "mount" ob da was komisch ist.

Bitte sehr Ich freue mich sehr über deine Unterstützung.

Auffällig sind die markierten 1,4 GB, oder nicht?

 

[Fusion]

Die 1.4Gb sind die Summe aus den Dateien und Verzeichnissen. Das passt ja eigentlich.

/usr und /var sind auch in üblichen Größen, nix ausgeartet.

Auch bei den Mounts sehe ich nix ungewöhnliches.

Nur die Differenz zu 2.2Gb sehe ich immer noch nicht.

Hast die DS mal neu gestartet?

 

[Happyboy]

Hast die DS mal neu gestartet?

Nein. Sie hängt an einer USV uns starte Sie eigentlich nie. Das ist aber eine gute Idee, ich werde mal einen Neustart machen. Vielleicht leert das den ein oder anderen Cache ......

 

[Happyboy]

Hast die DS mal neu gestartet?

Der Neustart hat es gebracht, die Backups sind anschließend ohne Fehlermeldung durchgelaufen.



Beruhigt bin ich allerdings nicht. Ich würde gerne verstehen, weshalb das passiert ist und die Ursache abstellen, statt mich mit den Folgen herumzuschlagen.

@Fusion - vielen Dank für Deinen Support, der mich auf den richtigen Pfad gebraucht hat

 

[Fusion]

Eigentlich sollte Hyper Backup ja gar nichts auf der root Partition machen (außer /var/log). Schon gar nicht, wenn man die Belegung mit üblichen Mitteln nicht erkennen kann.
Aber ich erinnere mich, dass schon mal jemand das identische Problem hier im Forum hatte. Ob der Kollege allerdings ein externes Cloud Backup hatte weiß ich jetzt nicht mehr.

Scheint, dass die Garbage Collection nicht Auf den Fall ausgelegt wurde, dass nie ein Neustart erfolgt.

Müsste man sich vielleicht die Dateiliste aktuell abspeichern und wenn das Problem wieder auftritt ebenfalls und vergleichen.

Oder halt mal ein Ticket mit den Symptomen bei Syno aufmachen. Vielleicht wissen die schon woran es liegt und ob es vielleicht schon für ein Fix vermerkt wurde.

 

[Happyboy]

Hallo Ihr Lieben,

das Problem besteht weiterhin und tritt leider immer wieder auf, etwa alle 2 Monate. Ein Neustart schafft dann jedes Mal Abhilfe.

Failed to start backup task. (Insufficient space on Synology NAS system root partition. Please contact Synology Technical Support.)

Das ist extrem nervig. Ich habe eine Rack Version, die an einer USV hängt. Ich gehe davon aus, dass ein NAS ohne Neustarts auskommen sollte. Genau dafür ist es doch da. Meine vorherige RS212 lief mehrere Jahre ohne Neustart, die RS819 zickt. Allerdings erst seit dem Update auf DSM7.

Was kann ich noch tun? Ideen? @Fusion ?

Vielen Dank für Eure Hilfe
Happy

 

[Fusion]

Hast du denn mal nach 4 oder 6 Wochen die Belegung geprüft?

Und jedes Mal nur ein Neustart, keinerlei andere Maßnahmen?

Bzw. mal ein Ticket aufgemacht?
Eventuell gibt es ja mit Cloud Sync (benutze ich nicht) da ein Problem mit temporären Dateien.

 

[Happyboy]

Ich habe eben ein Ticket aufgemacht. Warten wir vielleicht erst mal ab.

Außer 2 Neustarts habe ich seit September nichts weiter gemacht.