Re: Klonen vs. Backup

Clemens Beier schrieb in <news:1hznepv.o4ugej1k2jkdxN%spamfalle@xxxxxxxxxxx>
Thomas Kaiser <Thomas.Kaiser@xxxxxxxxxxxxx> wrote:

[<http://www.macgeekery.com/tips/automation/time_machine_for_tiger>]

Der Artikel ist halt leider nur in doppeltem Sinn Themaverfehlung:

1) Die elementaren Komponenten von "Time Machine" werden negiert:

* problemlose Benutzbarkeit durch den definitionsgemäßen DAU

Naja. Dann kann(!) man entgegenhalten, dass der Artikel auf einer Seite
namens mac*geekery* erschienen ist.

Hmm... auch "Geeks", "Nerds" und sonstige sollten versuchen, Dinge in
ihrer Gesamtheit zu begreifen. Und "Time Machine" ist eben nicht nur
irgendein inkrementelles Sync-Dingens sondern hat zwei wesentliche
Komponenten mehr.

* Abstraktion der Datensicherung von starrem Dateisystem-basierten
Modell (wenn denn die Anwendungsentwickler, allen voran die bei
Apple selbst, das Angebot seitens "Time Machine" annehmen)

Da kann ich mir nur ansatzweise etwas darunter vorstellen.

Also konkret -- erstmal den Werbetrailer angucken:

<http://tinyurl.com/2b42eh> (Original-URL: <http://images.apple.com/movies/euro/euro/macosx/leopard/movies/apple-time_machine_672x416.mov>)

In der Macgeekerei (bzw. jedem x-beliebigen geskriptet rsync-Kram) wird
nur Wert darauf gelegt, daß *Dateien* von A nach B geschoben werden. Es
findet keinerlei qualitative Unterscheidung der Dateien statt. Datei ist
Datei und was damit anzustellen ist, ist Sache des Nutzers.

Das, was Apple als "Time Machine API" bezeichnet, erlaubt eine
Abstraktion davon. Nehmen wir als Beispiel das Adreßbuch: Die dortigen
Kontakte landen einerseits in der SyncServices-Datenbank und seit 10.4
auch noch zusätzlich als Proxy-Dateien im Dateisystem (XML-kodierter
Kram, der eigentlich nur die Funktionalität hat, daß das dateibasierte
Spotlight irgendwas anfassen kann, weil es eben nur dateibasiert
arbeiten kann).

Wenn ich Dich in mein Adreßbuch aufnehmen würde, entsteht ein Eintrag in
irgendeiner Datenbank und parallel eine XML-Datei unterhalb

~/Library/Caches/com.apple.AddressBook/MetaData/

Wenn ich Dich dann wieder aus dem Adreßbuch lösche, verschwindet beides.
Bei einem rein dateibasierten Backup- oder Sync-Ansatz müsste ich jetzt

1) wissen, wo der Rotz seitens Address Book.app überhaupt abgelegt wird.

2.a) wenn zwischenzeitlich 10 Kontakte gelöscht wurden, ebenfalls
wissen, daß Du E80CF5C6-CB1D-4B41-A67A-923DCB8D8A11:ABPerson.abcdp
und nicht F067BCB8-B089-4F1D-95F4-ACBEB08691BC:ABPerson.abcdp warst
(bzw. Deine Daten in eben jenen Dateien mit den hübsch kryptischen
Namen gesteckt haben)

oder alternativ

2.b) sämtliche jemals unterhalb des .../com.apple.AddressBook/MetaData/
Pfades abgelegten Dateien einzeln durchforsten, mich dabei mit den
Interna des jeweils verwendeten Dateiformats auseinandersetzen (bei
Apple im Regelfall das bekannte Property List Format) und die mich
interessierenden Informationen herauspuhlen, um überhaupt das zu
finden, was mich eigentlich interessiert.

