Re: Klonen vs. Backup

Thomas Kaiser <Thomas.Kaiser@xxxxxxxxxxxxx> wrote:

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

Hmm... auch "Geeks", "Nerds" und sonstige sollten versuchen, Dinge in
ihrer Gesamtheit zu begreifen.

Ich dachte man nennt die Leute welche das in der Gesamtheit begreifen
'Spezialisten' oder 'Fachleute'. ;-)

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>

Ah, OK. Interessant.
(warum denke ich sofort an die Jammereien wie man die Daten-Bruchstücke,
welche ja "so viel Platz" einnehmen löschen kann?)

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.

Während bei Time Machine die Unterscheidung daher kommt, dass man Daten
aus der betroffenen Applikation zuordnen bzw. zurückholen kann. So
zumindest im Film dargestellt.
Stellt sich die Frage: funktioniert das mit allen Programmen oder nur
mit Apple-eigenen? Sicher, es ist auch möglich das aus dem Finder heraus
zu machen. Die ehemalig gewünschte Objektorientierung (ich habe eine
Datei, die macht schon das richtige Programm auf...) ist damit ja zum
Teil rückgängig gemacht worden.

Den Grund dafür erklärst du -- meiner Meinung nach -- im folgenden
Absatz:

<snip>

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.
<snip>
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?

Schon durch den Clip: auf jeden Fall.

2) "Snapshots" [...]

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.

Ich bin gerade am Überlegen ob das von mir praktizierte Verhalten, neue
Dateien mit Datum und Versionsnummer, möglicherweise diesem
entgegenstehen könnte.

(...) wächst der Speicherplatz, (...), *nur* um die Differenz der
sich geändert habenden Datenblöcke.
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.

Das meinte ich (auch).

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)

Gleiches Problem hat(te) man ja mit Spotlight: auf dem lokalen Mac toll
im Netzwerk (noch) nicht zu gebrauchen.

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é! ;-)

Zwei abschließende Fragen:
* warum erwähnst du gerade eine "große Serverkiste"?

(für mich ist -- vorurteilsbeladen -- eine Solaris-Kiste quasi das
"Professionelle", was nach einem Linux-Server kommt; YMMV.)

* Kann jemand noch auf eine Rosine in den ganzem Datenkuchen hinweisen,
wo das Prinzip 'Snapshot' ordentlich beschrieben ist. Also was man
darunter versteht, etc. Ich habe durch die Diskussionen hier eine
Vorstellung, möchte die aber überprüfen.
Wenn feststehende Begriffe, dann "richtig". Vorher möchte ich dieses
Wort nicht selber schreibend nutzen.


Und danke für alles!
ClemiSan
.

Relevant Pages

  • Re: Klonen vs. Backup
    ... Die elementaren Komponenten von "Time Machine" werden negiert: ... findet keinerlei qualitative Unterscheidung der Dateien statt. ... weil es eben nur dateibasiert ... Vergleich zur letzten Sicherung ...
    (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: Alternative zur Time Capsule?
    ... der schafft auch einen Restore. ... Wer seine dateien nach /dev/null schreiben kann, ... (Sicherung in ein fragiles mitwachsendes Disk-Image), ... diese Backup-Infrastruktur mit TimeMachine verheiraten ...
    (de.comp.sys.mac.misc)
  • Re: Klonen vs. Backup
    ... Die elementaren Komponenten von "Time Machine" werden negiert: ... Snapshots haben erstmal *nichts* mit Backup zu tun, ... Im Vergleich zur letzten Sicherung geänderte Dateien dann ...
    (de.comp.sys.mac.misc)
  • Re: backup nach ftp, Datenstrom splitten
    ... Es sollen lokal keine Dateien ... kann ich die ganze Sicherung wegwerfen. ... schiebe die tarchive per rsync auf den Backup-Server. ... Zwei Sicherungsvorgänge pro Server ...
    (de.comp.os.unix.shell)
Loading