Hallo Leute,
wollte mal fragen ob es eine Möglichkeit gibt seine ganzen Fotos automatisch und ohne viel Aufwand sichern zu lassen sobald man seine Festplatte an den Laptop anschließt?

Es kann ja z.b sein das Mac OS selber eine Funktion hat. Oder eine passende app im AppStore.

Wichtig ist dabei das ich kein System Backup machen möchte.

Sondern im Idealfall, das ich die Festplatte anmache evtl eine app starte und die dann ganz automatisch meine Bilder immer sichert auf der externen Platte.

Wie gesagt die cloud und System Backup sollten keine Vorschläge sein

Wäre Super ihr könnt mir da weiterhelfen mit einer kleinen Erklärung falls ihr was wisst.

Dafür kannst du annähernd jedes Synchronisationsprogramm nehmen.

Ich würde Synchronize! empfehlen, da man dort eine Sicherung automatisch starten kann, wenn die Festplatte angeschlossen wird, und nach Abschluss die Platte auch automatisch wieder unmounten kann. Alternativ dazu auch Chrono Sync, ob das allerdings diese Option bietet weiß ich nicht

Ist denn Synchronize eine app oder ein Programm ? Freeware ?
Und da kann man ganz einfach sagen bitte nur Fotos sichern automatisch und fertig ?

Du gibst bei dem entsprechenden Programm (= App) Quelle und Ziel an bzw. welche Ordner synchronisiert werden sollen.

· SyncTwoFolders (free) →
· SuperDuper! ($ 28) →
· Synchronize! X Plus ($ 29) →
· CarbonCopyCloner ($ 40) →
· ChronoSync ($ 40) →

Vielen Dank hoffe das gratis Programm reicht dafür aus

Hat es glücklicherweise: Automator (der verkannte Blechtrottel):

Wenn Du Dir selbst was Gutes tun willst, vergißt Du die ganzen blöden Sync-Programme, startest den Automator und klickst Dir die Lösung zusammen. Warum ist das besser? Weil "Hilfe zur Selbsthilfe", "der Appetit kommt beim Essen" und "Mal wieder was gelernt"

Wenn man mal merkt, wie simpel man sich damit repetitive und stupide Vorgänge automatisieren kann und mit wie wenig Aufwand man das, was Apple mitliefert bzw. sich auf den einschlägigen Seiten im Netz als fix- und fertige Automator-Flows oder -Aktionen gratis findet, sinnig für die eigenen Bedürfnisse modifizieren läßt, greift man nicht mehr zu irgendwelchen limitierten "Apps" und so Zeugs sondern modelliert sich seine perfekt passenden Arbeitsabläufe einfach selbst.

Ähem, SuperDuper! und CarbonCopyCloner sind keine »blöden« Apps — ob sie allerdings das richtige zum ausschliesslichen Synchronisieren sind, sei dahingestellt. Beide sind eigentlich (ausgereifte) Clone- und Backupprogramme. Und sie können einige Dinge besser als Apples eigene Tools.

Haha, SuperDuper! ist kein Backup-Programm (ohne Versionierung kein Backup) sondern ein Klon- bzw. Synchronisierungs-Programm. Mit dem CCC kannst Du -- wenn Du weißt wie -- auch Backups anfertigen (mit "rotierenden Hardlinks" am Syncziel -- das ist aber genaugenommen nur eine sophisticated Anwendung des im CCC steckenden und beim inkrementellen Syncen genutzen Tools namens rsync).

Zum Glück geht's hier nicht um Backup sondern nur um Sync. D.h. die Tools könnte man einsetzen, wenn man nichts lernen aber Geld ausgeben will. Und darum geht's mir: Darauf hinweisen, dass OS X seit 'zig Versionen ein ganz tolles Hilfsmittel an Bord hat, das für die Automatisierung stupider Abläufe perfekt und viel flexibler als alle "fertigen" Sync-Mittelchen ist.

Grad der CCC benutzt(e) übrigens überwiegend "Apples eigene Tools", initial ditto und dann asr , zwischendrin aber auch mal psync und seit geraumer Zeit rsync (nicht das, was Apple an Bord hat, sondern eines, das um einige Patches bereichert ist, mit denen sich dann auch vollwertig Mac-Dateien inkl. aller Spezialitäten wie Extended Attributes, Beibehalten der HFS+-immanenten transparenten Dateikompression, usw. usf. syncen lassen).

Der CCC hat nach wie vor keinerlei eigene Funktionalität sondern ist ein GUI für "Apples eigene" oder im Programmbundle beigelegte Kommandozeilen-Werkzeuge. Das macht ihn keinesfalls schlechter. Ist für viele Zwecke sicherlich geeignet. Aber der Automator ist natürlich das Tool der Wahl im konkreten Fall

