UGREEN NAS Btrfs-Scrub: Daten per Hand und Zeitplan prüfen

Btrfs speichert zu jedem Datenblock eine Prüfsumme. Diese Prüfsummen nützen aber nur, wenn jemand die Daten auch liest und vergleicht. Genau das macht ein Btrfs-Scrub: Er liest alle Daten und Metadaten eines Volumes und meldet jede Abweichung. Die App Speicher von UGOS Pro bietet dafür keine Schaltfläche, über SSH ist ein Scrub aber in einer Minute gestartet. Diese Anleitung zeigt Schritt für Schritt, wie Sie auf einer UGREEN NAS einen Btrfs-Scrub per Hand starten, das Ergebnis lesen und ihn als Zeitplan einrichten.

Geprüft auf einer UGREEN DXP4800 Pro mit UGOS Pro 1.21.0.0190 und btrfs-progs 6.2. Alle Ausgaben stammen von diesem Gerät, der Scrub des SSD-Volumes lief am 03.11.2026.

Voraussetzungen

• Ein Volume mit dem Dateisystem Btrfs, siehe Teil 13
• Ein Konto mit Administratorrechten, das sudo nutzen darf
• SSH-Zugang zur NAS und ein Terminal auf Ihrem Rechner
• Eine aktuelle Sicherung, denn ein Scrub repariert nur, was Btrfs aus einer zweiten Kopie ersetzen kann
• Etwa 15 Minuten für die Einrichtung, der Scrub selbst läuft danach je nach Größe Minuten bis viele Stunden

Schritt 1: SSH aktivieren

Öffnen Sie die Systemsteuerung und klicken Sie unter Konnektivität & Zugriff auf Terminal. Setzen Sie bei SSH den Haken Aktivieren und klicken Sie auf Übernehmen.

Bei uns läuft SSH auf dem Standardport 22, Telnet bleibt aus. Die Option Automatisch deaktivieren schaltet SSH nach einer gewählten Zeit wieder ab. Wer SSH nur für einzelne Wartungsarbeiten braucht, nutzt sie. Auch für einen Scrub per Zeitplan muss SSH nicht dauerhaft laufen, denn der Zeitplan arbeitet auf der NAS selbst. UGOS empfiehlt in der Beschreibung ein sicheres Passwort und die automatische Blockierung. Mehr zu SSH folgt in einem eigenen Teil dieser Serie.

Melden Sie sich dann von Ihrem Rechner an. Ersetzen Sie Benutzer und Adresse durch Ihre eigenen Werte:

ssh admin@192.168.1.10

Verifizieren: Sie sind per SSH auf der NAS angemeldet und sehen eine Eingabezeile.

Schritt 2: Die Btrfs-Volumes finden

Welche Volumes Btrfs nutzen, zeigt die App Speicher unter Speicher, Reiter Speicherpool & Volume.

Bei uns nutzen beide Volumes Btrfs. Auf der Kommandozeile heißen sie /volume1 und /volume2. Wie Btrfs die Daten ablegt, verrät dieser Befehl:

sudo btrfs filesystem df /volume1

Die Ausgabe auf unserer NAS, gekürzt auf die wichtigen Zeilen:

Data, single: total=19.09TiB, used=18.94TiB
System, DUP: total=8.00MiB, used=2.00MiB
Metadata, DUP: total=21.00GiB, used=20.62GiB

Diese Zeilen bestimmen, was ein Scrub kann. Data, single heißt: Von den Nutzdaten gibt es im Dateisystem nur eine Kopie. Findet der Scrub hier einen Fehler, meldet er ihn, kann ihn aber nicht aus einer zweiten Btrfs-Kopie ersetzen. Metadata, DUP heißt: Die Metadaten liegen doppelt vor. Fehler dort kann Btrfs aus der zweiten Kopie reparieren. Das ist der Grund, warum der Scrub trotzdem wertvoll ist: Er findet beschädigte Dateien, bevor sie unbemerkt in Ihre Sicherung wandern.

Verifizieren: Sie kennen die Pfade Ihrer Btrfs-Volumes und wissen, ob die Daten auf single oder DUP stehen.

Schritt 3: Den bisherigen Scrub-Status prüfen

Bevor Sie starten, lohnt ein Blick darauf, ob schon einmal ein Scrub lief:

