Beiträge von tgsbn

Zitat von dolbyman

zwei RAID1 mit gleich grossen Platten macht wenig Sinn.

Würde ich so pauschal jetzt nicht sagen.

Von dem mit Firefox ESR, wo es jetzt klappt, hatte ich das Forum noch nie aufgerufen.

Der Windows-PC mit Firefox 92.0.1, wo es jetzt nicht klappt, war früher mein Standard-PC für den Zugriff aufs Forum, wann ich da zuletzt die Antwort-Funktion benutzt habe kann ich nicht sagen.

Diese Antwort habe ich erfolgreich vom Linux-PC aus abgeschickt, wo das heute morgen noch nicht ging.

Eine permanent angeschlossene USB-Platte als Sicherungsmedium würde ich nicht empfehlen.

Die Gefahr ist groß, dass ein das NAS treffende Schadensereignis sie gleich mit erwischt.

• Bei Ransomware-Befall kann die Ransomware sie ebenfalls verschlüsseln oder löschen, um die Motivation zur Lösegeldzahlung zu steigern.
• Bei Feuer-, Wasser- oder Überspannungsschäden kann die Sicherungsplatte zusammen mit dem NAS beschädigt werden.
• Bei Diebstahl oder Beschlagnahme des NAS durch kann die Sicherungsplatte gleich mit gestohlen bzw. beschlagnahmt werden.
• Ein technischer Defekt mit Datenverlust kann auf die Sicherungsplatte durchschlagen.

Deshalb sind mehrere abwechselnd eingesetzte USB-Platten, die nur für die Dauer des Sicherungsvorgangs angeschlossen und ansonsten getrennt vom NAS gelagert werden, unbedingt zu empfehlen.

Zitat von tiermutter

Browser up to date?

Mozilla Firefox 92.0.1 (64-Bit) auf Linux Mint. Laut Paketverwaltung aktuell.

Und ja, Antworten geht auch nicht.

Dasselbe Bild auf einem anderen PC mit Windows 10, sowohl mit Firefox 92.0.1 (ganz frisch aktualisiert) als auch mit Microsoft Edge Version 94.0.992.38 und Microsoft Internet Exploder.

Im MSIE hatte ich das Forum noch nie aufgerufen, also kann es auch nicht irgendetwas mit stale cookies oder Cache zu tun haben.

Diese Antwort schicke ich von einem dritten PC, ebenfalls Windows 10, aber Firefox 78.13.0esr. Da funktioniert's.

Seit heute funktioniert anscheinend die Funktion "Alle Foren als gelesen markieren" in der Ansicht "Ungelesene Beiträge" nicht mehr.

Das Häkchen-Icon ist anklickbar, hat aber keine Wirkung: die Liste der ungelesenen Beiträge bleibt unverändert.

Wenn ich einen Beitrag öffne und danach die Liste wieder aufrufe, ist er korrekt daraus verschwunden.

Die Gelesen-Verwaltung funktioniert also grundsätzlich, nur das Als-gelesen-Markieren der ganzen Liste nicht.

Doch, doch, das ist normal. Jedenfalls bei QNAP. Gerade HBS3 produziert gerne mal "überraschende" Fehler.

Eine mögliches Szenario: Die USB-Anbindung der Festplatte ist ein bisschen wacklig. Wenn die Verbindung kurz unterbrochen wird, wird der alte Job abgebrochen und triggert den Auswurf der Platte. Bevor der abgeschlossen ist, wird die Platte wieder erkannt und der Job erneut gestartet. Bis der dann loslaufen will, ist allerdings dann der Auswurfbefehl ausgeführt und der neue Job beschwert sich, dass das Backup-Ziel nicht da ist.

(Passiert mir regelmäßig mit der USB-Platte von der QNAP Kompatibilitätsliste, die ich extra angeschafft habe, um QNAP Support Cases aufmachen zu können. Die scheint von ziemlich schlechter Qualität zu sein - die anderen, "inkompatiblen" Platten machen keine solchen Sperenzchen.)

Ein weiteres Szenario: Die Volume Labels der beiden Platten sind gleich oder eins von beiden enthält ein Leerzeichen. Dann gerät die Volume-Verwaltung von HBS3 durcheinander, fängt an die beiden Platten zu verwechseln und beschwert sich dann, wenn auf der einen ein Ordner nicht da ist, den es auf der anderen doch angelegt hat.

Es gibt sicher noch viele weitere Situationen, die die QNAP-Programmierer nicht bedacht haben und die deshalb zu "undefiniertem Verhalten" führen, wie das im Informatikerjargon dann heißt.

Auch wenn sich nicht viel getan hat, mal ein kleiner Zwischenstand aus der Bearbeitung des Supporttickets:

