ARCHIV 1999-2006

ARCHIV :: # 2808

Nix Retro bei Retrospect 6

Dantz verwirrt mit unklarer Informationspolitik

Autor: flo - Datum: 17.02.2004

Die Backup-Suite Retrospect aus dem Hause Dantz dürfte jedem Mac-User ein Begriff sein, der nicht gerade erst seit gestern mit der Aufgabe betraut ist, große Datenmengen zu sichern. Nach eigener Aussage ist Dantz der führende Hersteller in diesem Bereich und am Mac ähnlich stark verwurzelt wie etwa Hersteller Hermstedt (ISDN-Lösungen). Der Erfolg kommt auch nicht von ungefähr, denn Retrospect war schon immer alles in allem eine sehr zuverlässige und gut zu bediendende Software, die mit diversen Produktvarianten praktisch jede Unternehmensgröße bedienen konnte. Ärger gab es trotzdem, etwa die leidige Problematik mit der Zeitsynchronisation von Backups wenn unerwarteterweise mal wieder irgendwo im Netzwerk ein Rechner automatisch auf die Sommerzeit umstellte (Version 4, nie gelöstes Problem) oder ein recht versteckter Hinweis auf die fehlende SCSI-Unterstützung in der kleinsten Retrospect-Variante in Version 5. Nun wurde uns ein Fall zugetragen, der der Informationspolitik bei Dantz auch bei Version 6 von Retrospect kein gerade makelloses Zeugnis bescheinigt. In einem Unternehmen wurde Ende letzten Jahres Retrospect auf Version 5.1 aktualisiert - die Server-Variante mit bis zu 100 Clients (knapp 70 sind tatsächlich vorhanden). Anfang diesen Jahres wurde die neue Version 6.0 für Macintosh vorgestellt und auch diesen Schritt machte das Unternehmen mit. Ein erster bitterer Beigeschmack: Eine "Grace-Period", also ein Zeitraum, in dem Käufer einer Vorversion ein nochmal verbilligtes (oder gar kostenfreies) Update auf die aktuelle Version erhält, gibt es bei Dantz nicht. Bei immerhin knapp über 1000 Euro ärgerlich - aber in der ganzen Geschichte sicherlich nur hinnehmbares "Beiwerk".

Die Aktualisierung des Retrospect-Servers lief anfangs problemlos. Der Installer fragt brav nach der Übernahme der Kataloge und Sets aus der Vorversion und vollzieht sie auch. Beim testweisen Start eines Scriptes jedoch ein erstes Problem. Eine Fehlermeldung besagte, dass das betreffende Set schreibgeschützt sei: "From Retrospect: Script "My Backup Script" failed during automatic execution, error -25054 (Catalog is pre-6.0 and read only). Please launch Retrospect and check the operations log for details." Was stecht dahinter?

Eine Menge. Denn das Format der Retrospect-Kataloge wurde mit Version 6 geändert mit der Konsequenz, dass ältere Sets zwar noch erkannt werden, man auch Daten daraus wiederherstellen kann, man diese Sets aber nicht mehr (mit weiteren Backup-Durchläufen) erweitern kann. Damit offenbart sich ein grundlegendes Problem des Datenbackups mit einer Lösung wie Retrospect: Da dieses Programm die Daten nicht "offen" speichert, sondern in einem eigenen (komprimierenden) Format, ist man als Benutzer natürlich auf die Kontinuität dieses Formats angewiesen. Wird es geändert, sieht man unter Umständen ganz schön belämmert aus der Wäsche. Dass das Format an sich aber (früher oder später) erweitert werden muss, alleine um schon neue Funktionen zu ermöglichen (neue Features sind auch die Begründung von Dantz zur Änderung), ist eine offensichtliche Tatsache.

Hier stellen sich zwei (entscheidende) Fragen. Erstens: Warum kann man die alten Sets nicht in das neue Format konvertieren? Laut Aussage des technischen Supports, den das betroffene Unternehmen kontaktierte, ist das nämlich in der Tat nicht möglich. Das mag aus technischer Sicht ja durchaus kompliziert sein, allerdings muss sich ein Anbieter wie Dantz aber auch darüber im Klaren sein, dass im äußerst sensiblen Bereich Daten-Backup Kontinuität und Kompatibilität das A und O sind.