Endlich mal jemand, der eine Lanze für Automator bricht.
Für mich ist das eins der am meisten unterschätzten Tools für den interessierten Otto Normalanwender. Mächtig genug für viele der „nervigen“, weil immer wieder auftauchenden Arbeitsabläufe, aber nicht so kompliziert und zeitaufwändig wie extra eine Programmiersprache zu lernen.

Guter Hinweis. Das "interessiert" respektive "lernwillig" ist natürlich ein Kriterium, das viele Nutzer gar nicht aufbringen, da Lernresistenz ja gerne schon mal in jungen Jahren einsetzt.

Naja, und Automator ist andererseits viel mehr als eine "Programmiersprache", weil ich mit paar Klicks aus dem Ding heraus fix und fertige "Apps" bzw. Droplets (also "echte Programme", die per Drag&Drop Dateien verarbeiten), Dienste, die systemweit zur Verfügung stehen (per Kontextmenü bspw.!), Plugins fürs Drucksystem, Ordneraktionen (also Hotfolder-Funktionalität) oder auch periodische Jobs einrichten kann.

All das in einer klassischen Programmiersprache wäre erstmal ein immenser Aufwand rund um die eigentliche Programmierung der eigentlichen Aufgabenstellung an sich.

Aber wenn man sich dann mal bisserl in das Konzept eingedacht hat und an Grenzen stößt, ist es extrem simpel, deutlich komplexere Funktionalität, für die es keine fertige "Automator Action" gibt, ganz simpel per Skripting (egal ob AppleScript oder CLI-basiert irgendeine der anderen 'zig Scripting-Varianten, die in OS X mitgeliefert werden) nachzurüsten.

Das Wichtigste dabei scheint mir aber immer noch zu sein, dass man statt Lebenszeit für das Antrainieren der Bedienung eines limitierten "Spezialwerkzeugs" zu verschwenden stattdessen lieber Lebenszeit in das Erlernen neuer Möglichkeiten, Probleme simpel selbst zu lösen, investiert. Das liegt jedem natürlich anders und ich glaub ja auch noch, dass die ideale Automator-Zielgruppe die Schnittmenge aus "bisserl schlau" und "bisserl faul" darstellt

Von den wahnsinnig genialen Möglichkeiten, wie man mit dem Automator in professionellen Umgebungen simpelst Probleme lösen kann, für die "klassische ITler" immer den Hebel erstmal ganz woanders ansetzen würden, mal ganz zu schweigen.

Wo gibt es eine einfache, so das ich es auch verstehe, Anleitung für Automator.
Es geht schon los, das ich nicht entscheiden kann ob man eben arbeitsablauf, oder ein Programm erstellen soll
Jochen

Also sollte die Frage an mich gegangen sein, dann schwierig, da ich in der Beziehung zu sehr Fachidiot bin

Ich empfehl aber regelmäßig "Kai Surendorf", wenn es um gute Erklärungen eher auf Einsteiger-Niveau geht, so dass ich jetzt mal Richtung http://www.galileodesign.de/artikel/gp/artikelID-255 zeigen würde.

Das Büchlein, das ich dann Fortgeschrittenen empfehlen würde (weil es fortgeschrittene Konzepte und alles, was neu ab Automator 2.0 dazugekommen ist, enthält), wäre das da: (Automator for Mac OS X 10.6 Snow Leopard)

Zur konkreten Frage: Das Grundkonzept in Automator ist, dass man modular einzelne Automator-Aktionen zu Arbeitsabläufen kombiniert. Ein solcher Arbeitsablauf läuft dann in jedem Fall innerhalb Automator, damit Du ihn auch außerhalb des Automator-Programms selbst nutzen kannst, stehen verschiedene Optionen zur Verfügung. Bei Dateihandling ist "Programm" meist die sinnigste. Arbeitsabläufe können später jederzeit als "Programm" gespeichert werden (über "Ablage" "Konvertieren in …").

Sorry, aber das ist quatsch. Eine (bootbare) Kopie (Klon) ist auch ohne Versionierung ein Backup.
→

Und Du widersprichst Dir bei …

vs.

Dein Ansinnen eine Lanze für Automator zu brechend in allen Ehren — aber alles selber machen zu wollen frisst Zeit. Viel Zeit. Und das hat bestimmt nichts mit Lernunwilligkeit zu tun; ich benutze auch Automator für manche Zwecke. Aber alles hat seine Grenzen — und dann bin ich gerne bereit Entwicklern Geld für ihre Arbeit zu geben um mir das Leben zu erleichtern, zumindest so lange wie die Qualität (inkl. Usability und Support) stimmt — oder schneiderst Du Dir auch selber Deine Kleidung?

P.S.: Ich schätze Dein (Fach-)Wissen — aber Dein Ton beherbergt einen leichten Anstrich von Arroganz und Geringschätzung. Wenn das nicht Deine Absicht war, dann einfach Schwamm drüber.

Ergänzend zu Thomas’ Anmerkungen:

Ich persönlich starte meistens mit einem Arbeitsablauf. Der lässt sich nämlich am leichtesten testen.
Später, wenn ich meinen Ablauf in ein Programm umwandel, muss ich meistens nur das erste Kommando (welches normalerweise die zu bearbeitenden Files angibt) entfernen – die werden von der „Arbeitsumgebung“ geliefert (z.B. indem du Files auf das Programm-Icon ziehst).

Wenn Du fit in Englisch bist, ist das hier ein guter Einstieg:

Puh, also ohne Dich "geringschätzen" oder mich arrogantisieren zu wollen...

Aber im Jahre 6 nach TimeMachine ausgerechnet im Kontext "Mac" über die Definition von Backup diskutieren zu wollen und das auf dem Beweisführungsniveau von Wikipedia-Einleitungssätzen ist... äh... völlig absurd. Sogar objektiv absurd, weil Backup/Datensicherung eines dieser Themen ist, bei dem man sich den Mund fusselig reden kann, Einsicht in Wesen und Notwendigkeit aber immer nur durch Erfahrung (in dem Kontext "nicht abgefangener Datenverlust") einsetzt.

In dem Sinne nur ein kleines Gedankenspiel: Ich biete Dir an, Dir ein kleines Skript zu basteln und zu schicken, das auf Deinem Rechner innerhalb der nächsten 30 Tage vereinzelt Dateien löscht und vereinzelt mehr oder weniger offensichtlich manipuliert (Dateien meint damit alles Mögliche, normale Daten, Kontakte im Adreßbuch aber auch Teile von Systemeinstellungen, so dass ich anschl. eine Hintertür auf Deinem Mac habe). Das Ganze stellt somit einen Simulator für eine Reihe von Szenarien dar, wegen denen man Backup macht.

Ich würde Dir empfehlen, parallel eine TimeMachine-Sicherung (oder irgendeine andere Form echten Backups) zu fahren. Denn wenn Du nur klonst, wirst Du erst dann merken (wenn überhaupt -- Stichwort kein sinnvolles Restore-GUI), was fehlt oder geändert wurde, wenn es längst zu spät ist.

Ein stumpfes periodisches Syncen/Klonen der Daten von A nach B schützt nur vor einer einzigen Gefahrenquelle: Sterbende Platte. Es ist damit auf dem Niveau von RAID-0, nur noch wesentlich sinnfreier implementiert, nämlich mit Zeitverzögerung. Alles, was auf A weg oder kaputt ist, ist es dann auf B auch. Die einzige Chance, das abzufangen, bestünde darin, permanent ein frisches Sync-/Klonziel zu wählen und immer wieder einen Komplett-Klon vorzuhalten (wie Du dann anschl. diese vielen Klons auf der Suche nach der letzten funktionierenden Version einer Datei durchsuchen willst, sei mal dahingestellt).

Ein Backup-Mechanismus überschreibt eben nichts am Ziel sondern behält es, wenn's gelöscht wurde und erzeugt eine neue Version, wenn's geändert wurde. Und viel viel viel wichtiger: Ein funktionales Backup definiert sich einzig und alleine über einen problemlos durchzuführenden Restore, d.h. im Zweifel ein GUI, mit dem der User überhaupt bemerken kann, welches die letzte Version von etwas war, stöbern kann, wann die gelöschten Daten noch da waren usw. usf. und idealerweise ein GUI, das Abstraktion bietet (wie es TimeMachine eben auch tut und ein objektorientiertes API bietet und damit Programme, die es unterstützten, erlaubt, Objekte und nicht nur stumpf Dateien wiederherstellbar zu machen. Als Beispiel einen Kontakt im Adreßbuch/Kontakte.app: Den kriegst Du übers TM-GUI direkt im Adreßbuch wiederhergestellt, das GUI zeigt Dir klipp und klar im historischen Verlauf alle Änderungen an den Kontaktdaten auf und mußt noch nicht mal wissen, in welcher kryptisch benannten Property-List im Dateisystem die Kontaktinformation physisch gespeichert war)

Bitte nicht falsch verstehen: Es gibt durchaus Daseinsberechtigungen für Syncen/Klonen (heutzutage allerdings äußerst limitierte) aber man sollte ein periodisches Komplettgesynce bitte nicht mit einem richtigen Backup-Mechanismus verwechseln. Bzw. sich über die ganzen Implikationen klar werden und abwägen, ob man wirklich sowas nahezu Sinnfreies durchführen will, wenn die problemlos nutzbare Alternative am Mac TimeMachine lautet (mit mind. 2 rotierenden Sicherheitsmedien tatsächlich eine Backup-/Restore-Implementierung, die vollumfänglich ist)

Aber klar, man kann einen Klon auch Backup nennen (man kann Äpfel ja auch als Birnen bezeichnen). Bringt halt nur nix, wenn's um Inhalte und nicht nur Wortklauberei geht. Apropos Letzteres: Du kannst das Nachfüttern von Informationen zur Funktionsweise des CCC und zu den Anpassungen des enthaltenen Kommandozeilen-Werkzeugs rsync gerne als Widerspruch bezeichnen (wenn's Dir nur um Wortklauberei gehen sollte )

