macOS Mojave Unnötige Sicherung unter Time Machine???

Besser kann man es nicht sagen, dem stimme ich 100% zu.
 
  • Gefällt mir
Reaktionen: iPille und dg2rbf
Kleiner Test:
einen beliebigen Film, *.mp4, heute angespielt und danach Time Machine geöffnet und diese Datei markiert.
Datum bei "zuletzt geöffnet" aktuelles Datum von Heute
in der Time Machine zurück geblättert, Pfeil-Schaltfläche nach Oben, die letzte Sicherung der Datei hat als Datum bei zuletzt geöffnet ein Datum aus 2018

Also bei mir ändert sich das "zuletzt geöffnet"-Datum nachdem ich den Film heute abgespielt habe. Demnach sollte die Datei gesichert werden, da sich ja etwas geändert hat. Vorher hatte der Film als "zuletzt geöffnet" ein Datum aus 2018. Bis hier her alles logisch, oder? Was soll denn nun gesichert werden? Der aktuelle Datenstand, oder? Der ist nun einmal "zuletzt geändert" = "Heute" und nicht "irgendwann 2018"
Wo ist der Fehler?
 
  • Gefällt mir
Reaktionen: mausfang und iPille
Was heutzutage getrieben wird kann man nicht mehr mit ansehen.

Wollt ihr mal sehen was man in 96kb (also kb, nicht GB und auch nicht MB, sondern wirklich extrem mickrige kb) - so packen kann?

Dieses ganze Spiel!
 
  • Gefällt mir
Reaktionen: electricdawn und iPille
Time Machine kann doch nichts dafür...

Fakt ist: Das passiert ja nicht von alleine. Es wurde was geändert und diese Änderung muss weggesichert werden.
Dass im Zweifel ein paar gigabyte zuviel gesichert werden ist in meinen Augen besser als würde etwas fehlen.

In anderen Bereichen ist das Problem akzeptiert.
Bei Virtuellen Maschinen sagt jeder, dass man die vom Backup ausschließen muss.
Parallels hat eine menge Gehirnschmalz in SmartGuard investiert um das Problem zu mindern: https://kb.parallels.com/115052

Das Problem tritt ja eigentlich nur bei riesigen (Film-)Dateien wirklich als "Problem" in Erscheinung.

Wer das nicht will kann:
- Die Dateien aus dem Backup ausschließen.
- Eine andere Backup Strategie Wählen.
- Schauen, ob er MacOS dazu bringen kann, beim öffnen einer Datei so zu tun als hätte es die Datei nicht geöffnet.
- Schauen, ob man die Dateien in einem Dateisystem speichern kann, dass Metadaten nicht speichert. (ob es das noch gibt?)
- Das Problem mindern indem man auf kleinere Dateien bzw. einen aktuelleren Codec wie HEVC mit besserer Kompression setzt.
 
  • Gefällt mir
Reaktionen: iPille
Time Machine kann doch nichts dafür...

Fakt ist: Das passiert ja nicht von alleine. Es wurde was geändert und diese Änderung muss weggesichert werden.
Dass im Zweifel ein paar gigabyte zuviel gesichert werden ist in meinen Augen besser als würde etwas fehlen.

In anderen Bereichen ist das Problem akzeptiert.

...sorry, aber das ist doch Unsinn. Mit rsync als *dem* Backuptool im Unixbereich werden seit Jahrzehnten komplette Serverinstallationen skriptbasiert kopiert und gebackupt *ohne* daß dort jede Datei mitgesichert wird, die mal zum lesen geöffnet wurde - auch wenn sich dort die Metadaten geändert haben. rsync kommt trotz endlos vieler Konfigurationsoptionen von Hause aus wunderbar mit Metadaten klar ohne daß auf Access-Timestamps groß Rücksicht genommen werden muß - schlicht weil das im Backup keine Sau interessiert. Ganze Backupkonzepte wären für die Tonne, wenn jede Datei die nur mal lesend geöffnet wurde nach jedem Zugriff neu gebackuppt werden müsste. Bei ZFS (ein COW-System wie Apples APFS) kann z.B. schon auf Dateisystemebene eingestellt werden, daß Lesezugriff-Timestamps eben nicht in den Metadaten aktualisiert werden, um das dauernde Rausschreiben von neuen Metadaten-Blöcken zu reduzieren.

Ich *vermute*, das Verhalten von TM lässt sich mit Apples Filesystem APFS in diesem Bereich erklären. An den Timestamps selbst kann es eigentlich nicht liegen, denn TM war m.W. ursprünglich rsync-basiert und damit gab es ja jahrelang keine Auffälligkeiten...
 
  • Gefällt mir
Reaktionen: mj, erikvomland, dg2rbf und eine weitere Person
Was soll denn nun gesichert werden? Der aktuelle Datenstand, oder? Der ist nun einmal "zuletzt geändert" = "Heute" und nicht "irgendwann 2018"
Wo ist der Fehler?