• Das Ticket wurde von einem anderen Bearbeiter übernommen.
• Ich wurde gebeten, den Remote Support zu aktivieren. Das habe ich getan, es hat sich aber nie jemand verbunden.
• Stattdessen wurde ich drei Tage später aufgefordert, auf Firmware-Version 4.5.4.1800 zu aktualisieren und zu testen, ob das Problem damit weiterhin auftritt. Wenig überraschend war das der Fall.

Bin gespannt, was die nächste Ausrede ist, warum der Fall noch nicht an die Entwicklung eskaliert werden kann.

Meine Erfahrung ist, dass die Verarbeitungszeiten von HBS3 ohne ersichtlichen Grund massiv schwanken.

Auf meinem kleinen Heim-NAS (TS-228A, 2x 6TB RAID1) dauert die regelmäßige Sicherung der wichtigen 350 GB per HBS3 auf ein und dieselbe USB-Festplatte irgendetwas zwischen 1h (24 GB übertragen) und 4,5h (10 GB übertragen).

Immer mit denselben Einstellungen.

Auch die Fortschrittsanzeige gibt keinen Hinweis darauf, was diesen enormen Zeitbedarf und die Schwankungen verursacht.

Meistens bleibt sie bei 5% erst einmal ein bis zwei Stunden ohne erkennbare Aktivität hängen, aber manchmal geht es da auch ohne Stocken drüber und kommt dafür irgendwann später eine Weile zum Stillstand.

QuDedup ist aus - ich lege Wert darauf, ohne Zusatzsoftware direkt an meine Daten auf der Sicherung zu kommen.

Tja, zu früh gefreut. Heute meldete ebendieser HBS3-Job trotz nach wie vor aktivierter Option "Remove additional files in destination folder" den Fehler "Cannot create a multi-version backup."

Der QNAP-Support hat jetzt die Theorie geäußert, das Problem könnte durch ein HBS-Update ausgelöst worden sein. Tatsächlich wurde HBS3 Version 17.2.0726 laut App Center am 2021/08/06 installiert, was bei den Jobs, die das Problem haben, zwischen dem letzten erfolgreichen und dem ersten fehlerhaften Backup-Lauf liegt. Nicht so ganz dazu passt aber meiner Meinung nach das Hin und Her mit der Option "Remove additional files in destination folder."

Ich werde weiter berichten.

Zitat von Anthracite

Einen Schutz bietet die Verschlüsselung nur für den Fall, dass Diebe bei dir einsteigen und das NAS inklusive Festplatten klauen.

Es gibt noch einen Use Case: das sichere Löschen der Daten, wenn man die Platten oder das ganze NAS entsorgen, verkaufen oder in einem anderen Sicherheitskontext wiederverwenden will. Statt die kompletten Daten sicher zu löschen reicht es dann, alle Kopien des Schlüssels zu vernichten.

Zitat von tiermutter

Einzig mir bekannte Einschränkung im RAID bei QNAP ist, dass man HDD und SSD nicht mischen kann.

PMR und SMR sollte man auch nicht mischen.

Aber dass 5400 gegen 7200 min⁻¹ Probleme machen würden habe ich noch nicht gehört.

Zitat von Francesco2017

In der Kompatibilitätsliste sind die LW für die TS131K natürlich alle nicht [...]

Eventuell liegt ja auch ein Hardwareproblem an den USB Anschlüssen vor (?). Da der NAS noch in der Garantie ist, werde ich

da mal ein Ticket erstellen.

Meine Empfehlung: wenn du ein Ticket erstellen willst, besorge dir vorher eine USB-Platte, die auf der Kompatibilitätsliste steht.

Der QNAP-Support wird als erstes (bzw. als zweites, nach der Abfrage deiner QTS- und HBS3-Version) nach dem Typ der USB-Platte fragen und prüfen, ob die auf der Kompatibilitätsliste steht.

Wenn nicht, wird das Ticket geschlossen.

Zitat von tiermutter

Ansonsten habe ich aber recht gute Erfahrungen mit dem Support, man darf halt nicht vergessen, dass dort auch keine Entwickler sitzen und erstmal oberflächlich nach Lösungen gesucht wird und eine Fehlbedienung seitens User ausgeschlossen werden muss, bis es weiter eskaliert wird und sich Profis der Sache annehmen.

Meine Erfahrung mit dem Support ist, dass er eben nicht nach Lösungen sucht, sondern nach Gründen, den Case zu schließen. Insbesondere tut er alles, um die Eskalation zu den Profis zu verhindern. Priorität hatte bei jedem meiner bisherigen Cases weder der Ausschluss einer Fehlbedienung noch die Suche nach Lösungen, sondern eindeutig die gezielte Suche nach Umständen, die einen Grund liefern könnten, keinen Support zu leisten.