Machen wir uns die Folgen dieses Formatwechsels einmal deutlich: Die Daten des Backups sind ja immerhin nicht verloren, insofern gehen also keine Daten verloren. Allerdings ist das Backup-Set definitiv zuende. Man kann es nicht fortsetzen. Gerade in einem Fall wie diesem mit knapp 70 Clients braucht es nicht viel Fantasie um sich den Umfang eines Vollbackups zu vergegenwärtigen. Und größere Betriebe soll's ja auch geben. Im hiesigen Fall waren die kritischen Fälle insbesondere zwei große Sets, eines davon auf einem RAID mit einem Gesamtvolumen von einem Terabyte. Das Backup belegte gut zwei Drittel des verfügbaren Platzes. Was tun?

Da man das Set nicht konvertieren kann muss man es zwangsläufig komplett neu anlegen oder ein neues Set für alle neuen Daten ansetzen. Beides hat seine gewichtigen Nachteile. Ein neues Set wäre denkbar, wenn es sich um ein Backup auf Bänder handeln würde. Doch dann würde der erste Durchlauf enorm viel Zeit beanspruchen (da der erste Lauf wieder einem Vollbackup entspricht) und die Anzahl an Bändern, die dafür benötigt werden, sollte man auch nicht unterschätzen. In diesem Fall liegt das Backup aber eben auf einem Festplatten-RAID, der "gute Rat" des technischen Supports von Dantz, man könne sich ja ein zweites RAID kaufen, klingt da wenig einfühlsam und dürfte die Finanzabteilung an den Rand des Nervernzusammenbruchs treiben. Will man das Set mit allen Daten hingegen "einfach" mit Retrospect 6 neu anlegen, hat man ein Platzproblem - wohin mit den Daten? In dem vorliegenden Fall ging es um gut 500 GB Daten - zuviel um sie doppelt auf dem Server-RAID abzulegen. Man müsste also wenigstens Teile des Backups (oder gar das komplette Backup) vorher löschen um vorübergehend wieder genug Platz zu haben. Murphy, ick hör dir trapsen. Das kann nicht Sinn und Zweck einer Backup-Strategie sein, dass man, um ein Backup-Set mit einer aktuellen Version nutzbar zu halten, zumindest Teile des Backups potentiell gefährdet. Selbst wenn es sich n anderen Fällen mit dem verfügbaren Platz ausgehen sollte ist der Zeitaufwand für diese "Konvertierung" enorm - auch das ist entgegen aller Gründe, weshalb man denn ein Backup anlegt: damit man Daten jederzeit problemlos und ohne riesigen Aufwand wiederherstellen kann. Das schließt auch mit ein, dass man mit der Pflege des Backups selbst keine unnötige Zeit verschwendet.

Bliebe ein zweiter Punkt: Warum weiß man um diese Problematik nicht vor dem Kauf/der Installation? Auf den Produktseiten findet sich kein Hinweis auf ein geändertes Format mit den geschilderten Folgen. Lediglich in der KnowledgeBase wird man fündig - den Eintrag fand der betroffene User erst nach Hinweis des technischen Supports, welchem das Problem sichtlicherweise bekannt war. Nun mögen nicht in allen Fällen die Folgen und Auswirkungen so unglücklich ausfallen wie im geschilderten Fall, aber die Änderung des Katalogformats ist bei einer Backup-Software etwas, was man groß auf die erste Seite schreiben muss. Denn zur Abwägung gehört dieser Faktor nebst allen tollen neuen Tschingderassabumm-Features auf alle Fälle dazu! Insofern ist die verfehlte Informationspolitik seitens Dantz der eigentliche Stein des Anstoßes.

Am Ende ist diese Gruselgeschichte damit noch nicht, wenn auch am Höhepunkt. Weitere Unannehmlichkeiten sind dagegen eher zweitrangig. Da wäre zum Beispiel die Tatsache, dass man die (OS-X)Clients alle "manuell" von 5.1 auf 6 updaten muss - bei fast 70 Clients, einige davon mobil, auch kein Job um den man sich reißt. Eine Netzwerkinstallation wäre da sicher bequemer. Dumm auch, dass Retrospect Server 5.1 mitnichten mit Clients der Version 6 kommunizieren kann. Im vorliegenden Fall wurde natürlich nicht nur der Server, sondern auch ein Großteil der Clients aktualisiert. Nach den Problemen mit den read-only Sets entschloss man sich aber den Server wieder "downzugraden" - der dann aber all die neueren Clients nicht mehr verstand. Auch diese Tatsache - wobei man bemerken muss, dass ein solcher Fall, in dem die Server-Version älter ist als die der Clients natürlich sehr selten bis praktisch nie vorkommt - geht aus den Produktseiten nicht wirklich hervor. Ganz im Gegenteil, denn auf dieser etwas verwirrenden Seite (Tabelle, Abschnitt "Retrospect 5.1")sieht es eher danach aus, als könne Retrospect 5.1 durchaus mit Clients der Version 6 kommunizieren, zumindest unter OS X.