Mit "Time Machine" bzw. den APIs wird das insofern simpler, als
Anwendungen "Time Machine" nutzen können, um einen Zugriff auf ihre
eigenen Dateiformate insofern komfortabel zu gestalten, als die
Anwendung selbst "Time Machine" den Schlüssel zum Verständnis der
Dateien gibt.

Ich muß also weder wissen, wo Address Book.app irgendwas speichert, noch
in welchem Format, sondern es reicht, wenn ich einfach nach "Clemens"
suche und "Time Machine" aktiviere. Die Schnittstelle zwischen Adreßbuch
und "Time Machine" sorgt dafür, daß die Informationen, die in den vorher
gesicherten Dateien lagen, auch _sinnvoll_ zur Verfügung stehen, d.h.
man innerhalb den logischen Datenstrukturen nach alten Versionen suchen
kann und nicht einfach verloren im Dateisystem hinter Dateien herrennen
muß, deren internes Format einem noch dazu völlig unklar ist.

Dito bspw. bei Anwendungen, die Dateien ihrerseits in einer Art Pool vor
dem Benutzer vervorgen ablegen (iPhoto ist da so ein Beispiel, das alle
importierten Bilder doch irgendwo in irgendwelche Datenstrukturen
stopft, aus denen sie kein normal denkender Mensch mehr ohne Probleme
herausziehen kann). Hier sorgt abermals die Schnittstelle zwischen
Anwendung und "Time Machine" dafür, daß man nach Bild-Metadaten suchen
kann (hier dürften dann mal wieder die Spotlight-Metadaten-Extraktions-
Mechanismen genutzt werden) und auf dem Weg nicht nur an auf dem
Produktiv-Dateisystem befindliche Bilder gelangt sondern eben auf
dieselbe von der eigentlichen Dateiablage abstrahierten Weg an Bilder im
"Time Machine"-Archiv gelangt.

Dito könnte eine Textverarbeitung oder eine Layout-Software dazu
übergehen, bei jedem "Zwischenspeichern"-Vorgang einfach von sich aus
eine spezifische Version der Datei eindeutig benamst _neben_ das
eigentliche Original zu legen und diese Zwischenversionen ebenfalls in
"Time Machine" einzutüten.

Wenn man dann kurz vor Abgabe des Textes merkt, daß man sich vor 'zig
Tagen mal aus Versehen einen relevanten Absatz gelöscht hat *und* die
Anwendung sich sinnvoll mit "Time Machine" versteht, dann wären auch
alle diese Zwischenversionen *bequem* per "Time Machine"-GUI verfügbar
ohne daß sich der User vor der Kiste auf einmal damit auseinander setzen
müsste, wo die verdammte Software diese Zwischensicherungen nun
hingeparkt hat, warum die per default auf unsichtbar stehen und wie er
aus den zwar eindeutigen aber kryptischen Namen (auch hier böten sich
UUIDs <http://de.wikipedia.org/wiki/Universally_Unique_Identifier> wie
bspw. bei den Appleschen Proxy-Dateien à la Address Book und Konsorten
an) die Version herausfischt, die ihn interessiert.

Jetzt klarer?

2) "Snapshots" [...]

...was wohl auch Vorteile hat wenn mehrere Leute an einem Projekt
arbeiten, das Ganze über Netz läuft und -- meinem Bauchgefühl nach --
auch gut in Kombination mit einem CVS funktioniert(?).

Hmm... äh, weiß nicht.

Mit Snapshots kann man eben einen spezifischen Stand eines Filesystems
einfach mal schnell eben einfrieren (und dann aus diesem eingefrorenen
Zustand heraus gemütlich ein konsistentes Backup heraus anlegen oder
auch nur einen inkrementellen Sync auf ein anderes Dateisystem, das
seinerseits Differenzen zum letzten Sync platzsparend via Snapshots
abfrühstückt), etc. etc.

Was in verteilten Umgebungen noch nicht automatisch gelöst aber dafür
ein echtes Problem ist, ist Zwischenversionierung. Das _könnte_ aber
wohl so gelöst werden, wie ich das oben hypothetisch mit dem Beispiel
der Textverarbeitung zu beschreiben versucht habe.