Definiere Datenbestand!

Daten sind alles oder nur die "echten" Daten? Zählen Metadaten zu "echten" Daten oder zum Wasserkopf?
 
Was heutzutage getrieben wird kann man nicht mehr mit ansehen.

Wollt ihr mal sehen was man in 96kb (also kb, nicht GB und auch nicht MB, sondern wirklich extrem mickrige kb) - so packen kann?

Dieses ganze Spiel!


Die Grafikdaten auch???
 
Es gibt keine Grafikdateien, die Grafik wird generiert.

Ich finde das zeigt deutlich was alles möglich sein kann. Aber das interessiert heutzutage halt Niemanden mehr. Klar ist das Arbeit das in dieser Perfektion zu betreiben und nicht generell möglich da zu teuer aber man sollte halt zumindest ein bisschen darauf achten ressourcenschonend zu programmieren.

Und das TM Thema hier zeigt eben das genaue Gegenteil, den Worst Case.
 
  • Gefällt mir
Reaktionen: dg2rbf und iPille
Time Machine kann doch nichts dafür...

Fakt ist: Das passiert ja nicht von alleine. Es wurde was geändert und diese Änderung muss weggesichert werden.
Dass im Zweifel ein paar gigabyte zuviel gesichert werden ist in meinen Augen besser als würde etwas fehlen.

OK, das kann man machen, muss man aber nicht.

Diese Erklärung ist doch aus der Rubrik "Ich fahre immer mit dem Tieflader zum Zigarettenholen". Funktioniert, aber smart und kostengünstig ist was anderes.
 
  • Gefällt mir
Reaktionen: dg2rbf
Ich *vermute*, das Verhalten von TM lässt sich mit Apples Filesystem APFS in diesem Bereich erklären. An den Timestamps selbst kann es eigentlich nicht liegen, denn TM war m.W. ursprünglich rsync-basiert und damit gab es ja jahrelang keine Auffälligkeiten...

Ich denke Apple Muss Time Machine eh nochmal massiv überarbeiten um mit APFS richtig kompatibel zu werden.
aber im verlinkten Artikel ist gleich im Ausgangsposting von HFS+ und Yosemite die Rede. Das Problem existiert also schon länger.

Diese Erklärung ist doch aus der Rubrik "Ich fahre immer mit dem Tieflader zum Zigarettenholen". Funktioniert, aber smart und kostengünstig ist was anderes.

Für einen eingefleischten Raucher zählt nur ob zigaretten da sind oder nicht...
Aber ja, du hast wie alle anderen hier natürlich ebenfalls recht. Schick ist das bei weitem nicht.
 
  • Gefällt mir
Reaktionen: dg2rbf und iPille
...sorry, aber das ist doch Unsinn. Mit rsync als *dem* Backuptool im Unixbereich werden seit Jahrzehnten komplette Serverinstallationen skriptbasiert kopiert und gebackupt *ohne* daß dort jede Datei mitgesichert wird, die mal zum lesen geöffnet wurde - auch wenn sich dort die Metadaten geändert haben. rsync kommt trotz endlos vieler Konfigurationsoptionen von Hause aus wunderbar mit Metadaten klar ohne daß auf Access-Timestamps groß Rücksicht genommen werden muß - schlicht weil das im Backup keine Sau interessiert. Ganze Backupkonzepte wären für die Tonne, wenn jede Datei die nur mal lesend geöffnet wurde nach jedem Zugriff neu gebackuppt werden müsste. Bei ZFS (ein COW-System wie Apples APFS) kann z.B. schon auf Dateisystemebene eingestellt werden, daß Lesezugriff-Timestamps eben nicht in den Metadaten aktualisiert werden, um das dauernde Rausschreiben von neuen Metadaten-Blöcken zu reduzieren.

Ich *vermute*, das Verhalten von TM lässt sich mit Apples Filesystem APFS in diesem Bereich erklären. An den Timestamps selbst kann es eigentlich nicht liegen, denn TM war m.W. ursprünglich rsync-basiert und damit gab es ja jahrelang keine Auffälligkeiten...

Sooooo hatte ich mir eine passende Klarstellung vorgestellt, allein mir selbst fehlt der techn. Backround für so eine Erklärung.


DANKE!

Ich glaube auch nicht, dass dies zuviel verlangt ist! So was muss eine Firma wie APPLE einfach drauf haben und ich hoffe das auch. Vielleicht stellt sich auch heraus, dass uns nur was vorgespielt wird, derweil macht TM im Hintergrund alles "richtig". Könnte gut sein, aber ich kann das leider nicht feststellen, ob wirklich gesichert wird (in voller Größe) oder ob mir TM das nur vorgaukelt und nur die Metadaten sichert. Manchmal ist das ja ganz witzig und fördert das "Verständnis" beim DAU. Bei TM ist das zB diese nette Animation mit der Zeitreise. Die findet natürlich nicht statt, aber jeder erkennt sogleich, was gemeint ist...

