Kaputte Mac OS Dateien nach Wiederherstellung aus Snapshot

  • Guten Tag,


    bin neu hier und und suche natürlich gleich Rat. Voraus: Ich bin Mac-Anwender seit 30 Jahren und bin mit einigen Mitarbeitern im grafischen Gewerbe tätig. Computerkenntnisse sind vorhanden, beim Mac tiefergehend, bei Windows auf Anwenderebene und Linux nur oberflächlich.


    Als Dateiserver hab ich schon einiges durch. Von Windows NT vor vielen Jahren (war nicht übel!) über Linux mit Netatalk 2 (hatte damals ein paar Eigenheiten) bis Apples FileServer-Anwendung auf Basis von Mac OS X 10.9, welche an sich für unseren Bedarf eigentlich am rundesten läuft. Leider hakt es hier bei der Erweiterbarkeit der aktuell eingesetzten Mac Minis (Late 2012), externe Laufwerke über teure Thunderbolt-Gehäuse anzuschließen widerstrebt mir, USB 3.0 erscheint mir doch zu unprofessionell und mit der Software-RAID-Implementation hatte ich schon zweimal negativen Erfahrungen (Abstürze bei Wear-Problemen der SSDs statt stabilem Weiterbetrieb mit entsprechender Warnung).


    Auf der Suche nach einer alternativen Dateiserverlösung mit guter Usability bin ich nun bei QNAP gelandet. Eine kurze Recherche brachte mich zum Modell TS-431X2 8GB, welche mir mit der ARM-CPU zwar mäßig potent, aber für einen reinen Dateiserver auch ausreichend ausgestattet erscheint. Auch gefiel mir die 10-GBit-Schnittstelle an den Geräten zum vergleichsweise schmalen Taler, Geld spielt ja auch eine Rolle. Besondere QNAP Applikationen sollen nicht laufen, kein Mail- und Webserver, keine Firewall etc., dafür habe ich eigene Linux-Systeme.


    Also 2 NAS gekauft, 2 SSDs (Samsung 860 Pro 2 TB) als RAID-1 für die "Hauptfreigabe" eingerichtet, eine Festplatte (WD Red 8 TB) als ungesicherte Archiv-Freigabe und eine weitere solche Festplatte als Backup-Ziel für Snapshot Replikation und eine "klassische" Volume-Kopie als "Plan B" mit dem bewährten Carbon Copy Cloner -- jeweils am anderen Server.


    Das Einrichten mit dem aktuellen QTS 4.3.6.0867 klappte problemlos, auch die Anbindung der Mac Clients mit dem von mir bevorzugten AFP funktioniert prima. Auch das Backup per Snapshot und Snapshot Replikation auf den anderen Server eingestellt, wunderbar, soweit gut zu verstehen und handzuhaben.



    Dann der Test, ob das Backup auch tut was es tun soll, alle möglichen Arten von Dateien wiederhergestellt.


    Oje. Viele wiederhergestellte Mac-Dateien sind nach der Wiederherstellung kaputt.


    Kaputt aus zweierlei Gründen:


    1. Weil die speziellen Möglichkeiten der Apple-Dateisysteme in Linux-Dateisystemen und einfachen Windows-Dateisystemen nicht einfach gespeichert werden können (mehrfache Datenströme, "Data Fork" und "Resource Fork") werden diese als "Apple Double" gesichert: Die Data Fork landet in einer Datei mit dem ursprünglichen Namen, die Resource Fork in einer mit "._" dem Namen vorangestellt. Der Netatalk-Dämon setzt das dann wieder zusammen, um dem Mac per AFP (oder auch per SMB) dies passend anzubieten (FTP und NFS können das meines Wissens nicht).


    Wenn man diese beiden zusammengehörigen Dateien bei der Wiederherstellung anwählt, dann sind die Daten grundsätzlich wieder da, auch bei alten PostScript Schriften und anderen Dateien, die die mächtigen Möglichkeiten des (etwas angestaubten) Resourcen-Konzepts nutzen.


    2. Allerdings kann man diese Dateien trotzdem nicht mehr öffnen. Weil nämlich die Dateiattribute "File Type" und "Creator" fehlen (inzwischen heißen diese Infos anders, aber egal). Diese sind für die Zuordnung von Dateiinhalt zu kompatibler Anwendung (welche Dateien ein Programm verarbeiten kann) und zur erzeugenden Anwendung (Öffnen des richtigen Programms bei Doppelklick auf das Dokument) nötig. Und genau die werden nicht wiederhergestellt! Typisches Symptom sind die "leeren" Dokumentensymbole statt Anzeige des richtigen Piktogramms.


    Siehe Anhang!



    Dieser Mangel fällt u.U. nicht auf, wenn man nur aktuelle Software und Schriften verwendet (diese meiden das Resourcen-Konzept) und alle Dateien mit Dateiendungen versieht. Das Besondere am Macintosh ist jedoch, dass das auch ohne diesen "Windows-Mist" funktioniert, eigentlich sogar viel besser (weil zB verschiedene Programme eine bestimmte Art von Dateien erzeugen können (zB TIFF) und trotzdem jede einzelne Datei bei Doppelklick genau mit dem Programm geöffnet wird, von dem es auch erzeugt wurde).


    Weil wir auch gezwungen sind mit beigestellten Daten zu arbeiten und auch immer wieder "historische Projekte" überarbeiten stellt sich diese Frage der 100%-igen Kompatibilität unausweichlich.


    Man könnte diese Attribute manuell wiederherstellen, aber nicht bei einem Restore von 40.000+ Dateien.



    (Übrigens passiert genau dasselbe, wenn man in der File Station Dateien kopiert. Es wird nur die Data Fork kopiert (die "._"-Dateien sieht man gar nicht) und die File-Attribute gehen ebenso verloren. Klar, ein Linux weiß mit diesen Dingen eben nichts anzufangen.)


    Ich finde es geradezu gefährlich, eine Server-Lösung anzubieten und die Mac-Kompatibilität herauszustreichen, welche beim absolut kritischen Thema Datensicherung ziemlich versagt!

    Nicht jeder Anwender wird diese Tests durchführen und könnte da im Fall des Falles schnell vor unlösbaren Problemen stehen!



    Daher stelle ich meine Frage an die Mac-User hier, wie sie mit diesem Thema umgehen. Habe ich etwas übersehen? Gibt es spezielle QNAP-Apps für das Mac OS-Dateihandling und fürs Backup?


    Ich werde vermutlich gezwungen sein eine Backuplösung aufzubauen, welche von einem Mac aus über das AFP-Netzwerk die Datensicherung vornimmt. Das ist leider langsam wie unnötig komplex und lässt viele potente Angebote des QNAP-Systems (Snapshot-Konzept, Snapshot Replika) brach liegen. Andererseits gefällt mir das QNAP Konzept gut und die Performance ist sehr zufriedenstellend. "Weiterwursteln" auf dem Mac Mini / Apple Server-Konzept mag ich auch nicht.


    Zu der Angelegenheit habe ich auch bei QNAP eine Anfrage laufen, aber da herrscht seit Tagen verdächtige Stille.



    Eine weitere Schwäche ist übrigend sie Suchfunktion. Spotlight funktioniert nur mit einem passenden Index, den auch Qsirch trotz so klingender Bewerbung offenbar nicht aufbaut. Spotlight wechselt in einen "Primitivmodus", wo es rekursiv den ganzen Verzeichnisbaum abklappert und nach den gesuchten Dateinamen sucht -- das dauert ewig, bei 40.000+ Dateien reden wir über einige Minuten. Dabei bietet AFP schon immer die genau passende Schnellsuche, welche zum Glück von findigen Programmierern wiederentdeckt und mit den Programmen "Find Any File" und "Esasy Find" wieder nutzbar wurden. So geht suchen zwar noch immer um ein ganzes Eck langsamer als auf einem Mac OS Fileserver (hier wenige Sekunden), aber immerhin sind knapp 30 Sekunden schneller als einige Minuten. Für Leute die nicht nach Inhalt sondern nur nach Dateinamen suchen ein praktikabler Lösungsansatz.

  • Hui da hast du ja ganz schön viel geschrieben.


    Ich versuch noch mal kurz den Kern deines Anliegens zusammen zu fassen. Du suchst eine Backuplösung für deine Macs und hast versucht das über die Replikation von Snapshots umzusetzten.


    Vorab noch ich habe mit Mac OS bisher so gut wie nichts am Hut, aber ich hoffe dich dennoch auf den richtigen Pfad führen zu können.


    Und zwar ist es wohl so, dass die Snapshots die man mit QNAP anfertigen kann nicht wirklich als Backup Lösung gedacht waren. Sondern eher als kurzfristige Möglichkeit Daten wieder herzustellen.


    Ich hatte diesbezüglich vor kurzem noch die gleiche Annahme getroffen wie du. QNAP suggeriert hier leider etwas anderes.


    Für Mac User gibt es aber im Sicherungsmanager die Timemachine, die sollte für dein Anliegen besser geeignet sein.

  • Also ich verwende TimeMachine um da System meiner Macs auf meine QNAP zu sichern. Damit ist ein kompletter, bootfähiger Restore möglich. Zusätzlich sichere in bestimmte Dateien zeitgesteuert mittels Carbon Copy Cloner ebenfalls auf die QNAP. Als Ziel verwende ich da aber nicht direkt einen NFS-Mount sondern ein Disk Image welches auf dem QNAP Share liegt.


    Sofern man ein Disk Image (z. Bsp. mitwachsendes Bundle mit AFPS Dateisystem) auf der QNAP einsetzt, so werden alle Features der Mac OS Dateisysteme unterstützt, also Forks, Ressourcen, usw.


    Man verliert allerdings etwas Geschwindigkeit und CCC kann nicht direkt von dem Image ein System wiederherstellen - deshalb Time Machine.


    Zum Suchen: wenn auf der QNAP QSirch installiert ist, so wird ein Spotlight Index auf der QNAP erstellt. Sobald eine Dateifreigabe, welche von QSirch indiziert ist, am Mac gemounted wird, kann man über den Finder Dateien auf der QNAP finden. Als gute Alternative vor QSirch hat sich bei mir auch Houdahspot erwiesen.

  • Danke für die Antworten! :)


    Leider gehen sie an meinem Anliegen vorbei: Ich will nicht meinen Mac sichern (zB mit TimeMachine), ich will meine Arbeitsdaten, die alle am NAS liegen, sichern. Wir sind 8 Mitarbeiter, die alle am Server direkt arbeiten (Adobe Creative Suite CS6, InDesign, PhotoShop, LightRoom 6 usw.). Damit man von jedem Arbeitsplatz aus auf die Daten zugreifen kann, dafür gibt es Datei-Server.


    TimeMachine kann nur lokale Datenträger sichern (auch aufs NAS), aber keine gemounteten Netzwerkvolumes. Und QNAPs Lösung kann lokal alles sichern, aber Mac-Dateien, die am NAS gespeichert sind, offenbar nur unvollständig wiederherstellen. Die Dateien sind nachher aus Mac-Client-Sicht nimmer so wie vorher. Das Problem sind die Extended File Attributes ("com.apple.FinderInfo" seit Mac OS X), das Zeug wird offenbar nicht gesichert bzw. wiederhergestellt.


    Das ist das zu grundssätzlich zu lösende Problem.


    Eine Sicherung von Server zu Server mit rsync o.ä. wäre auch schneller als eine Sicherung durch einen Netzwerkclient, der die Daten des Servers A auf den den Server B überträgt (doppelter Traffic).


    Weil außer Netatalk offenbar kein QTS-Programm weiß wie mit Mac-Dateien korrekt umzugehen ist wird wohl nur der Zugriff über AFP verlässlich funktionieren.




    (Hmmm, Qsirch funktioniert bei mir wirklich nicht mit Spotlight. Laut iNet-Recherche nicht nur bei mir nicht ... mit und ohne dieser Q-App sucht Spotlight rekursiv alle Verzeichnisse elend langsam ab. Vergleicht mal zu einem Apple Server, da geht das genauso flink wie lokal. )

  • Ich will nicht meinen Mac sichern (zB mit TimeMachine), ich will meine Arbeitsdaten, die alle am NAS liegen, sichern.

    Dann nimm nicht die Snapshots, sondern mach ein "echtes" Backup der ganzen Ordnerstruktur mit allen Files die drinnen sind. Das geht z. B. mit RTRR von einem NAS zum anderem.

  • Naja, mit RSYNC bzw. RTRR bekomme ich bei APFS bzw. HFS+ auch Probleme beim Restore von Dateien mit Ressourceforks. Wie oben geschrieben, war meine Lösung - Sicherung mittels CCC auf ein Image, welches auf einem QNAP-Share liegt. Damit kann ich alle Features des Dateisystems sichern & wiederherstellen. Und mit CCC mach er auch einen automatischen Mount des Shares oder weckt den Mac zur Sicherung auf...


    Spotlight & QSirch schaue ich mir heute abend noch mal an und poste mein Ergebnis (ich brauch das nicht so häufig).

  • Danke. Mit CCC oder Retrospect wird das alles zu lösen sein.


    Allerdings bietet ersteres keine "Timeline" wie die Snapshots bzw. TimeMachine und zweiteres ist mir vom Userinterface her nicht so wahnsinnig sympathisch.


    So wichtig ein "echtes" Backup ist, 99% der Alltagsanwendungen sind die Behebung von einfachen User-Fehlern wie die Wiederherstellung überspeicherter oder versehentlich gelöschter Dokumente.

  • Das Wiederherstellen geht mit CCC mittlerweile echt gut, optional wird ein Ordner "SafetyNet" angelegt, in denen Unterordner je Timestamp geänderte und gelöschte Dateien zum Zeitpunkt enthalten.


    Zu Spotlight: ich habe QSirch aktiviert. Sobald ich ein Shared Folder mounte wird ein Spotlight Index für den Ordner aktiviert (im Beispiel "Sicherung"):


    Code
    1. mdutil -sav
    2. /:
    3. Indexing enabled. 
    4. Scan base time: 2019-02-09 20:15:06 +0000 (2238195 seconds ago), reasoning: '(null)'
    5. /Volumes/Sicherung:
    6. Server search enabled.

    Wenn ich nun eine Spotlight-Suche starte kommt das Ergebnis sofort und zieht auch Inhalte mit ein, zum Beispiel:

    Code
    1. mdfind -onlyin /Volumes/Sicherung/ Cabrio
    2. /Volumes/Sicherung/Archiv/Zwischenablage/Cabrio_Preisliste.pdf
    3. /Volumes/Sicherung/Archiv/Zwischenablage/CA_pricelist.pdf
    4. /Volumes/Sicherung/Archiv/Email/Mailarchiv/t-online_inbox_archiv.MBOX
  • mdutil sagt mir "Indexing disabled." bei diesem QNAP Servervolume. Ich hab einfach Qsirch installiert (vorher die ARM JRE).


    Muss ich da noch etwas konfigurieren? Hätte nichts gefunden. Nach der Installation hat das Zeug stundenlang indexiert.

  • Qsirch muss installiert werden und der Index muss erstellt sein - also keine besondere Konfiguration, du musst QSirch mindestens einmal aufrufen und die Ersteinrichtung machen.


    Spotlight Server search wird ab QTS 4.3.5.0699 build 20180914 Public Beta 3 unterstützt, das heisst es sollte bei Dir eigentlich laufen:


    Mod: Undeklariertes Zitat ohne Quellenangabe entfernt!

  • Danke für deine Unterstützung!


    Das ist ja spannend. Ich werde Qsirch mal deinstallieren und neu laden. Vielleicht ist dann ja etwas anders.

  • Nach ich bei QNAP eine Supportanfrage gestellt habe und die nötigen Dinge nachgereicht habe wurde mir mitgeteilt, dass sich die Entwicklungsbteilung das ansieht.

  • Habe nun Qsirch deinstalliert und neu installiert. Die Indizierung lief wieder stundenlang -- mdutil meint auf meinen Macs noch immer "Indexing disabled."


    Was kann da sein?


    Ich mounte die Serverfreigabe per AFP in der Form "AFP://10.5.0.10", logge mit einem angelegten Benutzernamen und Kennwort ein -- was kann man da groß falsch machen? Getestet auf MacOS 10.13.6 und 10.9.6

  • Ah, guter Hinweis. Bitte versuche das mal mit SMB. Wobei ich immer nur auf das NAS-Symbol im Finder klicke (es gibt bei mir nur eins da ich AFP auf der NAS deaktiviert habe).


    AFP wird von Apple ja nicht mehr weiterentwickelt und durch SMB2 ersetzt.

  • Erstaunlich: mdutil sagt bei einer SMB-Verbindung "Server search enabled." und das Suchfenster bleibt leer. Egal ob allgemeine Suche (oben), selbst definierte Suche ("Name enthält ..."), egal ob bestimmtes Volume oder "Netzwerk" angewählt.


    Die Suchprogramme "Find Any File" suchen und finden, aber im "Langsam"-Modus, also rekursiv-sequentiell. Mit AFP-Verbindung laufen diese wenigstens einigermaßen schnell.


    Das ist alles Müll. :/

  • Mal kurz zum Verständnis....defekte Dateien nach Snapshot-Restore. Ich bin gerade hingegangen:

    1. via AFP Pages und RTF Dokument vom Mac via AFP aufs NAS gespeichert

    2. manuellen Snapshot erstellt

    3. selbigen auf einem anderen Volume wiederhergestellt

    4. Dateien via AFP problemlos zu öffnen.

    Übersehe ich was?

  • Austro-Diesel Die Mac Metadaten werden von afp möglicherweise in „Extended Attributes“ des Filesystems gespeichert, siehe New AppleDouble backend.

    Snapshots sollten Extended Attributes zwar erhalten, aber vielleicht gehen sie bei der Snaphot Replication auf einen anderen Host verloren?

  • Nach über einem Monat kommt schon fast eine unerwartete Nachricht vom QNAP Helpdesk ... "die Entwicklungsabteilung kann das nicht nachvollziehen", ich solle doch Dateien von vor der Wiederherstellung und nach derselben übermitteln sowie eine Beschreibung meiner Abläufe. -- Natürlich prompt erledigt ... ich warte.


    @ Ezekiel666: Der Schaden ist nur zu bemerken, wenn in den Dateilen "Extended Attributes" verwendet werden und/oder die Dateien keine Dateiendung aufweisen.


    Also a) "klassische" Mac OS-Dateien wie anno dazumal mit Mac OS 9, beispielsweise die alten LaserWriter-PostScript-Fonts etc. Diese Dateien sind nach der Wiederherstellung auf Null Bytes geschrumpft.


    Oder b) zB Bilddateien aus PhotoShop ohne Dateiendungen. Nach dem Restore weiß Mac OS nicht mehr, was das ist und womit zu öffnen. Schreibt man dann ".tif" oder ".jpg" dran, dann gehen entsprechende Dateien wieder zu öffnen.


    @ mjb: Das ist ein denkbarer Erklärungsansatz. Dass die RRTR und rsync-Mechanismen das nicht mitübernehmen. Allerdings klappt es auch schon nicht in der FileStation Dateien mit Extended Attributes zu kompieren, die sind auch beschädigt. Der Kopierprozess also offenbar dasselbe Problem.

  • Ich habe gerade eine neue TurboStation eingerichtet und dabei meine Dateien via RRTR von der alten auf die neue TurboStation übertragen. Dazu habe ich im Hybrid Backup Sync einen One-Way Sync Job auf die Remote NAS eingerichtet. Bei den Advanced Settings waren die folgende Optionen bei Policy aktiviert:

    1. Filter system-generated Temp-Files
    2. Replicate ACL and extended Attributes
    3. Do not take a snapshot

    Alles andere war Standard. Snapshot geht leider nicht mangels Platz :-)


    Auf der neuen NAS waren nach dem der Job durchgelaufen war zumindest alle MACOS-Tags und Datei-Attribute wieder vorhanden. Auch das gesicherte TimeMachine wurde erfolgreich überprüft und funktioniert.


    Das Dateien auf 0 gesetzt wurden kann ich nicht nachvollziehen.


    Das alles mit Hybrid Backup Sync Version 2.1.190329.


    P.S. Programmassoziationen ohne File-Extensions wurden auch erfolgreich mit übertragen.

    Einmal editiert, zuletzt von Variag ()