Man kann das aber auch wie folgt lesen/verstehen/adaptieren. Nachdem der CCC eben ausschließlich ein GUI für Kommandozeilenwerkzeuge ist und er ein gepatchtes rsync enthält, bedeutet das letztlich zweierlei:

- man kann dem CCC auf die Finger schauen, was er da dann im Hintergrund für das Erledigen des eigentlichen Jobs abfeuert (bspw. um den rsync-Aufruf in einer Automator-Aktion zu nutzen oder sich angucken, wie man asr für das Anfertigen von Komplett-Klons im block-copy-Modus abseits der Donationware CCC nutzen könnte)

- man sollte, wenn man Mac-Dateien vollwertig syncen will, im Zweifel nicht das bordeigene rsync nehmen sondern das im CCC vergrabene nutzen (/Applications/Carbon Copy Cloner.app/Contents/MacOS/ccc_helper.app/Contents/MacOS/rsync)

Mehr Information steckte nicht in den beiden Aussagen

Angesichts der dermaßen flachen Lernkurve bei der Nutzung des Automator, grad wenn's um sowas Trviales geht wie neue Dateien von A nach B kopieren, und Deinem Vergleich mit "Kleiner selber schneidern" spar ich mir weitere Ausführungen

Also soll ich mir CCC anschauen, und die dort verwendeten »Teile« rauskopieren um mir per Automator etwas zu bauen, was _keine_ halbwegs vernünftige GUI hat? Hmm, lass mich überlegen … ja macht Sinn. Nicht.