Allerdings noch keine automatische Lösung für Zwischenversionierung
("Time Machine" sichert bspw. alle 24 Stunden und man ändert
zwischen- zeitlich die Textdatei für bspw. einen Artikel mehrfach -->
nur die zum nächsten Sicherungslauf aktuelle Fassung wandert in die
"Time Machine"- Sicherung, Zwischenversionen bleiben erstmal außen
vor)

Oje! Ich sehe schon die Jammereien wenn Sachen zurückgeholt werden
sollen die nicht innerhalb genannter 24h liegen.

_Wenn_ die Anwendung mitspiel und das "Time Machine"-Konzept adaptiert,
dann "eigentlich" kein Problem ;-)

[ZFS-Snapshots und Ausführung was dabei anders wäre, wenn
inkrementelle Unterschiede per Snapshots voneinander separiert werden
anstatt immer Dateien komplett je Version vorzuhalten]

Während der Übertragung wächst der Speicherplatz, den der zuletzt
angefertigte Snapshot benötigt (der muß natürlich bei Änderungen am
Live-Dateisystem alle Differenzen zum Live-System aufnehmen, d.h.
wächst erst mir der Zeit), *nur* um die Differenz der sich geändert
habenden Datenblöcke. Also nicht um die Gesamtgröße der
modifizierten Dateien sondern lediglich dem, was rsync de facto
blockweise überträgt (macht bei obigen fetten Dateien einen
Riesen-Unterschied aus)

Solche Vorteile dürften derzeit aber nur Personen interessieren die
Großprojekte zu betreuen haben. Also Bereiche in denen große
Datenmengen anfallen.

Nö, das hat mit großen _Dateien_ zu tun. Jeder, der bspw. immer ein
bisserl an Video-Dateien herumschraubt, die bspw. im Schnitt 8 GByte
groß sind aber an denen sich pro Tag nur paar hundert MByte ändern,
merkt den Unterschied blitzschnell. Mit der aktuellen "Time Machine"
Inkarnation, kann er sich ein "Noch'n TByte je Woche"-Abo bei seinem
Storage-Dealer holen, per ZFS-Snapshots tut's das Ganze auch mit einem
Bruchteil des Platzbedarfs, weil eben immer nur die Differenzen im
Vergleich zur letzten Sicherung (in dem Fall identisch mit Snapshot)
blockweise anfallen.

Denn: meine Annahme ist die, dass nur eine geringe Zahl der
Durchschnitts-Admins bereit ist sich über Szenarien Gedanken zu machen
wie ...

Benutzer/Admins sollen sich da drüber ja gar keine Gedanken machen. Das
soll eben Apple irgendwann mal umstellen, wenn/falls ZFS mal tauglich in
MacOS X implementiert ist. In Bezug auf Abhängigkeit von den Features
des Filesystem isses eh wurscht. Aktuell sind sie von HFS+ in 10.5-
Version abhängig, dann halt von ZFS (was mir besser schmeckt, da sich
wohl schon abzeichnet, daß "Time Machine" rudimentär Netzwerk-fähig ist,
man also die Sicherungen auch auf vernünftigen Plattformen != MacOS X
unterbringen kann)

[1] "(blockweiser Vergleich von Checksummen über die Daten)"
Message-ID: <news:d9r3fn$935$1@xxxxxxxxxxxxxxxxx>

Yo, da steht in grob, wie das bei rsync funktioniert, wenn es nur die
Differenzen innerhalb Dateien überträgt.

Den Ansatz kann sich aber weder "Time Machine" leisten (weil immer
komplette Dateien auf das Sicherungsmedium kopiert werden) noch die im
Umlauf befindlichen rsync-basierenden Lösungen, die zum Zwecke der
Speicherplatzersparnis auf dem Zielmedium mehrere Versionen der Syncs
per Hardlinks rotieren, da auch hier immer komplette Dateien neu
geschrieben gesynct werden müssen, da eine Version auf dem
Sicherungsmedium halt entweder vollwertige Datei oder Hardlink aber
nicht ein wenig von dem und von dem anderen sein kann.

