@kernelpanik
Verschiedene Backupprogramme decken verschiedene Szenarien oder Anwendungsproblem ab.
TimeMachine ist eine gute Sache für den normalen Benutzer der einen Mac und eine zweite Festplatte hat. Das ist ein einfaches Szenario und für diesen Zweck ist TimeMachine auch ganz gut geeignet und vor allem einfach zu bedienen.
Für andere Backupanwendungen ist TimeMachine wiederrum völlig ungeeignet (aber eben auch nicht gedacht).
Für manche dieser Fälle ist
mlbackup konzipiert und auch gut geeignet. Für andere Fälle wiederrum gibt es andere Programme. (Beispielsweise kann man bootbare Clones mit CarbonCopyCloner besser erstellen.)
Es kommt eben sehr auf die Aufgabenstellung und die Umstände an. Nicht jede Backupsoftware ist für jede Art von Backup geeignet oder gedacht.
mlbackup kann und will TimeMachine nicht ersetzen und umgekehrt.
@pepi: Die Dokumentation sollte schon in den Hauptordner und dann auch mit .txt enden. Was auch nicht klar ist, wie man die Backups anwirft. Muss man immer die Config-Datei mit angeben oder grast er alle gefundenen Config-Dateien ab? Gut wäre auch, wenn die Doku sagt, wie überhaupt gesichert wird. Wird eine Kopie erzeugt oder in ein Diskimage, wird beim nächsten Aufruf das Backup aktualisiert oder die Differenz neu abgelegt? Funktioniert das Backup auch auf Volumen wo die Option "Eigentümer ignorieren" aktiviert ist?
Wenn mlbackup mit so wenigen Optionen auskommt, wäre es doch prädestiniert für eine simple GUI, welche die config-Dateien anlegt und launchd-Einträge vornimmt, oder? Ok, ich weiß das kostet Zeit, war aber auch nur so ein Gedanke.
Die Idee das README als README.txt abzulegen schaue ich mir an. Aus Sicht des Unix Users (meine Zielgruppe) ist das zwar unüblich, aber nicht störend. Aus Sicht des Mac
Users ist es durchaus eine praktische Änderung, daman dann beispielsweise QuickLook verwenden kann um die Datei zu lesen. Ich glaube ich werde das aufnehmen. Danke für den Vorschlag.
mlbackup gibt bei einem Aufruf ohne Argumente gemäß POSIX Standard seine Usage Meldung aus.
Usage: mlbackup path/to/configfile
Demzufolge mußt Du also immer angeben welche Konfiguration Du verwenden möchtest.
mlbackup kann (und soll) dies nicht selbst entscheiden (können). Ich verwende
mlbackup mit vielen verschiedenen Konfigurationen für unterschiedliche Anwendungen. Aufrufen kannst Du es entweder manuell im Terminal, oder über ein launchd Item oder über
cron.
Es wird beim ersten Backup eine (fast) idente Kopie der Dateien angelegt. Bei jedem weiteren Backup werden nur noch die Änderungen übertragen. Es wird kein DiskImage angelegt, sondern nur Dateien und HardLinks (um Platz und Zeit zu sparen.) (Also Inkrementelle Backups.) Der Effekt ist, daß Du am Zielort sowohl den letzten Stand (also den vom ersten Backup) als auch den vom neuen Backup abgreifen kannst, trotzdem aber nur Platz für die erste Kopie und die Änderungen verbraucht wird. (Voruasgesetzt das Filesystem unterstütz dies. Ich beziehe mich in dem Fall auf das übliche HFS+ mit oder ohne Journaling)
mlbackup sollte auch mit Volumes wo die Zugriffsrechte ignoriert werden zurecht kommen. Ich muß gestehen, daß ich dies noch nicht explizit getestet habe. Ich werde dies aber in meine Testsuite Aufnehmen und danke für die Anregung.
Die Idee ein Konfigurations "GUI" zu erstellen ist mir auch schon gekommen. Ich bin dabei noch nicht schlüssig ob das wirklich ein Klickbares GUI werden sollte, oder ob das beispielsweise ein Assistent im Terminal sein sollte. Meine Zielgruppe sind eben Sysadmins und Serverbetrieb. Dort ist ein Klick-GUI oft nicht verwendbar, es muß aber alles über
ssh konfigurierbar sein.
Ich werde darüber nachdenken.
Wie meinst Du: Ein Backup ist zuwenig? Also dass gleich zwei HD's gleichzeitig abschmurgeln ist unwahrscheinlich[…]
Was das Feuer nicht zerstört wird vom Löschwasser erledigt.
Vertraue niemals nur einem Backup!
Gruß Pepi
)