sudo btrfs scrub status /volume1

Auf unserem Festplatten-Volume lautet die Antwort:

no stats available
Total to scrub:   18.98TiB
Rate:             0.00B/s
Error summary:    no errors found

no stats available bedeutet: Für dieses Volume ist kein Scrub-Ergebnis gespeichert, bei uns lief dort also noch kein Btrfs-Scrub. Die Zeile no errors found sagt in diesem Fall also nichts über den Zustand der Daten aus. Die App Speicher bietet keinen Scrub an, obwohl die Datenorganisation aus Teil 19 prüft das RAID, nicht die Prüfsummen von Btrfs.

Verifizieren: Sie wissen, ob und wann auf Ihren Volumes zuletzt ein Scrub lief.

Schritt 4: Einen Scrub per Hand starten

Beginnen Sie mit dem kleinsten Volume, dann sehen Sie den Ablauf schnell. Bei uns ist das das SSD-Volume:

sudo btrfs scrub start /volume2

Der Befehl kehrt sofort zurück, der Scrub läuft im Hintergrund weiter:

scrub started on /volume2, fsid 2ce5b1c3-51b1-45fc-ba4b-db4ae73e185f (pid=193052)

Den Fortschritt fragen Sie mit status ab. Nach fünf Sekunden sah das bei uns so aus, gekürzt:

Status:           running
Duration:         0:00:05
Time left:        0:02:09
Total to scrub:   206.50GiB
Bytes scrubbed:   7.66GiB  (3.71%)
Rate:             1.53GiB/s
Error summary:    no errors found

Für große Festplatten-Volumes hat der Befehl eine nützliche Option. Mit -c 3 läuft der Scrub in der Ein-/Ausgabeklasse idle. Er bekommt dann nur Plattenzeit, wenn sonst nichts zu tun ist, und bremst andere Zugriffe in der Regel weniger:

sudo btrfs scrub start -c 3 /volume1

Ein laufender Scrub lässt sich jederzeit anhalten und später fortsetzen:

sudo btrfs scrub cancel /volume1
sudo btrfs scrub resume -c 3 /volume1

Verifizieren: status zeigt running und einen steigenden Wert bei Bytes scrubbed.

Schritt 5: Das Ergebnis lesen

Ist der Scrub fertig, zeigt status das Ergebnis. Unser SSD-Volume:

Scrub started:    Tue Nov  3 07:53:04 2026
Status:           finished
Duration:         0:02:08
Total to scrub:   206.50GiB
Rate:             1.61GiB/s
Error summary:    no errors found

206,5 GiB in 2 Minuten und 8 Sekunden, ohne Fehler. Entscheidend ist die letzte Zeile. Hat der Scrub beschädigte Blöcke gefunden, stehen unter Error summary statt no errors found Fehlerarten wie csum für Prüfsummenfehler, darunter die Zeilen Corrected und Uncorrectable mit ihrer Anzahl. Corrected bedeutet, dass Btrfs die Blöcke aus einer zweiten Kopie ersetzen konnte. Uncorrectable bedeutet, dass die betroffenen Daten aus der Sicherung kommen müssen.

Zusätzlich führt Btrfs eigene Fehlerzähler je Gerät:

sudo btrfs device stats /volume1

Bei uns stehen alle fünf Zähler auf 0: write_io_errs, read_io_errs, flush_io_errs, corruption_errs und generation_errs. Steigt einer davon, lohnt ein Blick auf die SMART-Werte der Platten, wie in Teil 18 beschrieben.

Verifizieren: Status finished, no errors found und alle Gerätezähler auf 0.

Schritt 6: Einen Zeitplan einrichten

UGOS bringt einen Cron-Dienst mit, auf unserer NAS ist er aktiv. Die Crontab von root war bei uns leer. Öffnen Sie sie zum Bearbeiten:

sudo crontab -e

Tragen Sie für jedes Btrfs-Volume eine Zeile ein. Dieses Beispiel startet den Scrub für das Festplatten-Volume alle drei Monate am 5. um 2 Uhr nachts mit niedriger Priorität, und das SSD-Volume monatlich am 5. um 1 Uhr:

0 2 5 */3 * /usr/bin/btrfs scrub start -c 3 /volume1
0 1 5 * * /usr/bin/btrfs scrub start /volume2