Ich bekomme mit CCC ein Werkzeug an die Hand was ich nicht selbst entwickeln muss — und erspare mir die Arbeit mich in eine Materie zu vertiefen um dann per Automator etwas zusammenzuklicken was ich auch einfacher haben kann.

Für den »normalen« User ist eine vernünftige GUI empfehlenswerter als halbgare Lösungen, aus diesem Grund kann ich die meisten Sync/Klon/Backup Software-Lösungen eben auch nicht uneingeschränkt empfehlen — ausser CCC und SuperDuper!.

Es gibt gute Gründe bei einem Backup sich nicht (nur) auf Time Machine zu verlassen oder dieses nicht zu benutzen:
1.) Bei einem Klon ist mein Rechner _sofort_ wieder einsetzbar; defekte Platte raus und geklonte Platte rein.
2.) Große Datenmengen die häufiger verschoben werden (z.B. verteilt auf 4 interne Platten zu je 3 GB)

Wahrscheinlich gibt’s auch noch andere Szenarien.

Anmerkung: der häufigste Grund für die Notwendigkeit von Backups waren in meiner 22-jährigen Mac-Laufbahn … defekte Platten. Sowohl bei mir als auch bei meinen Kunden.

Und natürlich hast Du auch recht, Time Machine ist für den »normalen« User ausreichend und am einfachsten.

Aber wenn Du den Wikipediaartikel wirklich gelesen hättest, würdest Du nicht — mal wieder — so abfällig argumentieren.

Naja... :

Der Fairness halber bietet die selbe Quelle auf der Folgeseite Dangerous (to your data) Misconceptions about Backup aber auch Unterstützung für deine Argumentation

einigt euch in eurer begriffsdefinition doch auf folgendes:

"echtes" (bzw sinnvollstes) backup = inkrementelles backup

natürlich geht die definition von backup schon da los, wenn ich einfach von daten xy eine kopie erstelle. egal welche daten genau, egal wann, egal wie, egal wohin.
theoretisch kann ich auch von hand ein textdokument neu abtippen und es würde unter "backup" fallen.
darüber wie sinnvoll oder praktisch die jeweilige form des backup ist, sagt es ja erstmal nix aus.

Akzeptiert: Ein stumpfes periodisches Syncen/Klonen der Daten von A nach B schützt nur vor der einen Situation, dass A komplett weg/kaputt/nicht-verfügbar ist. Dann hat man halt noch B (und damit -- Scusa, dass ich mich wiederhole -- im Wesentlichen nichts weiter als ein zeitversetztes und im Zweifel noch nicht mal vollständiges Äquivalent zu etwas, das sich RAID 0 nennt)

Vor all den anderen und typischerweise viel häufiger vorkommenden Gründen, ein Backup zu machen (eben nunmal alles, was zu Datenverlust und Datenkorrumption führen kann wie unsachgemäße Bedienung, Malware, amoklaufende Software, etc. pp. [1]), schützt das nicht. Und ein Klon bringt kein Restore-GUI mit, ich kann darin nicht nach älteren Versionen suchen, etc. pp. -- es ist halt eben nur ein Werkzeug, das in speziellen Situationen nützlich sein kann aber alleinig darauf vertrauend und auf ein ordentliches Backup verzichtend ist keine gute Idee. "Ein Klon ist kein Backup"