Sei es wie es ist, die Informationen, die man vor dem Kauf über die Seiten von Dantz erhält (ohne sich in die Untiefen der KnowledgeBase zu vergraben) sind, gelinde gesagt, suboptimal. Dass nach einigen Versionschritten eine Änderung des Katalogformats nötig ist, sei Dantz gar nicht vorgeworfen, sehr wohl allerdings, dass dies nicht explizit an prominenter Stelle erwähnt wird. Unbefriedigend ist auch, dass es seitens Dantz keinen wirklich gangbaren Lösungsweg gibt, um alte Sets weiter fortzuführen, ohne sie komplett neu anzulegen. Und auch die weiteren, vermeintlich kleineren Unklarheiten (welche Server-Versionen funktionieren denn jetzt mit welchen Clients) und Unannehmlichkeiten (keine Grace-Period, kein Netwerk-Aktualisierer) sind nicht gerade überzeugende Argumente, um auf die neueste Version upzudaten - auch wenn sie eine Fülle sinnvoller Neuerungen bietet. Interessierte sollten auf alle Fälle genau hinsehen.

Kommentare

na danke, dantz

Von: FOX | Datum: 17.02.2004 | #1
ich habe 5.0 server im einsatz. die läuft, nach dem update auf 5.1 wirklich gut.
ich sehe also keinen grund auf 6 zu wechseln.
gut, ich hätte das problem mit dem zusätzlichen backupplatz nicht, aber trotzdem sollte man die firma nicht mit dem kauf dieser version für ihre unausgereifte software belohnen.
danke für den bericht. ich denke, es gibt hier doch viele retrospect benutzer, die für solche tipps dankbar sind.

btw: was sind denn die neuen features von version 6?

Dantz ist klasse!

Von: Dunehopper | Datum: 17.02.2004 | #2
Habe vor Jahren Support für Dantz gemacht. Die Software ist absolut genial (jedenfalls so lange ich sie supported habe, bis Version 4.1), die Leute sehr nett, hilfsbereit und kompetent.
Es betrübt mich sehr, so was hier lesen zu müssen. Schildere den Fall doch noch mal bei Dantz USA. Das Callcenter wird wenig Einfluß auf die Produktgestaltung haben.
Aber ich frage mich, was so eine Nachricht in dieser Ausführlichkeit hier zu suchen hat. Hat flo das selbst erlebt, stand dann vorm Kunden dumm da und ist jetzt sauer?

Nix für ungut!

Dunehopper

ein bisserl übertrieben, gell...

Von: eRob | Datum: 17.02.2004 | #3
Also ich arbeite mit Retrospect seit vielen Jahren und habe mehrere Serverlizenzen bei mir bzw. bei meinen Kunden laufen. ...

Ja, Dantz ist eine Mühsal, wenn man Informationen haben möchte die eventuell zum Kauf dieser Software führen und es wird einem verdammt schwer gemacht (kostenlose) Auskunft zu einem Produkt zu erhalten, eine Auskunft die man auf der verwirrenden Dantz-Website in der technischen Beschreibung der Produkte nicht findet. Ich sage nur Monopol...

Die Server-Preispolitik finde ich auch nicht ok, denn wer möchte schon 100 Clients updaten, wenn er einfach einen Server (nicht gemounted an Clients) backupen möchte und nur 5 Clients im Netz hat, die er vielleicht gar nicht backupt, weil diese Ihre Daten ja eh am Server haben. Da ist mir der Update-Preis-Sprung von 5 auf 6 schon etwas zu groß geraten... Na ja, es muss halt Kohle reingebracht werden, nach Jahren der dotcom-Dürre denkt man sich auch bei Dantz

Und da wäre noch vieles mehr was echt ärgerlich ist...