Den Pfad /usr/bin/btrfs zeigt which btrfs. Cron arbeitet ohne die Suchpfade Ihrer Anmeldung, deshalb gehört der volle Pfad in die Zeile. Prüfen Sie danach mit sudo crontab -l, ob die Einträge gespeichert sind.

Wählen Sie den Termin mit Abstand zu den anderen schweren Aufgaben: Bei uns läuft die Datenorganisation am 20. eines Monats und der SMART-Volltest am 1. Ein Scrub am 5. kommt keinem davon in die Quere. Achten Sie auch darauf, dass ein Zeitplan zum Herunterfahren aus Teil 10 die Nacht nicht abschneidet. Eigene Einträge in der Crontab gehören nicht zur Oberfläche von UGOS. Kontrollieren Sie deshalb nach jedem Systemupdate mit sudo crontab -l, ob sie noch vorhanden sind.

Verifizieren: sudo crontab -l zeigt Ihre Einträge, und nach dem ersten Termin zeigt btrfs scrub status ein aktuelles Datum.

Typische Fehler beim Btrfs-Scrub

Symptom	Ursache und Lösung
no stats available	Auf dem Volume lief noch nie ein Scrub. Einen Scrub per Hand starten.
ERROR: not a btrfs filesystem	Das Volume nutzt ext4. Ein Btrfs-Scrub ist dort nicht möglich.
Befehl bricht mit einem Rechtefehler ab	Ohne sudo gestartet. Befehl mit sudo und einem Administratorkonto ausführen.
NAS während des Scrubs langsam	Der Scrub liest alle Daten. Mit -c 3 starten oder in die Nacht legen.
Scrub per Zeitplan läuft nicht	Kein voller Pfad in der Crontab oder Eintrag nach einem Update verschwunden. Mit sudo crontab -l prüfen.
Fehler als uncorrectable gemeldet	Keine zweite Kopie der Daten. Betroffene Dateien aus der Sicherung zurückholen, SMART-Werte prüfen.

Häufige Fragen

Wie oft sollte ein Scrub laufen?

Für große Festplatten-Volumes ist alle drei Monate ein gängiger Rhythmus, für kleine SSD-Volumes ist monatlich ohne spürbare Last gut machbar. Die Btrfs-Entwickler nennen monatlich als üblichen Rhythmus, bei großen Festplatten-Volumes spricht die lange Laufzeit für größere Abstände.

Wie lange dauert ein Scrub?

Das hängt von Datenmenge und Platten ab. Unser SSD-Volume schaffte 1,61 GiB pro Sekunde. Festplatten sind deutlich langsamer, bei fast 19 TiB rechnen Sie mit vielen Stunden.

Kann ich während des Scrubs arbeiten?

Ja. Der Scrub läuft im Hintergrund, Zugriffe werden aber langsamer. Mit -c 3 fällt das weniger auf.

Muss SSH für den Zeitplan aktiv bleiben?

Nein. Cron läuft auf der NAS selbst. SSH brauchen Sie nur zum Einrichten und für einen Blick auf das Ergebnis. Danach können Sie SSH wieder abschalten oder automatisch deaktivieren lassen.

Ersetzt der Scrub die Datenorganisation?

Nein. Der Scrub prüft die Daten im Dateisystem anhand der Prüfsummen, die Datenorganisation das RAID auf Ebene der Platten. Beide ergänzen sich.

Fazit

Ein Btrfs-Scrub ist schnell gestartet und macht die Prüfsummen von Btrfs erst nützlich. Er zeigt beschädigte Dateien, bevor sie unbemerkt in die Sicherung gelangen, und repariert Metadaten aus ihrer zweiten Kopie. Mit einem Eintrag in der Crontab läuft er regelmäßig, nachts und mit niedriger Priorität. Zusammen mit Datenorganisation und SMART-Tests prüfen Sie Ihren Speicher damit auf drei Ebenen. Werfen Sie nach jedem Termin einen Blick auf sudo btrfs scrub status, denn der Cron-Eintrag meldet Fehler nicht von selbst.

Weiterführende Anleitungen und Quellen

• Teil 13: Btrfs oder ext4
• Teil 18: SMART-Werte lesen
• Teil 19: Datenorganisation
• Btrfs-Dokumentation: btrfs-scrub
• Btrfs-Dokumentation: btrfs-device