Ein NAS ist kein Backup!

Heute habe ich eine sehr interessante und zugleich lehrreiche Lektion von QNAP erhalten, warum ein NAS kein Backup ist und das NAS selbst gesichert werden muss. Das könnte auch dir passieren.

Vor Kurzem habe ich das RAID-Scrubbing auf meinen Volumes durchgeführt. Zuvor hatte ich das noch nie gemacht. Aufgrund eines Problems, das ich hatte, habe ich meine Dump-Logs zum Ticket hinzugefügt. Der Techniker hat mir daraufhin mitgeteilt, dass ich eine Reihe von ZFS-Dateisystemfehlern habe, die nicht behoben werden können, und dass ich mein NAS neu initialisieren und komplett von vorne anfangen muss!

Das liegt nicht an defekten Festplatten (es tritt sowohl bei meinen SSDs als auch bei meinen Haupt-RAID-HDs auf). Er sagte, dass dies auch bei guten Festplatten passieren kann, aber manchmal werden Daten beim Schreiben beschädigt und man kann nichts dagegen tun. Er meinte, ich solle sicherstellen, dass alle Daten vom NAS gesichert sind, das NAS neu initialisieren und von vorne beginnen! Ich konnte es kaum glauben.

Also – eine weitere Warnung – das NAS selbst ist kein Backup. Du kannst zwar deine PCs auf das NAS sichern, aber sichere dein NAS auch woanders! Es ist nicht unbedingt eine defekte Festplatte, die Probleme verursachen kann.

Ich freue mich schon sehr darauf, das zu machen! Wenigstens werde ich wieder auf h5.2 zurückgehen, da h5.3 wirklich noch nicht fertig ist und eigentlich nur für High Availability-Anwendungen notwendig ist…

1 „Gefällt mir“

Deshalb war ich Quts und all den Dingen, die es im Hintergrund macht, gegenüber immer misstrauisch. Ich hatte kürzlich überlegt, auf Quts umzusteigen, aber ich bleibe vorerst bei Qts.

Korrekt: Ein NAS ist niemals eine sichere Methode für Backups. RAID ist ebenfalls kein Backup. Daher die 3-2-1-Regel. Das ist wahrscheinlich das größte Missverständnis beim Einsatz von NAS und RAID. Sie minimieren zwar die Wiederherstellungszeit, aber allein schützen sie nicht vor einem Brand oder Hardwareausfall.

2 „Gefällt mir“

Egal ob QNAP, Syno oder etwas anderes

War es nie und wird es nie sein

Wenn das NAS das Backup (eine Kopie der Daten) war, dann IST das NAS ein Backup und kann aus den Originaldateien wiederhergestellt werden

1 „Gefällt mir“

Ich habe Ende 2024 ein brandneues TS-464C2 gekauft und innerhalb eines Monats hat es meinen gesamten Speicherpool zerstört. Ich bin auf QuTS Hero umgestiegen und habe bald darauf Prüfsummenfehler auf allen meinen Laufwerken festgestellt, woraufhin mir klar wurde, dass es sich um ein NAS-Problem handelt. Ein Memtest bestätigte meinen Verdacht.

Noch schlimmer: Ich habe vom Händler ein weiteres nagelneues Gerät als Ersatz erhalten, und auch dieses hatte Speicherprobleme …

Ich habe tägliche Backups in der Cloud, daher habe ich nur Daten von mehreren Stunden verloren, aber die Wiederherstellung hat mich Tage gekostet.

Für diejenigen, die QuTS Hero verwenden, empfehle ich, regelmäßig eine SSH-Sitzung zu öffnen und diesen Befehl auszuführen:

zpool status -v

So sieht das aus:

[Jono@NA9D-NAS ~]$ zpool status -v
  pool: zpool1
 state: ONLINE
status: Bei einem oder mehreren Geräten ist ein Fehler aufgetreten, der zu Daten-
        korruption geführt hat. Anwendungen könnten betroffen sein.
action: Stellen Sie die betreffende Datei nach Möglichkeit wieder her. Andernfalls stellen Sie
        den gesamten Pool aus einem Backup wieder her.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: Scrub hat 0 in 0 Tagen 00:15:53 mit 2 Fehlern am So 19. Okt 00:15:58 2025 repariert
 prune: Zuletzt 409 Einträge bereinigt, insgesamt wurden 2392 Einträge jemals bereinigt
        Gesamte Bereinigungsanzahl #5, durchschnittliche Bereinigungsrate = 2986468 (Einträge/Sek.)