Aber die Katalog-Synchronität auf der sich Euer Artikel aufhängt, liebe grüne Freunde, ist eine Marginalie. Eine der Grundregeln bei der Einspielung von einer neuen "Haupt"-Version der Backupsoftware (nicht Update im .x.x.x Bereich) ist das Anlegen eines neuen Kataloges - also wozu sollte ich in einen "alten" 4er oder gar 3er Katalog schreiben wollen, so ich doch Version 5 habe. Ich verwende Retrospect seit vielen (fast schon zehn) Jahren und "wiederherstelle" von Bändern und Katalogen die wurden mit Version 3.x geschrieben und das ohne Probleme.

Mir scheint, da ist bei jemandem der Ärger über Dantz ein wenig zu hoch gekommen. :-)

noch einen schönen Tag und "backup to go forward" :-)

@Dunehopper

Von: flo (MacGuardians) | Datum: 17.02.2004 | #4
Nein, das ist nicht auf meinen Mist gewachsen sondern wurde uns zugetragen. Die Ausführlichkeit mag nicht jedermanns Ding sein, aber die Nachricht ist eh recht spezifisch und wird daher eh nur von denen gelesen, die es auch interessiert. Dies wiederum dürften unter Mac-Usern doch einige sein - und darum steht es hier zu lesen.

Das soll keine "Abrechnung" mit Dantz sein, denn die Software ist ja wirklich nicht schlecht. Es ist aber aus meiner Erfahrung (und sichtlicherweise aus der des betroffenen Users) nicht alles so golden wie es glänzt.

"Serving th community" beinhaltet für mich derartiges.

Die Problematik ist Dantz ja schon bekannt, sonst gäbe es den KB-Eintrag nicht, auch der (freundliche) Mann an der TechSupport-Leitung wusste nach Schilderung bereits davon und konnte auf eben jenen Beitrag verweisen. Publizierung von Problemen ist meist die beste Methode, um eine Problematik dem Hersteller ans Herz zu legen ;)

Kleinigkeit?

Von: flo (MacGuardians) | Datum: 17.02.2004 | #5
Mit Verlaub, aber die Kontinuität des Katalog-Formats finde ich enorm wichtig, wenn man, wie Retrospect, seine Daten nicht offen ablegt. Und nein, ich sehe es nicht unbedingt als ersten Schritt an, beim Updaten der Backup-Software ein neues Set anzulegen.

Bei meinem früheren Arbeitgeber ahtten wir vergleichsweise humane "Kleinstmengen" zum backuppen, also so in den Größenordnungen 40-300GB, wobei letztere Größe sich lediglich ansammelt im Lauf der Zeit. Es wurden auch immer wieder mal neue Sets begonnen, einfach um die Sets nicht allzu riesig werden zu lassen, was die Suche nach bestimmten Dateien naturgemäß erschwert.

Hat man allerdings genug Clients oder anderweitig genug Daten, dann ist selbst bei einem jährlichen Wechsel des Sets schnell eine Unmenge an Daten zu bewältigen. Da kann ich nicht mittendrin wegen des Updates der Software mal eben ein paar Hundert GB aus Lust an der Freude durch die Gegend kopieren.

Ich frage mich schon, weshalb es keine Möglichkeit gibt, die alten Sets einfach zu konvertieren. Gäbe es diese Möglichkeit, selbst wenn sie einen einmaligen Aufwand bedeutete, wäre der geschilderte Fall imho tatsächlich zu vernachlässigen. So aber...

2TBGrenze/Backupstrategie?

Von: Gruffy | Datum: 17.02.2004 | #6
Ich denke, daß einer der Hauptgründe für die Formatänderung das Beseitigen der 2 TB Grenze war. Daher kann ich mir auch vorstellen, daß eine Konvertierung sehr schwierig ist. Diese Grenze wurde in jüngster Zeit einer der Hauptgründe für viele Dantz-Kunden zu wechseln, da die Xserve RAIDs (oder auch andere RAIDs) schnell diese Grenze erreicht haben.