Zitat von tiermutter

Wurde denn irgendwas, evtl. auch Verstecktes, bei dem Backup weggelassen?

Nicht, dass ich wüsste.

Zitat von tiermutter

Und was passiert, wenn der nächste Job ohne die Option gestartet wird?

Naheliegende Frage, hätte ich auch selber drauf kommen können.

Getestet:

• Option "Remove additional files in destination folder" deaktiviert, Backup gestartet: Fehler

Warning	2021-08-29	12:25:34	admin	127.0.0.1	Hybrid Backup Sync	Custom Job Event	[Hybrid Backup Sync] Finished Backup job "ImageStore" with errors. Failed to create multiple versions for backup.

• Option "Remove additional files in destination folder" wieder aktiviert, Backup gestartet: kein Fehler

Information	2021-08-29	13:11:38	admin	127.0.0.1	Hybrid Backup Sync	Job Status	[Hybrid Backup Sync] Finished Backup job: "ImageStore".

Scheint also tatsächlich an der Option zu hängen.

Jetzt habe ich mal aus einer Eingebung heraus in Rules > Policies die Option "Remove additional files in destination folder" aktiviert - und was soll ich sagen: der Fehler ist weg!

Genauer:

Ich dachte mir, irgendwas ist vielleicht in dem Zielordner auf der USB-Platte, was die Hardlink-Erzeugung für die Versionierung stört.

Also, dachte ich mir, wie werde ich das los? Wenn ich, während der Ordner aus der Sicherung ausgenommen ist, diese Option aktiviere, löscht HBS3 dann vielleicht auch den Zielordner? Hat es aber nicht getan. Natürlich ist die Sicherung fehlerfrei gelaufen, wie immer wenn ich den Download-Ordner ausgenommen habe, aber auf der USB-Platte war er unter "latest" trotzdem noch da.

Dann habe ich - jetzt kommt die Eingebung - den Download-Ordner wieder in die Sicherung mit reingenommen, aber die Option "Remove additional files in destination folder" aktiv gelassen. Und siehe da: die Sicherung lief nun auch unter Einschluss des Download-Ordners fehlerfrei durch.

Erklärungsversuche willkommen. Ich werde das jetzt sukzessive mit den anderen betroffenen Platten auch testen, ob das nur Zufall war oder tatsächlich systematisch hilft. Falls letzteres, werde ich diese Option generell aktiv lassen. Da sie die "additional files" offenbar nur aus der "latest"-Sicherung löscht und in den datierten Versionen drin lässt, wäre das kein Verlust an Sicherheit.

Der kopierte Ordner lässt sich einwandfrei sichern.

Allerdings lässt sich auch der Originalordner "Download" in einem neu angelegten Job fehlerfrei sichern.

In drei meiner vorhandenen Jobs verursacht er hingegen nach wie vor den Fehler "Cannot create a multi-version backup."

Dort allerdings auch, wenn ich alle anderen drei Ordner abwähle und nur ihn alleine zu sichern versuche.

Wenn ich andererseits nur den Ordner "Download" abwähle, werden die übrigen drei fehlerfrei gesichert.

Und dann gibt es auch noch zwei vorhandene Jobs, in denen alle vier Ordner nach wie vor fehlerfrei gesichert werden.

Gemeinsamkeiten der fehlschlagenden Jobs sehe ich mittlerweile keine mehr:

• Die meisten Einstellungen sind ohnehin bei allen meinen Jobs identisch, z.B. habe ich die Option "Do not take snapshots" bei keinem meiner Jobs aktiviert.
• Bei allen meinen Jobs ist Version Management aktiv, teils "Simple", teils "Smart". Unter den fehlschlagenden Jobs sind sowohl welche mit "Simple" als auch mit "Smart" Versioning.
• Eine meiner fünf Sicherungsplatten ist NTFS-formatiert, die anderen vier mit ext4. Auf der NTFS-Platte ist der Fehler bis jetzt nicht aufgetreten. Von den vier ext4-Platten schlägt auf zweien das Backup des Download-Ordners fehl, auf einer läuft es fehlerfrei. Auf der vierten produziert der reguläre Job den Fehler, der obige Testjob aber nicht.

Ich habe keine Idee mehr, was da die Problemursache sein könnte. Zumal ja auch nichts darüber herauszubekommen ist, woran denn das "create a multi-version backup" tatsächlich scheitert. "Cannot" - basta.

QNAP-Support hat erwartungsgemäß geantwortet:

Zitat von QNAP Support