expand: Keine angefordert
 renew: Keine angefordert
config:

	NAME                                    STATE     READ WRITE CKSUM
	zpool1                                  ONLINE       0     0     2
	  mirror-0                              ONLINE       0     0     4
	    qzfs/enc_0/disk_0x1_24074767F6C0_3  ONLINE       0     0     4
	    qzfs/enc_0/disk_0x2_24534D52401A_3  ONLINE       0     0     4

errors: Permanente Fehler wurden in den folgenden Dateien festgestellt:

        zpool1/$SHADOW:<0x1> (181:1:0:5046392)
        zpool1/$SHADOW:<0x1> (181:1:0:5046393)

  pool: zpool2
 state: ONLINE
status: Bei einem oder mehreren Geräten ist ein Fehler aufgetreten, der zu Daten-
        korruption geführt hat. Anwendungen könnten betroffen sein.
action: Stellen Sie die betreffende Datei nach Möglichkeit wieder her. Andernfalls stellen Sie
        den gesamten Pool aus einem Backup wieder her.
   see: http://illumos.org/msg/ZFS-8000-8A
  scan: Scrub hat 0 in 5 Tagen 04:25:26 mit 16 Fehlern am Fr 24. Okt 04:25:37 2025 repariert
 prune: Zuletzt 2637224 Einträge bereinigt, insgesamt wurden 15879437 Einträge jemals bereinigt
        Gesamte Bereinigungsanzahl #5, durchschnittliche Bereinigungsrate = 3490183 (Einträge/Sek.)
expand: Keine angefordert
 renew: Keine angefordert
config:

	NAME                                        STATE     READ WRITE CKSUM
	zpool2                                      ONLINE       0     0   364
	  raidz1-0                                  ONLINE       0     0   728
	    qzfs/enc_0/disk_0x3_5000CCA27EC5F5A5_3  ONLINE       0     0     0
	    qzfs/enc_0/disk_0x4_5000CCA267CD00FE_3  ONLINE       0     0     0
	    qzfs/enc_0/disk_0x5_5000CCA273F0B2D9_3  ONLINE       0     0     0
	    qzfs/enc_0/disk_0x6_5000CCA27EC5A850_3  ONLINE       0     0     0

errors: Permanente Fehler wurden in den folgenden Dateien festgestellt:

        zpool2/$SHADOW:<0x1> (181:1:0:29628189)
        zpool2/$SHADOW:<0x1> (181:1:0:764458)
        zpool2/$SHADOW:<0x1> (181:1:0:12855854)
        zpool2/$SHADOW:<0x1> (181:1:0:784706)
        zpool2/$SHADOW:<0x1> (181:1:0:57489228)
        zpool2/$SHADOW:<0x1> (181:1:0:57232981)
        zpool2/$SHADOW:<0x1> (181:1:0:57499738)
        zpool2/$SHADOW:<0x1> (181:1:0:5362782)
        zpool2/$SHADOW:<0x1> (181:1:0:1036430)
        zpool2/$SHADOW:<0x1> (181:1:0:5493137)
        zpool2/$SHADOW:<0x1> (181:1:0:5355174)
        zpool2/$SHADOW:<0x1> (181:1:0:57241256)
        zpool2/$SHADOW:<0x1> (181:1:0:30161860)
        zpool2/$SHADOW:<0x1> (181:1:0:5499856)
        zpool2/$SHADOW:<0x1> (181:1:0:754404)
        zpool2/$SHADOW:<0x1> (181:1:0:13872636)

1 „Gefällt mir“

Ich hatte diese Fehler früher schon einmal, aber das ist schon eine Weile her. Ich erinnere mich nicht mehr genau, wie sie behoben wurden, vielleicht musste ich das RAID zerstören und neu erstellen. Ich glaube, ich hatte diese Fehler, als meine USV (UPS) Probleme mit kurzen Stromausfällen hatte, bei denen der Strom für ein oder zwei Sekunden weg war. Nachdem ich die USV durch ein besseres Modell ersetzt habe, ist das bei mir nicht mehr vorgekommen und einige meiner Festplatten liefen schon seit 8 Jahren, einige waren neuer, etwa 2-3 Jahre alt.

Wenn du Stromschwankungen hast, bei denen die USV einen Moment braucht, um Strom an das NAS zu liefern, könnte das die Fehler verursachen.