Davon abgesehen empfehle ich abgespeckte Klone, die bewußt vor bestimmten Ereignissen angefertigt werden, ja durchaus ebenfalls. Aber selbstredend nur als Ergänzung zu Backup, siehe bspw.

Man braucht sich übrigens auch gar nicht um Begrifflichkeiten streiten. Nur einfach darüber nachdenken, ob etwas, das Quelle und Ziel immer 1:1 identisch hält, in Situationen hilft, wo an der Quelle was schiefläuft (mir bspw. passieren öfter mal Malheurs, die ich teils erst Wochen später entdecke) und einem dieser Umstand nicht auffällt, bevor der nächste Sync bzw. irgendein Geklone abgefeuert wird.

[1] Nachtrag zu einer weiteren Ursache von Datenverlust/Datenkorrumption: bzgl. malader Dateisysteme kommt es dann stark auf die Verfahrensweise an, wie gesynct bzw. geklont wird. Bzw. ist das genau einer der Unterschiede zwischen dem Begriff syncen (dateiweise) und klonen (block-level also eigentlich unterhalb des Dateisystems und damit auch prinzipbedingt Dateisystemfehler 1:1 duplizierend). Aber wenn schon nicht mal der Begriff "Backup" noch irgendeine konkrete Bedeutung hat, seitdem die Marketing-Fuzzies von Sync-Software ihn mißbrauchen, braucht man mit sowas gar nicht erst anfangen.

"Können" nicht "sollen"

Ich glaub, es ist an der Zeit, explizit mal drauf hinzuweisen, dass ich zumindest hier mit Dir kein Privatgespräch unter vier Augen führe. Ich schreib hier im öffentlchen Raum aus diversen Gründen (unter anderem, um gratis meine hier abgesonderten Äußerungen abklopfen zu lassen, um fehlerhafte Standpunkte meinerseits korrigieren zu können -- da kam hier auch schon viel Wertvolles, wenngleich bislang v.a. von "gfhfkgfhfk"), bin mir bewußt, dass hier paar mehr mitlesen (mit Umweg über Tante Google sogar zeitversetzt) und dass die Menschen unterschiedlich sind. Daher sonder ich manchmal irgendwas "einfach so" ab, weil ich's für erwähnenswert halte aber nicht um meinen Vorredner damit irgendwas zu entgegnen. Wäre toll, wenn Du das akzeptieren könntest, denn das erspart Dir hoffentlich in Zukunft, jeden meiner Sätze als persönlichen Angriff zu interpretieren

Zu rsync und "die Menschen sind unterschiedlich": Alteingesessenen Macianern treibt die Erwähnung von Kommandozeile die Zornesröte ins Gesicht, konvertierte Windows- oder Linux-User hingegen freuen sich vielleicht über den Denkanstoß, dass man die ganze originale Aufgabenstellung schon mit einem simplen


abfrühstücken könnte. Dazu noch ein LaunchAgent, der per WatchPaths-Direktive auf Änderungen in "/Volumes" reagiert wie in beschrieben angelegt und der Lack ist geritzt. Fortan führt Anstöpseln der fraglichen Platte zu einem 1:1 Sync der Bilder auf die externe Platte, genau was der Anfrager wollte und noch dazu mit Bordmitteln (aber evtl. überhaupt nichts, was er anfassen will, weil Kommandozeile -- wer weiß)?

Was ist der Unterschied zu irgendeiner GUI-Lösung: Kost' nix und was dabei gelernt. Und was ist das Ergebnis: Identisch, d.h. in erster Linie Themaverfehlung. Denn warum denkt man denn drüber nach, Bilddateien auf der internen Platte periodisch auf eine externe zu syncen? Vermutlich irgendwas mit Datensicherheit. Ein 1:1 Gesynce bietet das aus den hier im Thread schon in epischer Breite durchgekauten Gründen aber nur bedingt.

An der Stelle könnte nun der Automator ins Spiel kommen oder auch nicht. Evtl. reicht ja auch schon das gute Gefühl, irgendwas irgendwie doppelt zu haben (in der Reailität also das berühmte "in falscher Sicherheit wiegen")

Klar, ein Klon kann in manchen Situationen eine prima Ergänzung zu einem Backup sein. Er ist aber kein Ersatz dafür (und ja, ich reite die ganze Zeit nur auf diesem einen Aspekt herum: periodische 1:1 Geschichten ohne Versionierung am Ziel haben nichts mit Backup sondern wenn dann nur Sicherstellen von Verfügbarkeit zu tun)

Da würde ich jetzt dann schon über Archivierung nachdenken. Hab's aber wahrscheinlich einfach nur falsch verstanden.