vielen dank das Sie sich an den Qnap Support gewendet haben. Bitte führen Sie zunächst ein Update auf die aktuelle Firmware Version und die aktuelle HBS Version durch. Prüfen Sie, nach einem Neustart im Anschluss an die Updates, ob das Problem weiterhin besteht

Also kein Support ohne vorheriges Update.

Zitat von Crazyhorse

Der Inhalt kopiert in in einen Ordner BUtest, lässt der sich sichern?

Das ist mir nicht ganz klar, was ich da testen soll. Soll ich BUtest als eine separate neue Freigabe anlegen oder als Ordner unter einer der vorhandenen Freigaben, die sich sichern lassen? Soll ich dann BUtest alleine sichern oder den Sicherungsjob, der aktuell bei Einschluss des Ordners Download fehlschlägt und ohne ihn erfolgreich ist, auf BUtest anstelle von Download umstellen?

Ich frage so dumm, weil mir nicht ganz klar ist, welche Aussage Du Dir von diesem Test erhoffst. Es ist ja nicht so, dass sich der Ordner Download grundsätzlich nicht sichern lässt. Nur auf drei meiner fünf Sicherungsplatten schlägt es fehl, auf den anderen beiden läuft die Sicherung einwandfrei durch.

Deine Frage liest sich so, als ob Du nach dem Update einfach die vorhandenen Jobs weiterbenutzen wolltest.

Das ist keine gute Idee.

Die automatische Übernahme vorhandener HBS2-Jobs in HBS3 ist für Ärger bekannt.

Selbst wenn sie zunächst zu funktionieren scheinen, können mit der Zeit die wunderlichsten Effekte auftreten.

Deshalb ist es das beste, alle vorhandenen Jobs zu löschen und erst danach die, die man weiter benutzen will, neu anzulegen.

Ok, gutes Argument.

Ticket Q-202108-68158 erstellt.

Schau'n wir mal, wann und wie QNAP reagiert.

Der Ordner "Download" enthält (wie der Name schon sagt) nur meine Sammlung aus dem Internet heruntergeladener Dateien, also einerseits nichts unersetzliches und andererseits nur Dateien mit verhältnismäßig "normalen" Namen, nichts überlanges oder mit komischen Zeichen drin - schließlich wollen die Anbieter ja auch, dass der Download bei jedem klappt.

Den vorgeschlagenen Test, diesen Ordner mal von der Sicherung auszunehmen, habe ich gemacht.

Und tatsächlich: ohne den Ordner "Download" läuft die Sicherung fehlerfrei durch.

Nehme ich ihn wieder rein, ist auch der Fehler wieder da.

Scheint also doch irgendetwas mit dem Inhalt dieser Freigabe zu tun zu haben.

Nur was, warum erst jetzt und warum nur bei Sicherung auf eine ext4-formatierte Platte?

Die Längen der Dateipfade in der Freigabe habe ich geprüft.

Der längste Pfad ist

"Documents/Exchange-Schulung/Exchange/Hardening Microsoft Exchange 2016 Server-Dateien/You_do_not_have_the_permission_to_send_the_message_on_behalf_of_tn.gif"

mit 157 Zeichen, die längste Pfadkomponente (Datei- oder Ordnername)

"18362.30.190401-1528.19h1_release_svc_refresh_CLIENTENTERPRISEEVAL_OEMRET_x64FRE_de-de.iso"

mit 91 Zeichen.

Ok, für einen alten System-III-Unixer (max. 14 Zeichen), PDP-11-er (9+3) oder CP/M-ler (8+3) schon exzessiv, aber für heutige Verhältnisse doch noch im Rahmen.

Die letzte dazugekommene Datei ist:

Software/ct2112_desinfect_2021.iso

am 2021-06-29 20:45:08. Danach liefen noch zwei erfolgreiche Backups auf die Platte, mit der ich jetzt getestet habe.

Alles sehr merkwürdig. Bin gespannt, was der QNAP Support sagt.

Das Problem weitet sich aus. Heute ist der Fehler bei einer dritten Platte aufgetreten. Da das meine eigens für einen früheren QNAP Support Case beschaffte einzige auf der QNAP Hardware Compatibility List stehende Platte ist, könnte ich jetzt einen Support Case aufmachen. Aber vorher müsste ich QTS aktualisieren, da wird sich der Support sonst erfahrungsgemäß sofort dran aufhängen. Das wird also jedenfalls heute nichts mehr.

Weitere Beobachtungen:

• Wenn das Problem bei einer Platte einmal aufgetreten ist, tritt es auch bei jeder weiteren Sicherung auf diese Platte wieder auf.
• Die drei bis jetzt betroffenen Platten sind alle mit ext4 formatiert, die beiden bisher nicht betroffenen mit NTFS.

Zumindest bis jetzt - bin gespannt, ob es dabei bleibt.