Falls jemand mit Server 5.x unter Panther arbeitet: autostart läuft sehr unzuverlässig und läuft vor allem nicht vom Login Screen aus, der Benutzer muß also eingeloggt sein. "Lösung" ist das kostenpflichtige Update. Begründung: die 5.x gab es lange vor Panther, daher gibt es auch keinen kostenlosen Bugfix :-(

Ansonsten finde ich es leicht kriminell, Backups über Monate oder sogar Jahre nur inkrementell zu machen. Bei wichtigen Daten gibt es bei mir 3 bzw. 4 Backup-Sets, davon sind 2 sehr kurzlebig, dienen also nur der Zwischensicherung, so daß bei der Zerstörung eines Teils der Sets oder Bänder immer ein relativ aktueller Stand in kurzer Zeit wieder hergestellt werden kann. Abgesehen davon: eine Daten"sicherung" auf Festplatten und sei es ein RAID Level 5 ist keine solche, auch wenn es nur das 2. Backupset ist (Einem Kunden sind vor kurzem in seinem RAID 2 72GB IBM-Platten abgeraucht, da hilft dann auch RAID Level 5 nicht mehr). Dafür brauche ich kein Retrospect, da wird ein RAID10/50 gefahren, somit sind die Daten vom ersten auf dem zweiten RAID gespiegelt. Außerdem wäre das Unternehmen mittelfristig so oder so an die 2TB-Grenze gestossen und hätte sich nach einer anderen Lösung umschauen müssen, z.B. BRU von der TOLIS group, ein seit fast 20 Jahren existierendes Unix-Programm, mittlerweile auch als Clients/Server-Variante für OS X erhältlich (ich kann mich noch an den Port von Dave Haynie auf dem Amiga Anfang der 90er erinnern, kam glaube ich mit AmigaDOS 2.1). Auch hier wäre natürlich ein Vollbackup fällig.

Alles in allem denke ich trotzdem, daß auch wenn ein neues Backupset erstellt werden muß, man doch sicher sein kann, daß die alte 2TB-Grenze nicht beim Einlegen des zweiten SAIT-Bandes gleich zuschlägt und mir zu verstehen gibt, daß die Anschaffung des 10kiloEuro-Laufwerks vielleicht verfrüht war :-)

In diesem Zusammenhang...

Von: Michel | Datum: 17.02.2004 | #7
... wäre auch eine Erwähnung der Dantz'schen "Zwangsupdate-Politik" (Thema "Software-Verfallsdatum") ganz nett gewesen. Zumindest Retrospect 4.1 hatte das: seit 22.2.2002 (glaub ich), nervt mein Retrospect mit dem Hinweis, dass ich meine Uhrzeit falsch eingestellt zu sein scheint. Ein Klick auf "Uhr stellen" startet dann das Programm (das heißt: automatischer Start ist nicht mehr).

Erst ein Update behebt diesen "Bug". Für die US-Version gab's kostenlose Abhilfe, in Europa muss man dagegen in die Tasche greifen, was ich nicht will. Es gibt auch einen (vermutlich nicht legalen) Crack, der aber auch nur mit der US-Version klappt.

@Gruffy