Siehste mal, wie unterschiedlich das alles ist. Das ist bei mir bzw. in meinem Umfeld (sowohl privat als auch vor allem Kunden) so selten der Grund für das Einspielen eines Restores (darum ging's eigentlich, oder?) gewesen, dass es einfach vernachlässigbar ist.

Hat wohl was mit pro-aktiven Maßnahmen zu tun (konkret: Verticken von Hardware am Ende des Abschreibungszeitraums -- sollen sich doch andere mit an Altersschwäche sterbenden Platten auseinandersetzen --, Schaffen von sinnvoller Redundanz vulgo RAID, Datenhaltungs- und Hardware-Konzepten)

Sehr schön, das Totschlagargument schlechthin.

Ich bin ab jetzt dann wahlweise unglaubwürdig oder hyperarrogant, wenn ich drauf hinweise, dass ich in der ganzen Thematik durchaus bisserl drin bin. Wir verdienen mitunter unsere Brötchen damit, Datensicherheit bei Kunden richtig zu implementieren. Mit einem bunten Strauß an Werkzeugen und Konzepten -- eben so, dass es zur Situation (Aufgabenstellung + Kostenrahmen + Güterabwägung) paßt.

Und in großen Installation verschwimmen dann gerne schnell auch mal die ganzen Begrifflichkeiten, da redet man nicht mehr (nur) über Backup sondern eher über CDP und federt systemimmanente Nachteile einer Lösung durch Ergänzung mit anderen Lösungen ab bzw. geht die Thematik auf allen Ebenen bei bewußter Mißachtung von "klaren Grenzen" zwischen diesen und jenen Konzepten an.

Bspw. brauchst Du bei Datenmengen im höheren 2-stelligen oder gar 3-stelligen TByte-Bereich nicht mehr über Komplettrestores nachdenken, weil die viel zu lange dauern würden. Ergo braucht's ne Spiegelung der Daten, damit bei GAU auf Produktivstorage nur ein Schalter umgelegt werden muß und alles weitergeht.

Da die Ressourcen, die man auf das Thema werfen darf, endlich sind, fängt man dann halt an, gewisse Sachen zu mischen. Auf dem Produktivstorage friert man dann bspw. stündlich die Desktop-Datenbanken der Volumes ein, erzeugt einen Snapshot, synct diesen Snapshot auf den Storage, der direkt am Ausfallsystem hängt, und hat damit dort sowohl eine 1:1-Kopie als auch (ähnlich wie bei TM) noch den Stand der letzten Stunden und je einen Stand je Vortag eine Woche lang vorrätig (in Form von Snapshots, die man wiederum als eigene Volumes rausreichen kann, was auch read-only geschieht, damit die User direkt den "kleinen Restore zwischendurch" durchführen können. Und laut den Logs wird das exzessiv genutzt).

Man kann bspw. auch die Trennung zwischen "Archiv" und "Online Storage" aufbrechen, indem man das Archiv konzeptionell herstellt. Durch klare Workflows, die Daten nur auf definierten Wegen in den -- von außen ansonsten nur read-only befuttelbaren -- Archiv-Storage rutschen lassen. Vorteil: Das Zeugs ist stets online (was in vielen Installationen aufgrund irgendwelcher Applikationen notwendig ist) aber braucht nicht gesichert werden weil ist schon archiviert.

Wir haben auch schon Event-gesteuerte Versionierungssysteme implementiert, damit "Klassiker" wie beim Speichern zerschossene Layout-Dateien ihren Schrecken verlieren bis hin zu Hijacking von "bösen" Applikationen, um vor Überschreiben älterer Dateien automatisiert eben diese noch schnell als vorherige Version wegparken zu können.

Und dann kommt immer wieder "high level"-Datenrettung dazu, was wohl der Hauptgrund dafür ist, dass ich bzgl. "das ist aber kein echtes Backup!" aufgrund leidiger Erfahrung übersensibel bin

Worte sind Schall und Rauch. Begriffsdefinitionen auch

Übrigens: Nein, das "Inkrementelle" also die ausschließliche Betrachtung des Transports des Datendeltas seit dem letzten Vorgang ist nicht das Spannende, wenn es einem um Datensicherheit gehen sollte.

Das Relevante ist, wie mit eben jenem Delta umgegangen wird.

Mach ich inkrementelles 1:1 Gesynce oder Geklone, dann hab ich das Daten-Delta halt schneller von der Quelle an das Ziel gebracht. Aber bei dem Vorgang letztlich nur Quelle und Ziel schneller wieder identisch bekommen, was im Falle von Korrigierbarkeit von Fehlern an der Quelle das aus bedeutet. Wenn an der Quelle aus Versehen und unbemerkterweise ein Ordner gelöscht wurde, dann ist er bei einem inkrementellen Sync blitzschnell auch am Ziel weg.

Wenn wir von Datensicherheit reden, ist doch ausschlaggebend, was technisch am Ziel und in der Backup-Software mit dem Datendelta geschieht und nicht wie es transportiert wird. Bei "echtem" Backup geschieht dann zwangsläufig Folgendes:

- das Delta überschreibt am Ziel nicht die schon rumliegenden Daten sondern erzeugt automatisch Versionen aller Änderungen
- an der Quelle gelöschte Dateien/Ordner sorgen nicht für ein Löschen am Ziel sondern fließen ebenfalls als irgendeine Art von Vermerk ("gelöscht am") in die Backup-Software ein
- alle Versionen und Löschvorgänge werden in sinniger Form protokolliert/indiziert/vermerkt

Die beiden ersten Punkte sorgen erst dafür, dass Malheurs an der Quelle revidiert werden können und der letzte ist eminent wichtig dafür, dem User (oder Admin in großen Umgebungen) eine Möglichkeit im Restore-GUI an die Hand zu geben, überhaupt gelöschte respektive geänderte Dateien zu finden um sie wiederherstellen zu können.

Alle großen Backup-Lösungen setzen dafür auf Datenbanken/Indizes, um die Vorgänge zu protokollieren bzw. ein Herumsuchen in älteren Versionen des Datenbestands im Restore-GUI zu ermöglichen. Apple hat das für TimeMachine anders implementiert und quasi den ganzen Backup-Index ins Dateisystem auf der Sicherungsplatte geklatscht (darum auch die Hardlinks auf Verzeichnisse ab 10.5, damit beim späteren Restoreversuch die Anzeige der Zeitstempel vorheriger Versionen so simpel/schnell funktioniert und sich das Backup nicht unnötig aufbläht).

Die Backup-Software reduziert sich also auf Zugriff auf die Dateisystemstruktur der TM-Platte (also "Index im Dateisystem enthalten") und die Restore-APIs (und die finden sich nicht nur im Finder sondern objektbasiert in vielen Programmen wieder, abermals das von mir schon angeführte Beispiel "Kontakte". Wenn ich Adreßbuch bzw. Kontakte offen habe, einen Kontakt anklicke und dann im Dock auf das TimeMachine-Icon klicke, dann krieg ich direkt in der App selbst alle früheren Versionen des Kontakts aufgelistet und restaurierbar, so weit das TM-Backup zurückreicht. Mit einem dummen Klon oder 1:1-Sync ein Ding der Unmöglichkeit)

Eben: Und damit ist es eine rein akademische Diskussion ohne praktischen Nutzen. Eben das, was nahezu immer dabei rauskommt, wenn man sich dem Thema "Datensicherheit" aus der völlig falschen Richtung, nämlich von der Thematik "Datensicherung" her nähert.

Macht man's hingegen richtig, d.h. kommt aus der Richtung "Datenwiederherstellung" wird auf einmal alles wahnsinnig einfach (und die Konsequenzen für den Bereich "Datensicherung" leiten sich automatisch aus den Erfordernissen der Datenwiederherstellung ab)

Um Dein Beispiel mit "Sicherung auf Papier" aufzugreifen. Der GAU tritt ein und 100.000 Textdateien sind weg. Es ist an der Stelle jetzt eigentlich einigermaßen wurscht, ob die Backups auf Papier vorher durch Abschreiben oder Ausdrucken angefertigt wurden. Denn jetzt geht es darum, ob bzw. wie der andere Weg zurück funktioniert, d.h. ob mit vertretbarem Aufwand in einem akzeptablen Zeitfenster aus dem Papier-"Backup" wieder Daten gemacht werden können und wie nah die dann am Original sind (Datenintegrität).

Waren's Ausdrucke könnte OCR klappen, wurde das Backup von Hand abgeschrieben, richtens die Datentypistinnen (ggf. in Indien oder China, wenn Zeitaufwand egal und monetärer Aufwand mehr eine Rolle spielen sollten). Wenn man für sich definiert, dass der "Restore" tatsächlich soundso lange dauern darf, die Datenintegrität dabei auch mal unter 99% rutschen wird und Geld irgendwie keine Rolle spielt, dann kann man "Abschreiben auf Papier" als für den Zweck sinnvolle Backup-Strategie gelten lassen, egal wie bescheuert das eigentlich ist. Sollte eines der drei Kriterien aber dadurch nicht erfüllt sein, dann ist diese Backup-Variante automatisch untauglich, weil sie den definierten Anforderungen an die Datenwiederherstellung nicht gerecht wird.

Weg von dem seltsamen, zu einem echten Beispiel. Kollege von anderem Systemhaus erzählt die Anekdote immer wieder gern: Wurde anno 2000 rum zu Neukunde gerufen, weil dort Server abgeraucht war. Kein Problem, neuer Server hingestellt nebst RAID... aber als es dann ans Einspielen der Daten ging ("Klar, Backup haben wir!" im Vorfeld), große Augen. Da waren in einem Stahlschrank über 1.000 DAT-Bänder, weil "Server-Backup" dort inkrementelles Retrospect-Backup an einem Client-Mac auf DAT über mehr als 3 Jahre bedeutete.

Konsequenz für den Restore: Fatal. Alleine die "Rücksicherung" aller 1000 Tapes hätte Wochen wenn nicht gar Monate gedauert. Aber selbstverständlich kam es nicht dazu, weil schon eines der ersten Tapes im Ar*** war und damit der ganze restliche inkrementelle Zinnober nutzlos.

Wäre die "Backup-Strategie" von der anderen Seite her (Anforderungen an Restore und Desaster Recovery) entwickelt worden, dann wäre klar gewesen, dass es wenigstens alle paar Wochen mal ein Vollbackup dazwischen braucht, weil sonst sowohl Rücksicherungs-Zeitraum als auch Ausfallwahrscheinlichkeit des Backups viel zu hoch geschraubt werden.

Das Ganze von der richtigen Seite her aufzuziehen, heißt Randbedingungen zu definieren und im Zweifel herzustellen, Daten ggf. zu klassifizieren (was ist wichtiger Kram, der sofort wieder verfügbar sein muß, wo reicht's auch, wenn das erst 1-2 Tage später wieder online ist?), Restore- und Desaster-Recovery-Abläufe zu definieren und zu testen (und das immer und immer und immer wieder). Sonst Augenwischerei bzw. Themaverfehlung (und netterweise etwas, das immer erst dann auffällt, wenn's zu spät ist).

Und jetzt kommt das Tolle: Mit all dem theoretischen Unterbau von Datensicherheit braucht man sich am Mac seit 10.5 eigentlich nicht mehr befassen: Einfach TimeMachine nehmen und ab 10.8 noch das coole Feature nutzen, dass man rotierend auf mindestens zwei unterschiedliche Medien sichern läßt (mit den rotierenden Medien wird TM quasi perfekt für Home-/SOHO-Backup). Und wenn man ergänzend noch irgendwie in der Gegend herumklonen will, soll man das halt tun, solange man nicht vergißt, parallel und vorrangig auch Backup zu machen.

Aus der Wiederherstellungsperspektive betrachtet wird auch die Einordnung von 1:1 Gesynce/Geklone bzgl. Datensicherheit auf einmal ganz einfach. Wenn ich bei meiner dann sehr speziellen Implementierung von Datensicherheit einfach als Randbedingung definiere, dass a) Menschen nie mehr unachtsam sind bzw. Fehler machen, b) das dito für Software gilt und c) Malware/Schadsoftware einfach per Dekret verboten sind, dann und nur dann ist ein 1:1 Klon/Sync ein ausreichendes Mittel, um Datensicherheit herzustellen. Denn dann braucht's auf einmal keine älteren Versionen und dann kann auch nie der Fall eintreten, gelöschte Dateien wiederherstellen zu müssen. Und dann kann man endlich einen 1:1-Klon guten Gewissens Backup nennen.

