Beiträge von tgsbn

    Am 5.10. schrieb er:

    die 2 Boxen sind dauerhaft über's Internet per Wireguard verbunden.

    Der Fall

    Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    wenn noch keine WireGuard Verbindung besteht.

    trifft also nicht zu und die Aussage

    Mod: Nicht deklariertes Zitat ohne Quellenangabe ... korrigiert! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen

    Tunnel von Fritte zu Fritte einrichten fertig.

    auch nicht.

    Auf meinem TS-228A sind die HBS3-Laufzeiten bei Sicherungsplatten mit NTFS extrem schwankend. Insbesondere das Erzeugen und Löschen großer Dateibäume aus Symlinks, wie HBS3 es bei aktivierter Versionierung zu Beginn jedes Sicherungslaufs macht, scheint die NTFS-Implementierung von QTS bzw. des zugrundeliegenden Linux massiv zu überfordern. Da kann es (muss aber nicht) schon mal ein oder zwei zwei Tage dauern, bis der Job anfängt tatsächlich zu sichern. Die tatsächliche Datenübertragung läuft dann relativ zügig.


    Ich persönlich finde es ja keine so gute Idee, auf einer NTFS-Platte mit großen Mengen von Hardlinks zu operieren. Aber QNAP hatte da offenbar keine Bedenken. Nunja.

    Ich habe ja schon lange immer mal wieder das Problem, dass das Backup mit HBS3 auf eine externe USB-Festplatte nach dem Start stunden- bis tagelang ohne irgendeinen Fortschritt hängt.

    Meistens läuft es dann irgendwann doch weiter, oder es lässt sich durch Stoppen und Neustarten dazu bewegen.


    Diesmal wollte die Sicherung auf einer meiner USB-Platten aber auch nach 14 Tagen und mehreren Neustarts nichts tun. Der Job blieb hartnäckig bei 0% stehen.

    Ich habe mir daraufhin einmal die Sicherungspartition per ssh mit ls -la angeschaut und dort eine Datei namens .job_config.lock vorgefunden.

    Inhalt waren 5 Dezimalziffern, vermutlich eine Prozess-ID. Ein Prozess mit dieser ID war nicht aktiv und der Zeitstempel der Datei auch schon mehrere Monate(!) alt.

    Ich habe daraufhin die Datei gelöscht (d.h. natürlich erst einmal in DELETED.job_config.lock umbenannt), und siehe da: beim nächsten Versuch lief der HBS3-Job klaglos und ohne Verzögerung durch.


    Ich kann nur spekulieren, dass HBS3 diese Lock-Datei bei einem früheren Job gesetzt und (wegen eines Absturzes oder sonstigen Bugs) nicht sauber entfernt hatte, und dass der Stale-Lock-Erkennungsmechanismus nicht richtig funktioniert. (Oder womöglich ganz fehlt ...)


    Vielleicht hilft es ja jemandem in einer ähnlichen Situation.

    Zum Finden der Duplikate würde ich das Linux-Kommando fdupes empfehlen. (Vorausgesetzt das existiert auf dem abgespeckten QNAP-Linux.) Aus dem Output von fdupes dann ln-Kommandos zum Ersetzen der Duplikate durch Hardlinks zu generieren, ist eine reine bash-Fingerübung. Ich habe das vor ein paar Jahren mal auf einem "richtigen" Linux-Server gemacht. Bei Interesse kann ich mal schauen, ob ich noch irgendwo eine Kopie des Skripts von damals finde.

    Die Klassifizierung von Backups in Full / Incremental / Differential stammt aus der Ära der Magnetbänder, die man nur von Anfang an neu beschreiben oder Daten am Ende anhängen konnte. Für Festplatten- oder Storage-Backups, wie HBS3 sie macht, passt sie schlicht nicht mehr.


    Das, was HBS3 macht, ist nach dieser Klassifizierung sowohl ein Full Backup (nach Abschluss der Sicherung befindet sich auf dem Sicherungsmedium eine vollständige Kopie der zu sichernden Daten) als auch ein Incremental Backup (es werden nur die Daten auf das Sicherungsmedium übertragen, die sich seit dem letzten Full Backup geändert haben) und ein Differential Backup (es werden nur die Daten übertragen, die sich seit dem letzten Sicherungslauf geändert haben.) - Die letzeren beiden Aussagen stimmen aber nur bezogen auf das gerade verwendete Medium; wurde eine Datei auf mehrere Medien gesichert und dann geändert, dann wird sie auf jedes Medium beim nächsten Sicherungslauf neu kopiert.


    Das hat Vor- und Nachteile. Einerseits vermeidet es das Problem des stetig wachsenden Platzbedarfs durch zahlreiche Kopien derselben Datei. Andererseits hat man von jeder Datei immer nur die letzte Version. Dem kann man aber durch Aktivieren der Versionierung abhelfen.

    Nimm eine stinknormale (sichere) HDD - die Kompatibilitätsliste bezieht sich meines Wissens nur auf eingebaute (interne) Bauteile.

    Bei externen Laufwerken regelt der Controller des USB-Gehäuse doch wohl die "Kompatibilität"

    Rein technisch ist das korrekt.

    Der QNAP Support sieht das allerdings anders und verweigert die Bearbeitung von Support Cases, bei denen USB-Festplatten beteiligt sind, die nicht auf der Kompatibilitätsliste stehen.

    Wenn man also darauf Wert legt, den QNAP Support in Anspruch nehmen zu können, dann sollte man zumindest eine externe Festplatte parat haben, die auf der Kompatibilitätsliste steht, und für die Dauer der Bearbeitung des Support Case ausschließlich diese verwenden.

    Im verlinkten Handbuch, Seite 45, Kapitel 5 "Troubleshooting":

    Schon, aber da steht halt gar nichts dazu, wie man den Step "Remove the defective drive" dann tatsächlich bewerkstelligt, insbesondere wie man das Gehäuse im laufenden Betrieb öffnet.

    Aber wenn das so einfach geht wie in der von binam verlinkten Animation, ist ja alles prima.

    Sorry, falls das hier das falsche Forum ist, ein passenderes habe ich nicht gefunden ...


    Auf der QNAP-Produktseite für das neue TS-233 prangt hinter "Hot-Swap-fähig" ein grüner Haken.

    Das Gehäuse sieht aber gar nicht so aus, als ob man da im laufenden Betrieb eine Platte herausgefummelt bekäme.

    Also habe ich mir mal das Handbuch für das Teil angeschaut, und siehe da, im Kapitel 3. Installation and Configuration steht unter Drive Installation: 1. Power off the NAS.


    Weiß jemand etwas näheres darüber?

    Kann man beim TS-233 defekte Festplatten im laufenden Betrieb tauschen oder nicht?

    Wenn ja, wie macht man das konkret?

    Windows ist halt leider auch nicht mehr das was es einmal war.

    Damals Funktionierten wenigstens die Grundlegenden Dinge ohne Probleme.

    Hmmm... Das muss aber lange her sein. Meinst du vielleicht Windows 2.1, als es noch ein 16-bit-DOS-Aufsatz war?

    Ich bin erst bei Windows 3.1 ernsthaft eingestiegen. Mit der Einführung von TrueType in dieser Version hatte ich meinen ersten "Spaß" mit Windows, und das hat definitiv nicht ohne Probleme funktioniert. Gut, vielleicht zählt das auch nicht als "grundlegendes" Ding. Dass Dokumente auf dem Papier gleich aussehen wie auf dem Bildschirm, wer braucht das schon?

    Spätestens bei Windows for Workgroups 3.11, der ersten Version mit Netzwerkunterstützung, kann ich jedenfalls aus eigener Erfahrung bezeugen, dass auch und gerade im Netzwerkbereich grundlegende Dinge nicht ohne Probleme funktionierten.

    Na dann bringt der Scan mit dem Windows Defender aber auch nichts. Der ist auch kommerziell. Oder meist Du Microsoft macht dies auch wohltätigen Zwecken?

    Nee, Microsoft macht das, um die wirklich kommerziellen Anbieter (also die, die mit der Antivirensoftware Geld verdienen wollen, statt sie kostenlos einem Betriebssystem beizupacken) auszubooten. Für den Anwender hat das den Vorteil, dass die ganzen nervigen Meldungen "587 Bedrohungen abgewehrt. Bin ich nicht toll!?" wegfallen, weil das Geschäftsmodell es nicht erfordert, den Kunden ständig zu "erinnern", wie gut sein Geld doch in diesem Abo angelegt ist.

    Wie gut die Signaturen sind? Keine Ahnung, kann ich nicht wirklich testen. Habe nur den Echtzeit-Scanner mit EICAR getestet. Funktioniert mit dem auf jeden Fall.

    Das wichtigste ist meiner persönlichen Erfahrung nach eine niedrige False-Positive-Rate. Wenn du viele False Positives hast, steigt die Gefahr, dass du auf einen berechtigten Alarm zu spät oder gar nicht reagierst. ClamAV fällt da komplett durch. Aber auch Trend Micro mit seinen PUA- und Parasite-Meldungen produziert viel zu viel Lärm, sodass die Admins notgedrungen Ohrenschützer aufsetzen und dann die echten Alarme nicht mehr hören, bildlich gesprochen.

    Schlussendlich ist Schadsoftware, die sich in Form von wiedererkennbaren Dateien auf der Festplatte niederlässt und somit von einem NAS-Virenscanner erkannt werden kann, ohnehin ein Auslaufmodell.

    Mal im Ernst: wie wahrscheinlich ist es, dass binnen 4 Tagen irgendjemand ausgerechnet "meine befallenen" Dateien im Mailarchiv gemeldet haben könnte??

    Warum sollten es ausgerechnet deine gewesen sein? So eine ClamAV-Signatur schlägt ja nicht nur bei genau deinen Dateien an. Die typische Ursache für false positives bei ClamAV sind zu unspezifische Signaturen, die außer bei der Schadsoftware, gegen die sie entwickelt wurden, auch bei vielen anderen, völlig harmlosen Dateien ansprechen. Die Wahrscheinlichkeit, dass sehr schnell jemand irgendeine dieser harmlosen Dateien als false positive meldet, ist recht hoch. Und wenn die Signatur daraufhin zurückgezogen wird, profitierst du davon, ohne etwas dafür getan zu haben, indem auch deine 41 Dateien nicht mehr als befallen gemeldet werden.