Von: FOX | Datum: 17.02.2004 | #8
------
Falls jemand mit Server 5.x unter Panther arbeitet: autostart läuft sehr unzuverlässig und läuft vor allem nicht vom Login Screen aus, der Benutzer muß also eingeloggt sein. "Lösung" ist das kostenpflichtige Update. Begründung: die 5.x gab es lange vor Panther, daher gibt es auch keinen kostenlosen Bugfix :-(
----------

das problem hatte ich auch. nach dem update auf 5.1, welches in der beschreibung auch das lösen dieses fehlers beschreibt, läuft es ohne dieses problem.
[Link]

vielleicht liegt es aber daran, dass ich mit 10.2.8 am server arbeite.

@Michel

Von: flo (MacGuardians) | Datum: 17.02.2004 | #9
Stimmt, den Hinweis auf eine falsche Uhrzeit kenne ich auch noch, wobei die Bezeichnung dessen als Zwangsupdate schon etwas hart ist. Allerdings verhinderte es den automatischen Start, was je nach Einsatz schon hinderlich ist (war bei uns damals nicht der Fall). Allerdings ergab sich der Wechsel auf Version 5 mit dem Umstieg auf OS X eh mehr oder minder von selbst.

@Fox

Von: Gruffy | Datum: 17.02.2004 | #10
Das Autostart-Problem gabs auch schon mit Jaguar, wurde dann in der Version 5.0238 (oder so) endlich behoben. Da denkt man, daß die Jungs daraus lernen, aber beim nächsten Update passiert der gleiche Murks wieder :-(

Dantz ist klasse, und Humor haben sie auch:

Von: Dunehopper | Datum: 17.02.2004 | #11
Antwort vom Dantz-Support zu flos zweitem Punkt im dantz-Forum:

Quote:

What is not understandable is Dantz's comprehensive failure to announce this issue IN ANY OF ITS DOCUMENTATION. As far as I can tell, it is not mentioned in pre-sales literature, the owner's manual, the readme file, the tutorials, or anywhere else.



I agree!

At the very least, Dantz should have written something in the ReadMe like:

"Older Backup Sets: The format that Retrospect uses for backup sets' catalog files has been changed to support some of the new features. Users will need to create new backup sets in order to back up data. The new backup sets will not be recognized with previous versions of Retrospect. Older backup sets will be treated as read-only. While users will not be able to append to pre-existing backup sets, they will be able to restore data from them, and will be able to recreate the older backup sets' catalog files from their media if necessary. "

Then they should have included that ReadMe with the software, and posted it on their web site. Maybe even as an article in their KnowledgeBase.

[Link]

Oh. Right. Never mind.

:-)

@Gruffy
Ich stimme Dir 100% zu, nur inkrementelle Backups zu machen ist mindestens gefährlich und ein Restore dauert ewig lange. Wöchentlich (z.B. Freitag) ein Voll-Backup ist schon sinnig.

Ach ja, wenn das inkrementelle Backup so viel schneller ist, bedeutet das womöglich, dass viele Dateien lange nicht geändert wurden. Mal drüber nachdenken, ob man diese Daten nicht woanders hin auslagert (auf DVD brennen oder so). Geht natürlich nur, wenn die Datenstruktur das zulässt.

Zum Humor.

Von: flo (MacGuardians) | Datum: 17.02.2004 | #12
Ein Eintrag in der KnowledgeBase ist schön und gut, aber nicht wirklich das, was ein potentieller Käufer durchliest. Nachdem es einen solchen Schritt bislang nicht gab (oder gab es einen zwischen 3 und 4?) ist es auch nciht das, womit ein User rechnet. Ich bleibe dabei: Diese Meldung gehört zur Featurelist. Ansonsten wirkt es so, als wolle Dantz diese Information verstecken.

Und zu den Kritiken an der Backup-Strategie: Ausschließlich inkrementelle Backups sind logischerweise kein Optimum, mir ist jedoch aber auch nicht bekannt, ob dies die einzigen Backups im betroffenen Unternehmen sind (wohl nicht).

However ;)

nochmal @ gruffy

Von: FOX | Datum: 17.02.2004 | #13
du hast geschrieben, das update von 5 auf 5.1 war kostenpflichtig.
das update von 5.0 auf 5.1.177 ist aber doch kostenlos.

ich glaube du meintest von 5.1.177bla auf eine noch höhere version 5.1.177blabla kostet es was, oder?
und da ist der fehler dann wieder drin ???

kläre mich bitte auf.
danke

@Fox

Von: Gruffy | Datum: 17.02.2004 | #14
Ok, nochmal zum mitschreiben:
den Fehler, das die Autostart-Funktion nicht zuverlässig klappte, gab es mit der 5.x, als Jaguar rauskam. Das wurde dann nach längerer Zeit mit einem kostenlosen Update (.238 oder so) gefixt. Mit Panther gibt es jetzt wieder das gleiche Problem, nur muß man diesmal zahlen, weil 5.x schon lange da war, bevor Panther rauskam (so sagt Dantz), der Fehler ist erst mit der 6.x behoben. Daß die allerdings so blöd sind, den gleichen Fehler zweimal zu machen, halte ich für ein starkes Stück, insbesondere, weil die Wiederholungstat richtig Geld kostet.

Sets neu anlegen?

Von: Ralf Saalmüller | Datum: 17.02.2004 | #15
Ich hab zwar noch eine alte Version und nur 3 Clients aber ich glaube mich erinnern zu können, dass man Sets aus Bändern neu erstellen kann.

Sprich Bänder noch da, aber die Set-Datei wurde glöscht. Macht nix, Bänder rein, Set neu erstellen lassen. Da das (nur) den BackUp Server belastet sollte das eher zuträglich sein als ein neues Voll-BackUp.

Oder geht das auch nicht? Sprich die alten BackUps verwenden?

Switch! Arkeia und BRU unterstützen OS X

Von: Kilian | Datum: 18.02.2004 | #16
BRU
[Link]

und Arkeia haben nun OS X support
[Link]

Beide unterstützen selbstverständlich Resource Forks etc. und kommen aus der Linux-Serverecke, also denke ich das Verläßlichkeit hier großgeschrieben wird. Man ist ja nicht auf Gedeih und Verderb Retrospect ausgeliefert.