Erst mit ZFS (oder einem beliebigen anderen Snapshot-fähigen
Dateisystem auf dem Sicherungs-Medium -- ist also "eigentlich"
unabhängig von dem, was der Mac selbst an Dateisystemen beherrscht und
was nicht) und Versionierung per Snapshots lassen sich beide Vorteile
kombinieren. Plattenplatzersparnis auf dem Sicherungsmedium durch
Speicherung nur der Differenzen im Vergleich zum vorigen Sicherungslauf
*und* Ausnutzen der blockweisen/differenzbasierten Übertragung von
Änderungen (was sich sowohl in zeitlicher Hinsicht als auch in Bezug auf
den für die Sicherung nötigen Plattenplatz rentiert)

BTW: Man _kann_ das Ganze mit Snapshots auf dem Backup-Medium auch schon
Stand heute machen. Auf den Macs kommt bspw. dieses rsync zum Einsatz:

<http://www.onthenet.com.au/~q/rsync/>

und man synct auf eine kleine (oder große -- je nach Geschmack bzw.
Größe der Portkasse) Solaris-Kiste mittels der "-X" Option, die ein
rudimentäres Set an Metadaten je Datei, in Form der beliebten "._"-
Dateien erzeugt. Nach jedem Sicherung einen Snapshot und darauf aufbauen
auf der Solaris-Kiste halt noch richtige Sicherung hinterher.

Funktioniert so alles auch real aber man bekommt natürlich keine
bootbaren Kopien (ist also eher was für sich häufig ändernde
Produktionsdaten) oder was ähnliches "disaster recovery"-Taugliches und
erst recht nix, was man mit dem Terminus "Time Machine" in Verbindung
bringen sollte (weil wie oben schon beschrieben die zwei wesentlichen
Punkte von "Time Machine" vollständig fehlen)... aber wenigstens hat
man Snapshots in einem Backup-Kontext zum Einsatz gebracht, olé! ;-)

So, jetzt reicht's aber mit dem Thema :-)

Gruss,

Thomas
.

Relevant Pages

  • Re: Klonen vs. Backup
    ... Modell (wenn denn die Anwendungsentwickler, ... findet keinerlei qualitative Unterscheidung der Dateien statt. ... Während bei Time Machine die Unterscheidung daher kommt, ... Nach jedem Sicherung einen Snapshot und darauf aufbauen ...
    (de.comp.sys.mac.misc)
  • Re: Pendant zur Backupsoftware Timemachine aus MacOS
    ... Interessieren würde es mich schon, ... Und ich hab seit über 10 Jahren ... kennen, was man mit ADS macht, und wie man an Dateien herankommt, die ... wie sie Time Machine offenbar bietet. ...
    (microsoft.public.de.german.windowsxp.sonstiges)
  • Re: Time Machine hat Hunger
    ... Der hat nur Dateisystem-Metadaten für einen Satz Dateien ... diese Dateien dann komplett neu gesichert werden (da Time Machine eben ... Aha, danke, Thomas! ...
    (de.comp.sys.mac.misc)
  • Re: Pendant zur Backupsoftware Timemachine aus MacOS
    ... Dateien Hardlinks setzen kann, aber auf Verzeichnisse nur Symlinks ... Time Machine offenbar bietet. ... "Time Machine Platte" anlegen und diese Platte danach elektrisch vom ...
    (microsoft.public.de.german.windowsxp.sonstiges)
  • Re: Time Machine - Was =?iso-8859-1?Q?w=E4re,?= wenn ...
    ... ist, daß der Hersteller des OS es vormacht, daß das Ganze deppentauglich ... letzte Sicherung ... Dateien wie Caches, etc.) wiederherzustellen, hat man natürlich auch ab ... um aus der letzten Time Machine Sicherung ...
    (de.comp.sys.mac.misc)
Loading