Ich habe meine Kunden seit vielen Jahren darüber aufgeklärt, weil ich einmal Daten verloren habe, als das RAID-Array auf meinem Netgear NAS abgestürzt ist. Dasselbe ist dann auf meinem Synology NAS passiert, aber zum Glück ist es bei meinen QNAP NAS-Geräten bisher noch nicht passiert. Dennoch sollte man nichts unterschätzen, und die 3-2-1-Backup-Regel ist wichtig, weshalb ich alles von meinem Haupt-NAS auf ein sekundäres NAS sichere.

Übrigens, ich habe deinen Code ausprobiert und er sieht gut aus.
zpool1 und zpool2 Ergebnis → Fehler: Keine bekannten Datenfehler

1 „Gefällt mir“

@marcoi – Ich hatte keine Stromschwankungen oder ähnliches. Wer weiß. Mein anderes Hero NAS funktioniert einwandfrei. Wie mir der QNAP-Techniker sagte, ist nicht bekannt, wie es passiert ist. Vielleicht wurde einfach etwas beim Schreiben beschädigt.

OK. Großer Nervenkitzel hier, da ich gleich dieses Gerät auf die Werkseinstellungen zurücksetze!

:grimacing:

Okay, ich habe meine alten E-Mails von QNAP-Tickets durchgesehen. Das ist übrigens im Jahr 2021 passiert und anscheinend haben sie das Problem gefunden und es per Firmware im Jahr 2022 behoben.

Unten aus den Tickets

Nach Überprüfung sagt das RD-Team, dass die von uns gesehenen Fehler auf einen permanenten Pool-Fehler hindeuten, der leider nicht behoben werden kann. Die einzige Lösung ist daher, einen neuen Pool zu erstellen.
Wenn Sie die Daten bereits woanders haben, sollten Sie die Daten einfach aus diesem ursprünglichen Datensatz zurück in den neuen Pool kopieren. Falls nicht, könnten Sie die Daten von diesem Pool kopieren, um sie zu übertragen, und alle Dateien, die beschädigt sind, sollten vom System übersprungen werden.

Nachdem Sie einen neuen Pool erstellt haben, empfiehlt das Team, monatliches Pool Scrubbing zu planen, um dieses Problem zukünftig zu verhindern (anstatt es nachträglich zu beheben).

Nur ein kurzes Update: Das Team glaubt nicht, dass es sich um ein Hardwareproblem handelt, ist sich aber nicht ganz sicher, was die Ursache ist.
Es tritt eine unbekannte Beschädigung in der „SHADOW“-Schicht des Dateisystems auf, aber sie versuchen immer noch herauszufinden, wie diese Beschädigung entsteht.

Es sieht so aus, als ob es ein neues h5.0.0 Firmware-Release geben wird, geplant für den 31.03., das einen Fix für das Pool-Korruptionsproblem enthält.
Ich versuche immer noch, weitere Informationen von ihnen zu bekommen, aber zumindest sieht es so aus, als ob der Fix bald zu erwarten ist.

Entschuldigung für die späte Antwort, ich habe versucht, einige Informationen mit dem Team zu klären.
Mir wurde gesagt, dass es bald ein neues h5.0.0 Firmware-Update geben soll, irgendwann in den nächsten Tagen, und diese Firmware sollte verhindern, dass zukünftige Pools weiter beschädigt werden.

Es scheint keine Möglichkeit zu geben, bereits beschädigte Daten zu reparieren, falls welche vorhanden sind, aber es wird in Zukunft eine h5.0.1 Version geben, mit der Fehler in bestehenden Pools bereinigt werden können, damit sie weiterhin ordnungsgemäß laufen.

Bitte achten Sie auf das kommende Release, aber wenn Sie Fragen haben, lassen Sie es mich wissen.

Seit 2022 ist dieser Fehler bei mir nicht mehr aufgetreten.

Nicht sicher. Dieses NAS wurde Ende letzten Jahres gekauft und Hero wurde etwa im April oder Mai darauf installiert.

Ich frage mich, ob beim Update auf h5.3 etwas durcheinander geraten ist.

Ich gehe jetzt zurück zu h5.2, da ich HA nicht brauche.

Es kann sein. Es hängt ganz davon ab, wie du den Begriff Backup verstehst. Wenn du glaubst, dass eine einzige Kopie deiner Daten oder ein einzelnes Gerät, das deine Daten speichert, für die Sicherheit eines Backups ausreicht, wird Murphy dich eines Besseren belehren. Das 3-2-1-Prinzip ist das absolute Minimum.