Beiträge von Anthracite

    Ich habe hier ein Sammelsurium von Transceivern, HP, Intel gebraucht, Cisco gebraucht (waren ziemlich billig), Ubiquiti, 10GTek. Es funktionieren alle, und Unterschiede in der Leistung habe ich nicht feststellen können. Lediglich wenn an den beiden Enden eines Glasfaserkabels Transceiver unterschiedlicher Marken hängen, kann es sein, dass sie nicht wollen.


    Ich würde im Heimbereich versuchen DAC Kabel zu bekommen dann spart man sich die einzelnen Optiken.

    Durchaus richtig, weil DAC-Kabel preiswerter sind und weniger Strom verbrauchen, aber auch im Heimbereich müssen Entfernungen von mehr als fünf Metern überbrückt werden, und dann sind LWL-Kabel erste Wahl.

    Umlaute und unixoide Betriebssysteme sind eine Katastrophe, seit die erste Unix-Version etwa 1970 veröffentlicht wurde.


    Wenn du eine Datei einmalig umbenannt hast, kannst du sie danach dauerhaft auf Mac und auf dem NAS (Shell oder File Station) öffnen?


    Wenn ja:


    Ich hatte solch einen Effekt, nachdem ich Dateien vom Mac nach Linux kopiert hatte. Die Umlaute waren Umlaute, aber irgendwie falsche Umlaute. Man sah dass, da die Punkte etwas zu weit rechts saßen. Einmal umbenennen hat gereicht (ging direkt, Umweg über ae war nicht nötig, z. B. mv Stromzähler-Wohnungsnummer.pdf Stromzähler-Wohnungsnummer.pdf wobei man den ersten Namen komplett kopieren musste oder über Tab vervollständigen lassen, beim zweiten Namen das ä einmal löschen und über die Tastatur neu eintippen).


    Ein Skript dazu gibt es nicht, aber mit find kannst du dir in der Shell alle potentiell betroffenen Dateien anzeigen lassen. Wenn du die Umbenennung automatisieren willst, kannst du an das find mit Pipe einen awk-Aufruf dranhängen, ist aber nicht ganz trivial.


    Wenn nein:


    Man kann beim mount in einer Option den Zeichencode, d. h. das Charset, festlegen.


    Zu deiner zweiten Frage:


    Das ist so. Dir spuckt da die Komfortfunktion vom Finder rein.


    Du kannst aber im Menü rechts oben "Timemaschine öffnen", brichst dann ab, und die mit den richtigen Anmeldedaten geöffnete Freigabe sollte im Finder weiterhin vorhanden sein, und da kannst du dich durchklicken.


    Im Terminal kannst du beim mount-Befehl ebenfalls andere Anmeldedaten angeben.


    Oder du weichst halt von SMB: nach AFP: aus. Für mal eben schnell etwas machen ist das auch in Ordnung.

    Ich hatte auch schon den Fall, dass die Platte kaputt war und das Backup von der lokalen Sicherung nicht mehr einlesbar war, weil HBS2 nicht startete.

    Das Backup lässt sich auch ohne HBS wieder zurückspielen (muss ja möglich sein, es könnte ja auch ein Defekt des NAS vorliegen). Wenn keine Containerdatei genutzt wird (kein QuDedup), dann geht das ganz einfach auf Dateiebene, z. B. mit Shell-Befehlen. Wird die Containerdatei genutzt, dann stellt Qnap für die üblichen Betriebssysteme (Mac, Linux, Windows) Programme bereit, welche die Containerdatei lesen können.

    Wenn es nur darum geht, herauszufinden, welche Dateien in einem Verzeichnis fehlen, aber Größe und Datum egal sind:


    Mit ssh auf dem NAS einloggen, dann

    Code
    cd ordner1
    find . -name "*" >~/tmp.ordner1
    cd ordner2
    find . -name "*" >~/tmp.ordner2
    diff ~/tmp.ordner1 ~/tmp.ordner2
    rm ~/tmp.ordner1
    rm ~/tmp.ordner2


    Das hat im Gegensatz zu duke-f s Vorschlag mit ls -R den Vorteil, dass man beim Ergebnis vom diff direkt sieht, in welchem Unterverzeichnis sich eine Datei, die nur in einem Ordner vorhanden ist, befindet.

    Ich will weder auf QTS 4.5.xxx zurueck, noch auf das BETA QTS 5.2.xxx und eine komplette Formatierung das BackUp-Mediums ist fuer mich auch sinnfrei.

    Bei qts 5.1.7 bleiben, HBS zurück auf 24.0.0304 (bei mir die letzte funktionierende Version) und abwarten. Die Aufforderungen zum Update von HBS kann man so lange einfach ignorieren.


    Der Fehler tritt sicher nicht in jeder Konfiguration und auf jedem System auf, sonst hätte selbst Qnap ihn bei den Tests bemerkt, aber es gibt genug Meldungen, so dass Qnap Interesse daran haben wird, den Fehler zu finden. Da ich einen offiziellen Workaround (der mein Problem allerdings nicht gelöst hat) zugeschickt bekommen habe, weiß ich, dass Qnap an dem Thema dran ist. Neue HBS-Versionen, die erscheinen werden, lohnen einen Versuch, ob der Fehler noch drin ist.


    Mittelfristig wird es eine stabile Version qts 5.2 geben.


    Ein Ticket bei Qnap kann helfen, mehr Druck aufzubauen. Qnap wird allerdings Log-Dateien anfordern, und diese Logdateien enthalten vertrauliche Informationen (wenn diese als Verzeichnis- oder Dateinamen vorkommen, z. B. Kundenname als Verzeichnisname) und ein paar Passwörter im Klartext.

    Bei mir ist es umgekehrt, ich habe ein relativ neues Qnap und ein elf Jahre altes Synology. Das Syno steht an einem anderen Standort und ist mein Backup-NAS.


    Die beiden NAS synchronisieren sich gegenseitig, und einmal mühsam eingerichtet funktioniert das jetzt sehr zuverlässig. Probleme hatte ich in erster Linie, für das Syno ein geeignetes Backupprogramm zu finden - das mitgelieferte Hyper Backup hat sich nicht als geeignet gezeigt. Fündig geworden bin ich dann bei Ultimate Backup - mehr als DSM 6.2 kann mein Syno ohnehin nicht. Bei DSM 7 würde ich mir das im Entstehen begriffene Basic Backup anschauen.


    Ein Qnap und ein Syno als Backup (oder umgekehrt) ist zwar etwas aufwendiger in der Einrichtung als beide Geräte vom gleichen Hersteller, hat aber den Vorteil, dass es sehr unwahrscheinlich ist, dass beide Geräte gleichzeitig von einer Welle einer neuen Schadsoftware betroffen sind.

    Die Verwendung des Verzeichnisses .VersionRecycle ist neu oder hat sich geändert, und an dieser Stelle ist HBS ziemlich bogus. Manchmal scheitert das Backup daran, dass dieses Verzeichnis nicht angelegt wird (da gibt es einen peinlichen Workaround dazu). Bei mir ist das Backup extrem langsam geworden.


    Geh auf HBS Version 24.0.0304 oder älter zurück. Jene Version hat diese Probleme noch nicht. (Aber nimm unter gar keinen Umständen eine der Versionen dazwischen. Da gibt es eine mit einem bösen Fehler, der dir u. U. die zu sichernden Quelldaten löschen kann.)

    Was auch gehen könnte:

    - NAS ausschalten

    - eine Platte des Raid rausnehmen

    - NAS einschalten ⇒ Raid wird als degradiert eingestuft.

    - in der Shell mit mdadm aus dem Raid eine Einzelplatte machen


    Bitte mach dies nicht, ohne ein aktuelles und funktionierendes Backup zu haben.

    Falls ich Dich richtig verstehe, wird die von mir voreingestellte Anzahl der Sicherungen mit diesen K-Sicherungen aufgefüllt ( bzw. diese Sicherungen werden nicht gelöscht ),

    Ja, du hast mich richtig verstanden, diese Sicherungen werden nicht gelöscht ("auffüllen" trifft es nicht ganz)

    Schliesslich habe ich ja die Eingabe „Anzahl der beizubehaltenen Versionen, bevor die obigen Einstellungen angewendet werden“ mit Null festgelegt

    Das ist die Anzahl der letzten Versionen, die in jedem Falle aufgehoben werden, auch wenn sie eigentlich gelöscht werden müssten. Siehe hier.

    Weiters sind die K-Versionen verschwunden, obwohl ich die Anzahl der geplanten Monatssicherungen auf 40 angehoben habe und erst 22 tatsächliche Monatssicherungen vorhanden sind.

    Ich kann es dir nicht sagen. Ich habe HBS nicht programmiert, ich bin auch nur Anwenderin.

    Weiters frage ich mich auch noch, warum in den Jahren 2022 und 2023 die K-Versionen nicht aufgetreten sind,

    Vielleicht ist erst danach eine entsprechende Änderung in HBS vorgenommen worden? Im März gab es eine Änderung zu diesem Kontext.

    Zu den .K-Verzeichnissen:


    Mit deiner Logik "8 Tage / 5 Wochen und 120 Monate" heißt das, dass insgesamt 133 Versionen aufgehoben werden sollen. Da dein NAS noch keine zehn Jahre in Betrieb ist, hast du keine 120 Monatssicherungen. HBS sieht die Zahl von 133 Versionen aber nicht als Maximalwert, sondern als Idealwert an und versucht, so viele Versionen aufzuheben. Wenn das nicht nach dem gewünschten Muster geht - sind halt keine 120 Monate vergangen - dann werden zusätzliche Tages- und Wochenversionen aufgehoben, die eigentlich schon zur Löschung vorgesehen wären. Diese zusätzlichen Versionen erhalten statt D, W oder M ein K. Werden die insgesamt 133 Versionen erreicht, dann werden die K-Versionen automatisch gelöscht.


    Ich habe auch ein paar K-Versionen, aber nicht, weil die Zahl der Monatsversionen noch nicht erreicht wäre, sondern weil ich neulich nach Problemen mit HBS ein paar aktuelle Versionen per Hand gelöscht hatte.


    Die K-Versionen sind also kein Fehler, sondern ein Feature.


    Zum Speicherplatzverbrauch:


    Du benutzt kein QuDedup. Mache ich auch nicht, das hat mir bei der Arbeit schon mal "den Kopf gerettet", als ich Montag früh beim Kunden als allererstes meine VM kaputt gemacht hatte, und mit sftp konnte ich dann die ruinierten Dateien aus dem heimischen Backup wieder herstellen. Der Verzicht auf QuDedup hat aber nicht nur den Nachteil, dass alle Verzeichnisstrukturen für jede Version komplett gespeichert werden, sondern auch, dass nicht erkannt wird, wenn Dateien verschoben werden. Wenn du ein Verzeichnis umbenennst, dann sind alle Dateien dieses Verzeichnisses und der Unterverzeichnisse im Backup doppelt vorhanden und belegen doppelten Speicherplatz.


    Es bringt relativ wenig Speicherplatzgewinn, wenn man ein Backup aus der Mitte löscht, weil die darin befindlichen Dateien meistens ebenfalls im vorangegangenen oder nachfolgenden Backup vorhanden sind und damit weiterhin Plattenplatz belegen. Das Löschen des ältesten Backups bringt mehr, weil dann alte Dateien wirklich rausfallen.


    120 Monate aka. zehn Jahre sind eine verdammt lange Zeit. Wenn du ein Verzeichnis mit 500GByte Daten umbenennst oder verschiebst, dann belegen diese 500GByte zehn Jahre lang den doppelten Speicherplatz, bis endlich die alten Abbilder rausfallen.