Wenn man nicht in dieser perfekten Welt sondern in der realen lebt, sieht's halt leider bisschen anders aus. Und dass man in der realen und keiner Traumwelt lebt, ist etwas, das selten erklär- aber meist recht gut erfahrbar ist (durch Datenverlust eben, den man nicht abfangen kann). Doch die Abhilfe ist im Zweifel so simpel: TimeMachine und fertig.

Thomas Kaiser

Danke für die schönen Einblicke in den Datenalltag. Auch wenn’s etwas lang war, war es spannend zu lesen und hat zumindest für mich nochmal ein paar Denkanstöße für’s Thema »Backup« gebracht.

Noch eine letzte Off-Topic-Anmerkung von mir: Nein, ich halte es schon für sehr sinnvoll, sich auf gemeinsame Begriffe zu einigen, da dies Missverständnissen vorbeugt. In diesem Sinne möchte ich kritisieren, wie du den Begriff Datensicherheit verwendest. Ich weiß ja dank des Kontextes, wie es gemeint ist, dennoch möchte ich darauf hinweisen, dass Datensicherung ungleich Datensicherheit ist. (Und beides hat erst recht nichts mit Datenschutz zu tun - das lese ich an anderen Stellen des öfteren mal).

Also: Datensicherung dient zur Erhöhung der Verfügbarkeit der Daten. Für den Begriff der Datensicherheit werden üblicherweise sieben Teilaspekte definiert; die wichtigsten sind soeben genannte Verfügbarkeit, Korrektheit (Integrität) und Vertraulichkeit (Stichwort Verschlüsselung, Zugangskontrollen, ..).

Da Datensicherung eben nur EINEN dieser Teilaspekte und somit nicht gleichzusetzen mit Daten/Informationssicherheit.

Während ich nicht annehme, dass du dies verwechselst, weise ich trotzdem darauf hin, da ja mehr Augen das geschriebene sehen, als sich an dieser Diskussion beteiligen, wie du selbst zuvor geschrieben hast.