maccoX
Aktives Mitglied
- Dabei seit
- 15.02.2005
- Beiträge
- 16.053
- Reaktionspunkte
- 6.063
Besser kann man es nicht sagen, dem stimme ich 100% zu.
Folgen Sie dem Video unten, um zu sehen, wie Sie unsere Website als Icon auf Ihrem Homescreen erstellen.
Anmerkung: This feature may not be available in some browsers.
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.
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?
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!
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.
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...
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.
Es gibt keine Grafikdateien, die Grafik wird generiert.
...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...
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.
Oh, cool. Das war mir noch gar nicht aufgefallen. Muss ich mir mal anschauen.Parallels hat eine menge Gehirnschmalz in SmartGuard investiert um das Problem zu mindern: https://kb.parallels.com/115052
Oh, cool. Das war mir noch gar nicht aufgefallen. Muss ich mir mal anschauen.
Wie?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.
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.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.
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.