Wenn ich während des Backups die Systemeinstellungen von TM öffne und hinterher das Backup mit BackupLoupe prüfe, wird immer die volle Größe angezeigt. Und entsprechend lange gedauert hat es auch.


Daher bin ich davon ausgegangen, dass die Datei jedesmal frisch und zusätzlich gesichert wurde.
 
Für einen eingefleischten Raucher zählt nur ob Zigaretten da sind oder nicht...
Aber ja, du hast wie alle anderen hier natürlich ebenfalls recht. Schick ist das bei weitem nicht.

Ja wenn das so ist....dem kann ich selbst als Nichtraucher zustimmen :unterschreibe:
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dg2rbf
Oh, cool. Das war mir noch gar nicht aufgefallen. Muss ich mir mal anschauen.

Das ist natürlich prima, wenn sich jemand darum kümmert, die Apfellücken zu füllen, aber das kann doch nicht der Anspruch einer Weltfirma sein...

Oder haben die mit einem Male wieder ein großes Herz für Drittanbieter???
 
Das ist natürlich prima, wenn sich jemand darum kümmert, die Apfellücken zu füllen, aber das kann doch nicht der Anspruch einer Weltfirma sein...

Oder haben die mit einem Male wieder ein großes Herz für Drittanbieter???
Wie?

Ist doch logisch, dass eine VM (die riesig ist und sich ständig ändert) ein Problem ist für das TM-Konzept. Das liegt doch nicht an Apple.

Man braucht TM jetzt auch nicht unnötig schlecht machen.

Das Problem, dass geänderte VMs inkrementell zu sichern schwierig ist, kann doch gerne bei den Herstellern von Virtualisierungssoftware zu Programm-Verbesserungen führen.
 
Wie?

Ist doch logisch, dass eine VM (die riesig ist und sich ständig ändert) ein Problem ist für das TM-Konzept. Das liegt doch nicht an Apple.

Man braucht TM jetzt auch nicht unnötig schlecht machen.

Das Problem, dass geänderte VMs inkrementell zu sichern schwierig ist, kann doch gerne bei den Herstellern von Virtualisierungssoftware zu Programm-Verbesserungen führen.


Das verstehe ich jetzt nicht ganz: Ist das eine Software, die TM von APPLE verbessern will (und der Hersteller produziert auch eine VM) oder kümmert die sich nur um die Daten, die im Rahmen der Virtualisierung anfallen?
 
Natürlich ist es in der aktuellen Umsetzung ärgerlich und man müsste die metadaten am besten irgendwie von der Datei trennen.
was ist das bitte für eine diskussion?! du kannst ja die metadaten nicht von den dateien trennen, ohne die sicherungszeiten ins unerträgliche zu erhöhen. jede normalfunktionierende backup.app nutzt metadaten, um veränderungen schnell zu erfassen und jeweils weitere nötige prüfungen anzugehen.

bzgl. TM scheint hier halt ein fehler vorzuliegen, der nicht leicht nachzuvollziehen ist.
 
  • Gefällt mir
Reaktionen: dg2rbf
was ist das bitte für eine diskussion?! du kannst ja die metadaten nicht von den dateien trennen, ohne die sicherungszeiten ins unerträgliche zu erhöhen. jede normalfunktionierende backup.app nutzt metadaten, um veränderungen schnell zu erfassen und jeweils weitere nötige prüfungen anzugehen.

So stelle ich mir das auch vor. Die Backup-Software schaut, ob sich was geändert hat - geht scheinbar über die Metadaten am besten - und prüft dann, was zu sichern ist: Nur die Metadaten oder die ges. Daten. Vormals wurden jedenfalls nicht wegen jeder Kleinigkeit die ganzen Dateien gesichert.

bzgl. TM scheint hier halt ein fehler vorzuliegen, der nicht leicht nachzuvollziehen ist.

Ja, das kann ich mir vorstellen. Daher ja auch meine frage hier ins Forum.
 
was ist das bitte für eine diskussion?! du kannst ja die metadaten nicht von den dateien trennen, ohne die sicherungszeiten ins unerträgliche zu erhöhen. jede normalfunktionierende backup.app nutzt metadaten, um veränderungen schnell zu erfassen und jeweils weitere nötige prüfungen anzugehen.

bzgl. TM scheint hier halt ein fehler vorzuliegen, der nicht leicht nachzuvollziehen ist.

Japp - "Trennen" in Sofern, das TM das selber erkennen müsste, dass nur die Metadaten angefasst wurden.
Ich bin ja Grundsätzlich bei euch...
 
  • Gefällt mir
Reaktionen: iPille und dg2rbf
Zurück
Oben Unten