RAID 1 Platte mag nicht mehr - und nun?

[stk]

Moin,

irgendwie hören meine Probleme nicht mehr auf ... .

Meine aktuelle Serverkonfig schaut wie folgt aus:

120 GB Samsung als Bootplatte
2 x 250 GB Samsung an ACARD ATA-Controller
Software RAID 1 aus den beiden 250er Platten gestrickt.

Nun meldet mir RAID-Eye (btw: nettes Freeware Tool) aber recht vernehmlich einen Fehler auf einer der beiden Platten. Weder über RAID-Eye noch über das FPDP bekomme ich das RAID wiederhergestellt (was nicht weiter verwundert, beide nutzen wohl diskutil im Unterbau dafür ).

Ich würde nun gerne die defekte Platte aus dem RAID nehmen, ohne meine Daten auf der ersten Platte zu verlieren. FPDP will aber wohl genau das machen, wenn ich "löschen" wähle. Und natürlich will ich anschliessend auch wieder eine neue Platte ins RAID einhängen.

Geht das und wenn ja wie?

Gruß Stefan

[pepi]

Dazu mußt Du erst das RAID brechen, dann kannst Du die Platten einzeln löschen und nachher wieder einen Spiegel draus machen. Kann der ACARD Controller das nicht in Hardware? Ich bilde mir ein da gäbe es so ein kleines Mäuseklavier mit dem man RAID 0 und 1 auf diesen Dingern direkt am Controller aktivieren konnte.

Wie es um die Datensicherheit von einem RAID 1 steht muß ich Dir ja zum Glück nicht erklären. Vielleicht überlegst Du Dir bei der Gelegenheit ob Du das nicht als zwei einzelne Volumes konfigurieren willst und dann per rsync beispielsweise so nette Backups machen magst. Ich könnte Dir da auch mit einem kleinen fertigen Skript aushelfen.
Gruß Pepi

[stk]

Moin,

Kann der ACARD Controller das nicht in Hardware? Ich bilde mir ein da gäbe es so ein kleines Mäuseklavier mit dem man RAID 0 und 1 auf diesen Dingern direkt am Controller aktivieren konnte.

Nicht der AEC-6280M, das ist der ganz einfache Controller, der nur den Large-Drive Support ermöglich, aber keine RAID-Funktion mitbringt.

Vielleicht überlegst Du Dir bei der Gelegenheit ob Du das nicht als zwei einzelne Volumes konfigurieren willst und dann per rsync beispielsweise so nette Backups machen magst. Ich könnte Dir da auch mit einem kleinen fertigen Skript aushelfen.

Zugegeben: um RSync hab ich bisher immer einen Bogen geschlagen. Vermutlich weil mich die "GUI" von RSyncX mal erschreckt hat .

Aber auf das Scriptangebot würde ich gerne zurückkommen. Egal ob RAID oder nicht: schon alleine um meine jetzige Backup-Routine zur externen Platte, die mit DejaVu auch nicht wirklich chic läuft, zu ersetzen.

Gruß Stefan

[pepi]

Hmm, mit einem GUI welches über ein Terminal hinausgeht kann meine Lösung nicht dienen. Ist immerhin für Server konzipiert, daher ist es da sehr unsinnig ein GUI zu machen. Aber grundsätzlich isses mit einer Zeile im Terminal installiert und mit einer Konfiguration per Textfile ist es funktionsfähig. Kamma für "User" per cron/launchd automatisieren, oder auch in ein .command file oder ein Applescript verpacken.

Das Skript ist langzeitgetestet und funktioniert für meine Zwecke auch auf größeren Serverinstallationen wunderbar. Als Filesystem empfehle ich auf Quelle und Ziel HFS+, mit anderen Filesystemen müßte es eigentlich funktionieren, ich habs aber mangels Notwendigkeit nie getestet. Es berücksichtigt Metadaten, allerdings keine ACLs. Zum Platzsparen werden Hardlinks verwendet, ebenso wird ein rotierendes DeltaBackup gemacht.

Am Besten Du probierst das einfach mal mit einem kleinen Ordner und ein paar Änderungen an der Quelle aus. Das Ding kommt aber grundsätzlich auch mit Mengen um ein TB herum gut zurecht. (Auf Netzwerkbackups gehe ich jetzt hier aus Zeitgründen nicht näher ein.)

Solltest Du Probleme damit haben, sag' bescheid. Für Vorschläge und Ideen bin ich natürlich jederzeit zu haben.
Gruß Pepi

[stk]

Moin,

< fredaufwärm>kaum ist ein halbes Jahr rum, schaff ichs auch mal mich mit dem Script auseinander zusetzen< /fredaufwärm>

Um ein ursprüngliches Thema einer 1:1 Kopie der Datenplatte zu erhalten ist's nicht wirklich das, was ich haben wollte, weil es auch mit einer Rotation "0" immer noch einen Zwischenordner mit der Bezeichnung und Datum/Uhrzeit des Backups erstellt. So what, da hilft mir psync, resp. DejaVu aus.

Für ein rollierendes Backup ist das Script aber genial und Verbindung mit launchd einfach welt. Bin so begeistert, das ich's gleich bei einem Kunden in Einsatz bringen wollte, aber da jetzt auf ein bis dreieinhalb Dinge stoße, die anders sind und die ich nicht aufgelöst bekomme:

a) Das Zielvolume ist keine lokale, externe HD sondern ein FileShare Mount eines Iomega NAS. Wenn ich man rsync richtig gelesen habe, sollte ich das doch per

*…*iomega.domain.tld:/name_der_Freigabe/ggf_name_des_zielordners …

als Parameter eintragen?!

b) die zu backupende Struktur ist ziemlich uferlos. Tonnen von Unterordner in Unterordner in Unterordner. Alles mit ziemlich verbosen Benennungen, führenden Kennziffern, Leer- und Sonderzeichen, garantiert jenseits von 255 Zeichen Länge Ich vermute mal das DejaVu deswegen brav Vollzug einer 1:1 Kopie meldet, in den Tiefen der Ordner auf dem Zielvolume aber immer noch alte Dateistände führt. Was habe ich da bei rsync zu erwarten?

c) der überwiegende Teil des Errorlogs liest sich

rsync: chown "/Volumes/Backup/backup-2007.09.20-13.35.04.noindex/DataVol/.vol" failed: Operation not supported (45)
rsync: chgrp "/Volumes/Backup/backup-2007.09.20-13.35.04.noindex/DataVol/Groups" failed: Operation not supported (45)

- eine Folge dessen, das wir über ein FileSharing Volume reden, welches ich aktuell unter seinem /Volume/-Pfad als Ziel definiert habe?

Ach ja: wir reden über r66

Gruß Stefan

[pepi]

[...]
a) Das Zielvolume ist keine lokale, externe HD sondern ein FileShare Mount eines Iomega NAS. Wenn ich man rsync richtig gelesen habe, sollte ich das doch per

*…*iomega.domain.tld:/name_der_Freigabe/ggf_name_des_zielordners …

als Parameter eintragen?!

b) die zu backupende Struktur ist ziemlich uferlos. Tonnen von Unterordner in Unterordner in Unterordner. Alles mit ziemlich verbosen Benennungen, führenden Kennziffern, Leer- und Sonderzeichen, garantiert jenseits von 255 Zeichen Länge Ich vermute mal das DejaVu deswegen brav Vollzug einer 1:1 Kopie meldet, in den Tiefen der Ordner auf dem Zielvolume aber immer noch alte Dateistände führt. Was habe ich da bei rsync zu erwarten?

c) der überwiegende Teil des Errorlogs liest sich

rsync: chown "/Volumes/Backup/backup-2007.09.20-13.35.04.noindex/DataVol/.vol" failed: Operation not supported (45)
rsync: chgrp "/Volumes/Backup/backup-2007.09.20-13.35.04.noindex/DataVol/Groups" failed: Operation not supported (45)

- eine Folge dessen, das wir über ein FileSharing Volume reden, welches ich aktuell unter seinem /Volume/-Pfad als Ziel definiert habe?

Ach ja: wir reden über r66 [...]

Vorab, keine PNs um auf Threads aufmerksam zu machen, da ich automatisch auf jeden Thread abonniert bin in dem ich poste. In Threads wo es um meine Software geht bleiben diese Abos natürlich auf Ewigkeit bestehen. Ist ja auch in meinem Interesse.

Ich versuche mal aus dem ganzen Gepost hier ein "Ganzes" zu machen.

Ad a)
Zwei Missverständnisse. Das eine ist, daß Du das Ziel als server.domain.tld:/Pfad/Zum/Serverlokalen/Ziel angeben möchtest. Das wird natürlich von rsync unterstützt und wenn Du den Zielpfad in der [FONT="Courier New"]/etc/maclemon/backup/meinTollesBackup.mlbackupconf[/FONT] so angibst dann wird [FONT="Courier New"]mlbackup[/FONT] das auch so versuchen. Das "Problem" ist, daß rsync dann so wie es dafür geschrieben wurde [FONT="Courier New"]ssh[/FONT] als Transport verwenden will was vom iomega NAS mit an Sicherheit grenzender Wahrscheinlichkeit nicht unterstützt wird. (Wenn Du von einem Mac auf einen Mac Server so backuppen möchtest, dann funktioniert das grundsätzlich, allerdings solltest Du in so einem Fall das Skript definitiv am Server, also dort wo das Backup zu liegen kommt, laufen lassen und die Daten vom "Opfer" pullen. Dann klappt das wunderbar und so setze ich das selbst auch mehrfach bei mir und meinen Kunden erfolgreich ein.)

Ich weis nicht über welches Protokoll Dein Share vom iomega NAS gemountet wird. Ich nehme an, daß dies über SMB geschieht, und die HD dran in FAT32 formatiert ist. Das würde erklären warum dort kein [FONT="Courier New"]chown[/FONT] und auch kein [FONT="Courier New"]chmod[/FONT] funktionieren. FAT32 unterstützt sowas schlicht und ergreifend nicht, jedenfalls nicht über SMB.

Grundsätzlich kann ich davon abraten rsync für lokal gemountetet remote Volumes zu verwenden. Rsync macht sehr viel Gebrauch von den Fähigkeiten eines Filesystemes, wie eben Zugriffsrechte, Hardlinks etc. die auf einem derart gemounteten Volume nicht verfügbar sind. Der Vorteil von rsync geht dabei auch zu einem großen Teil flöten. (Beispielsweise kannst Du so keine Hardlinks mehr verwenden was jedes Mal in einer kompletten Kopie der Daten ausartet, sowohl vom Zeit- als auch vom Platzbedarf.) Ich supporte diese Vorgehensweise daher, weil sie nicht zuverlässig funktioniert auch nicht und rate von solcher Art mit meiner Software Backups zu machen ab. Dafür ist sie nicht konzipiert und die mangelnde Unterstützung von essentiellen Voraussetzungen macht es einigermaßen unpraktisch. Sorry.


Ad b)
Länger als 255 Zeichen können die Filenamen auf der Quelle schonmal nicht sein. Rsync kommt bei entsprechenden Filesystemen sehr sehr gut mit sehr langen Pfaden und auch Sonderzeichen zurecht. Ich habe einen expliziten Test-Quellordner um mein Skript während der Entwicklung zu testen in dem es Dateinamen mit obskuren Zeichen gibt, die allseits beliebten Bullet Points sind da noch das harmloseste. Auch mit Japanisch (Hiragana, Katakana und auch Kanji) stellen für mein Skript kein Problem dar. (Lediglich der Name des Backupsets darf keine Umlaute enthalten, japanische Zeichen beispielsweise aber schon. Auf diesen Bug in rsync weise ich in meiner Sample.config aber explizit hin!) Probleme können entstehen wenn das Zielfilesystem nur mangelnde Unterstützung für solche Dateinamen oder Pfadlängen mitbringt. (zB FAT32...)

Ich habe bereits geplant eine Überprüfung des Filesystems einzubauen um evt. auf solche Probleme hinweisen zu können. Da dies aber dann auch remote funktionieren muß stellt sich das noch als einigermaßen problematisch dar. Grundsätzlich ist die Idee aber mal da und auch angedacht, in der Umsetzung allerdings nicht mit sonderlicher Priorität gereiht, da bisher fast alle [FONT="Courier New"]mlbackup[/FONT] nur auf HFS+ Volumes einsetzen.


Ad c)
Ja, siehe auch meine Erklärungen oben.



Danke für das interessante Feedback, den Real-Life Bericht und die Lorbeeren zu [FONT="Courier New"]mlbackup[/FONT]. Sowas ist immer interessant.

Gruß Pepi
PS: Nachdem mein Domaintransfer nun nach 10 Tagen endlich geschafft ist... kann ich nun weiter daran arbeiten [FONT="Courier New"]mlbackup[/FONT] ofiziell und so richtig ordentlich zu OpenSourcen.
UPDATE: [FONT="Courier New"]mlbackup[/FONT] wurde unter der GPL veröffentlich!

Gruß Pepi

[stk]

Moin,

Vorab, keine PNs um auf Threads aufmerksam zu machen, da ich automatisch auf jeden Thread abonniert bin in dem ich poste. In Threads wo es um meine Software geht bleiben diese Abos natürlich auf Ewigkeit bestehen. Ist ja auch in meinem Interesse.

ok, sorry for that.

…Das "Problem" ist, daß rsync dann so wie es dafür geschrieben wurde [FONT="Courier New"]ssh[/FONT] als Transport verwenden will was vom iomega NAS mit an Sicherheit grenzender Wahrscheinlichkeit nicht unterstützt wird.

yep - das ssh-Thema … wir hatten es an anderer Stelle

Ich weis nicht über welches Protokoll Dein Share vom iomega NAS gemountet wird. Ich nehme an, daß dies über SMB geschieht, und die HD dran in FAT32 formatiert ist.

FAT32 - keine Ahnung. Die Web-Adminoberfläche schweigt sich ebenso beharrlich darüber aus wie die vorhandene Dokumentation des Teils. Aber die Wahrscheinlichkeit das wir über FAT oder NTFS reden dürfte hoch sein. BTW: anstelle des Iomega wäre auch noch ein LaCie NAS vorhanden, welches unter NTFS läuft, falls das hilfreich wäre.

Die Verbindung zum Iomega (und auch zum LaCie) wird jedenfalls per AFP aufgebaut, SMB wäre alternativ eingerichtet, NFS wäre (zumindest beim Iomega) machbar, wenn es denn der Sache dienlich wäre.

Grundsätzlich kann ich davon abraten rsync für lokal gemountetet remote Volumes zu verwenden. … und die mangelnde Unterstützung von essentiellen Voraussetzungen macht es einigermaßen unpraktisch. Sorry.

Ok - was wäre denn die Alternative? Gehen wir vielleicht die Eckdaten mal durch, die ich gemeinhin von meinen Kunden so vor die Füße geworfen bekomme:

a) reichlich Platzbedarf. TB-Platten/RAIDs für die Aufnahme von Daten sind i.d.R. vorhanden und werden gerne und fleissig genutzt, sprich: wenn ich nächste Woche nicht wieder mit einer neuen Strategie daherkommen soll, sollte das Backup auch auf Größen bis in den TB-Bereich anwendbar sein. Der Stand von gestern ist gut, der von vorgestern zusätzlich wäre noch besser und eigentlich wäre uns am liebsten wenn wir das von vor 6 Wochen noch irgendwo wiederfinden könnten … ok den 6-Wochen Zahn kriegt man mit einem Blick auf die Betriebswirtschaft schnell gezogen: Menge Datenspeicher x Preis/MB vs. Menge verlorene Arbeitszeit im Vergleich läßt die meisten dann doch klein beigeben. Aber faktisch bleiben immer noch o.g. TB-Menge x gewisse Anzahl Tage über. Einigen wir uns mal auf 5 Arbeitstage retour, versuchen das vernünftigerweise auf Zuwachs zu organisieren, dann bleibt immer noch Faktor 2 bis 3 auf das operative Volumen über, die das Backupmedium mitbringen sollte.

b) Räumliche Trennung von operativen Daten und Backupmedium.

Wenn ich das zusammennehme kommt immer irgendein NAS mit RAID-Funktion und fetten HDs raus. NAS wegen b), Fette RAIDs wegen a). Wenn NAS, dann ist allen gemein - soweit ich den Markt überblicke: die Dinger arbeiten ziemlich gerne mit Windows zusammen (AD-Einbindung, CIFS-Rechtevergabe, SMB-Protokoll) und haben das ein oder andere Mac/Linux-Feigenblatt in Form von AFP, FTP und/oder NFS an Bord. Sprich: an der Ecke entsteht oben beschriebenes Problem. Firewire durch die Hütte ziehen um b) gerecht zu werden kommt eher nicht in Frage, zumal die Auswahl bezogen auf a) auch relativ begrenzt ist (spontan fallen mir da eigentlich nur die Sonnet-Teile ein).

Immerhin - jetzt habe ich ein Netgear in die Finger bekommen, welches rsync von sich aus unterstützt und nach einem rsync-Server fahndet um von diesem das Backup zu saugen … Könnte ein echter Lichtblick sein. Bliebe der Rest der Kundschaft, der seine vorhandene Hardware nicht in die Tonne hauen mag. Meine und deren bisherigen Versuche eine Backup zu organisieren: DejaVu, iBackup, Retro(su)spect, Apple Backup, … irgendwann ist alles immer irgendwo an Grenzen gestossen. Deja Vu ist an den Rechten verzweifelt, iBackup brauchte Tage für den Durchlauf, Retrospect und Apple haben Ergebnisse fabriziert, dennen man glauben konnte oder auch nicht … .

Ad b)
Länger als 255 Zeichen können die Filenamen auf der Quelle schonmal nicht sein.

Wäre auch meine Idee. Ich hab nochmal genau nachgezählt. Die echten Daten bewegen sich sehr hart unterhalb der 255er Zeichengrenze, aber testhalber habe ich mal Datei erzeugt, die den Rahmen in der Tat sprengt. Der komplette Dateinamen, inkl. Pfad (in UTF-8, keine Sonderzeichen maskiert, wahlweise die "/" mitgezählt oder auch nicht) liegt über 255 Zeichen! Das Teil läßt sich anlegen, editieren, verschieben, … . Trägt nicht gerade zu meiner Beruhigung bei. Der nächste HiWi beim Kunden macht's IRL, wundert sich ob der nachfolgenden Ergebnisse nur kurz und haut stattdessen auf den armen Sysadmin ein .

(Lediglich der Name des Backupsets darf keine Umlaute enthalten, japanische Zeichen beispielsweise aber schon. Auf diesen Bug in rsync weise ich in meiner Sample.config aber explizit hin!)

Das hatte ich gelesen und genau das war's was mich verunsicherte

# This script is not yet capable of handling Umlauts correctly!

Das es sich auf das vorhergehende Naming des Backupsets bezog, … jetzt ist's klar .

Danke für das interessante Feedback, den Real-Life Bericht und die Lorbeeren zu mlbackup. Sowas ist immer interessant.

Wenn man - wie ich - seine Lösungen schon nicht selber basteln kann, dann sollte man wenigstens sein Problem einigermassen treffsicher beschreiben können, um mit Hilfe anderer zur Lösung zu gelangen. Sprich: ein Feedback zu geben ist ja wohl das Mindeste .

PS: Nachdem mein Domaintransfer nun nach 10 Tagen endlich geschafft ist...

ich wunderte mich schon … dann kommen auch endlich die Bildchen dazu, auf die ich schon ganz neugierig bin .

kann ich nun weiter daran arbeiten [FONT="Courier New"]mlbackup[/FONT] ofiziell und so richtig ordentlich zu OpenSourcen.

Ich hab irgendwo was im Hinterkopf das es schon r68 geben soll …?

Gruß Stefan

[pepi]

[...]ok, sorry for that.
[...]BTW: anstelle des Iomega wäre auch noch ein LaCie NAS vorhanden, welches unter NTFS läuft, falls das hilfreich wäre.

Die Verbindung zum Iomega (und auch zum LaCie) wird jedenfalls per AFP aufgebaut, SMB wäre alternativ eingerichtet, NFS wäre (zumindest beim Iomega) machbar, wenn es denn der Sache dienlich wäre.

Schon verziehen, ist nur eine Unsitte die sich in letzter Zeit irgendwie breitzumachen scheint...

SMB ist wie schon erwähnt eher hinderlich. Die Frage ist wirklich was das zugrundeliegende Volume kann und ob die verwendete Software nicht versehentlich eine steinzeitliche Version von netatalk ist.
NFS unterstützt keine Authentifizierungen, bzw. Eigentümer und schon garnicht Metadaten blahfasel und so wie wir das brauchen.
Die LaCie NAS könnten theoretisch sogar HFS+ Platten ansprechen können. (Doppelter Konjunktiv, also möglich, aber sehr unwahrscheinlich. Immer noch wahrscheinlicher als bei iomega.)

[...]Alternative?[...]
a) reichlich Platzbedarf.[...]gestern[...]vorgestern[...]besser[...]6 Wochen[...]Betriebswirtschaft [...]immer noch[...]TB-Menge[...]Anzahl Tage[...]Zuwachs[...]Faktor 2 bis 3 auf das operative Volumen[...]irgendein NAS mit RAID-Funktion[...]gerne mit Windows[...]Mac/Linux-Feigenblatt [...]Firewire[...]kommt eher nicht in Frage
[...]

Mein Versuch einer Quitessenz. Mein Vorschlag in dem Fall wäre ein echter Server und nicht so ein "Pseudo Server"-NAS Hilfskonstrukt. Erstens kann ein Server auch noch andere praktische Aufgaben erledigen und zweitens ist man dort von der Intelligenz der vorhandenen Software und Protokolle deutliche flexibler. (AFP, SMB, VPN, SSH, rsync, etc.)
Ich backuppe bei einem Kunden von mir mit [FONT="Courier New"]mlbackup[/FONT] mehrere hundert GB zwischen zwei Standorten über Kreuz. Jede Nacht über eine 1Mbit/s Verbindung. (Das initiale Backup habe ich per portabler HD übertragen, die inkrementellen Backups laufen per [FONT="Courier New"]mlbackup[/FONT] jede Nacht problemlos darüber.)

Wichtig für den Sepicherbedarf des Backups ist die Menge der Daten die sich im Zeitintervall der Backups ändert! Wenn ich 10 Mal am Tag so ein Backup mache, dann braucht es nur minimal mehr Speicherplatz als das Original, da ich bei [FONT="Courier New"]mlbackup[/FONT] hardlinks einsetze um den Backupvorgang zu beschleunigen und Platz zu sparen.

Du kannst das gerne mal testen. Als Beispiel Quelle empfehle ich Dir den ~/Library/Mail Ordner. (Sofern Du Apple Mail.app verwendest.) In diesem Ordner tut sich sicherlich jeden Tag was. Unter Umständen ist der auch garnicht so klein. (Bei mir doch gute 7GB inzwischen.) Er besteht aus vielen kleinen Dateien. Das erste Backup braucht genausoviel Platz wie das Original. Jedes tägliche Backup genau soviel Platz wie die Menge an eMails die Du an dem Tag erhalten hast. Trotzdem kannst Du jeden Tag einzeln wieder so herstellen wie er an dem Tag war. Dank Hardlinks wird im Finder jeder Ordner soviel Platz anzeigen wie das Original, insgesamt wäre das aber unter Umständen sogar ein vielfaches der Gesamtkapazität Deines Zielvolumes. ([FONT="Courier New"]du[/FONT] im Termina hilft die tatsächliche Größe festzustellen. So eine Art Reporting ist auch für irgendwann mal angedacht. Auf jeden Fall wird das optional, da es sehr sehr viel Leistung zieht das zusammenzutragen.)

Überschlage also wie groß Euer Live-Datenbestand ist und wieviel sich da täglich ändert bzw. wieviel dazukommt. Diese Menge mußt Du mit den Tagen Multiplizieren die Du vorhalten möchtest. Dann solltest Du den ungefähren Aufwand fürs Backup Volumen haben. je nachdem ob ihr eher große Einzeldateien habt oder viele kleine Dateien mußt Du ein wenig korrigieren. Bei großen Einzeldateien nach oben, bei vielen kleinen Dateien eher nach unten.

Als Beispiel für den Zeitaufwand: Ich backuppe das ~/ meine PowerBooks auf meinen Server per rsync+ssh (natürlich mit [FONT="Courier New"]mlbackup[/FONT]). Ich fahre von meinem PowerBook G4/1.5Ghz ganz gemütlich mit 100Mbit/s Ethernet auf meinen alten G4/450 (mit dem dicken 1.8TB RAID) und die 72GB sind im Schnitt in 60-90 Minuten dort angekommen. Bei schnelleren Rechnern darfst Du erwarten, daß auch die rsync Rechnerei entsprechend flotter geht. Das gleiche gilt für Gbit Ethernet welches hilfreich ist und auch ein flottes RAID ist sicher kein Fehler. Und wenn das Backup in der Nacht drei Stunden braucht wird es wohl auch egal sein.

Das hatte ich gelesen und genau das war's was mich verunsicherte

# This script is not yet capable of handling Umlauts correctly!

Das es sich auf das vorhergehende Naming des Backupsets bezog, … jetzt ist's klar .

Bezieht sich nur auf die Bezeichnung des Backup-Sets und ist soweit ich das bisher nachvollziehen konnte ein Bug in rsync. Ich werde dies wohl in den Erklärungen noch etwas deutlicher ausarbeiten um Missverständnisse in Zukunft hintanzuhalten. Diese Einschränkung betrifft nicht die Daten die gesichert werden sollen!

Wenn man - wie ich - seine Lösungen schon nicht selber basteln kann, dann sollte man wenigstens sein Problem einigermassen treffsicher beschreiben können, um mit Hilfe anderer zur Lösung zu gelangen. Sprich: ein Feedback zu geben ist ja wohl das Mindeste .
[...]Ich hab irgendwo was im Hinterkopf das es schon r68 geben soll …?[...]

Leider sehen das nicht alle so, und auch nicht bei kostenloser Software. ich freue mich, daß Du ein gutes Verständnis dafür aufbringst!
r68 ist sagen wir mal ein sehr privater Fork von r66 mit einer sehr speziellen Anpassung an die sehr speziellen Bedürfnisse eines Kunden die in dieser Form nicht für die Öffentlichkeit geeignet sind. Ich würde dringend davon abraten [FONT="Courier New"]mlbackup[/FONT] r68 irgendwo einzusetzen wenn er nicht der Autor der Software ist und genau weis was das Ding tut (oder im Falle von r68) nicht tut.
Weitere Entwicklungen werden mit Sicherheit auf Basis von r66 entstehen und ich bin auch am Überlegen das ganze langfristig einem kompletten Refactoring zu unterziehen. Grundsätzlich ist mir die Stabilität und Zuverlässigkeit dieses kleinen Skriptes am wichtigsten. Features sind an Ideen ca. 22.874 Millionen Ideen vorhanden die jedoch nach meiner Auffassung allesamt hinter der Zuverlässigkeit stehen müssen und diese auf keinen Fall kompromittieren dürfen. Immerhin vertraut man Backup Software seine Daten an. Garantien kann ich auch keine Abgeben, aber ein wenig helfen ruhiger zu schlafen.


Hab ich jetzt Deine Fragen eigentlich alle Beantwortet? :-P Vor lauter Geschwafel hab' ich sicherlich was vergessen. Einfach nochmal drauf hinweisen, dann schaffen wir das auch noch.
Gruß Pepi

[stk]

Moin,

Mein Versuch einer Quitessenz. Mein Vorschlag in dem Fall wäre ein echter Server und nicht so ein "Pseudo Server"-NAS Hilfskonstrukt. Erstens kann ein Server auch noch andere praktische Aufgaben erledigen und zweitens ist man dort von der Intelligenz der vorhandenen Software und Protokolle deutliche flexibler. (AFP, SMB, VPN, SSH, rsync, etc.)

Hmmm, gehe ich so weit mit, allerdings sprechen wir a) über einen OS X Server, der eh schon vorhanden ist und gebackupt werden soll und b) über jüngst angeschaffte NAS, die sicherlich nicht ersetzt werden können/sollen. Wird also eher schwierig den Vorschlag zu verkaufen .

Ich backuppe bei einem Kunden von mir mit [FONT="Courier New"]mlbackup[/FONT] mehrere hundert GB zwischen zwei Standorten über Kreuz. Jede Nacht über eine 1Mbit/s Verbindung. (Das initiale Backup habe ich per portabler HD übertragen, die inkrementellen Backups laufen per [FONT="Courier New"]mlbackup[/FONT] jede Nacht problemlos darüber.)

Klingt interessant - vielleicht wäre das eine Alternative für meine "kleineren Kunden", denen ein Online-Backup auf einem Shared OS X Server anzubieten. Ich seh schon … ich muß mal einen Betriebsausflug nach Wien machen … .

… Sepicherbedarf … Menge … Daten … Zeitintervall … nur minimal mehr Speicherplatz …mal testen … Überschlage … Live-Datenbestand … mit … Tagen Multiplizieren … Aufwand …Beispiel … Zeitaufwand: … 72GB … in 60-90 Minuten … Gbit Ethernet … flottes RAID … kein Fehler … drei Stunden … auch egal …

Yep - klingt recht gut, paßt nur noch nicht ganz auf meine Umgebungsvariablen. Aber mal wieder ein Konstrukt das man künftig mitdenken kann.

Leider sehen das nicht alle so, und auch nicht bei kostenloser Software. ich freue mich, daß Du ein gutes Verständnis dafür aufbringst!

Erst recht bei kostenloser Software, erst recht! Wenn man schon nix dafür zahlt/zahlen muß, dann sollte man wenigstens anderweitig dienlich sein - ich hab noch so ein oder zwei Kontakte, wo ich immer wieder gerne mal Rückmeldungen einwerfe. Und sei es als DAU.

Hab ich jetzt Deine Fragen eigentlich alle Beantwortet? :-P

Schon, nur nicht so, wie ich's hören wollte . Ich hab immer noch keine wirklich praktikable Lösung für's Backup via Netzwerk (AFP oder SMB) eines OS X Servers auf ein NAS (i.d.R. mit FAT32/NTFS formatiert). Und auf TimeMachine mag ich nicht warten. Frage daher nochmal in die Runde: wer kennt was brauchbares an Software dafür?

Gruß Stefan

[pepi]

[...]Hmmm, gehe ich so weit mit, allerdings sprechen wir a) über einen OS X Server, der eh schon vorhanden ist und gebackupt werden soll und b) über jüngst angeschaffte NAS, die sicherlich nicht ersetzt werden können/sollen.
[...]
Klingt interessant - vielleicht wäre das eine Alternative für meine "kleineren Kunden", denen ein Online-Backup auf einem Shared OS X Server anzubieten. Ich seh schon … ich muß mal einen Betriebsausflug nach Wien machen … .
[...]
Schon, nur nicht so, wie ich's hören wollte . Ich hab immer noch keine wirklich praktikable Lösung für's Backup via Netzwerk (AFP oder SMB) eines OS X Servers auf ein NAS (i.d.R. mit FAT32/NTFS formatiert). Und auf TimeMachine mag ich nicht warten. Frage daher nochmal in die Runde: wer kennt was brauchbares an Software dafür?
[...]

Dann muß ich mal hinterfragen warum Ihr ohne vorher checken was so ein NAS kann oder was für technische Fähigkeiten explizit für so ein "Offsite-Backup" gebraucht werden so ein NAS angeschafft habt. Ein Firewire RAID und ein Mac mini, oder ein alter G4 hätten es in dem Fall deutlich besser getan vermute ich mal blauäugig ohne das Big Picture genauer zu kennen.

Shared Backup ist natürlich eine Möglichkeit die Du gegen wieviel Geld auch immer anbieten kannst. Mußt Dir nur Gedanken darüber machen wie das mit der Datenmenge und der Bandbreite und dem Traffic bei Dir und bei Deinen Kunden aussieht. Das sollte man nicht unterschätzen.
Falls Du mal in Wien vorbeischneist sag' bescheid, dann gehen wir auf ein "Getränk".

TimeMachine wird Dir bei diesem Problem auch nicht wirklich helfen, da auch TimeMachine Hardlinks verwenden will und entsprechende Zugriffsrechte am Ziel braucht um alle Dateien korrekt abbilden zu können. Du scheiterst genaugenommen nicht an der Backup Software sondern an den mangehaften Fähigkeiten des NAS bzw. des zugrundeliegenden Netzwerkprotokolles oder Filesystems.

Eine etwas naja schräge Lösungsmöglichkeit gäbe es natürlich schon noch. Ich erwähne sie allerdings nur der technischen Vollständigkeit halber und werde Dir diese Vorgehensweise nicht explizit empfehlen! Du könntest am NAS ein beschreibbares .dmg File anlegen (kein SparseImage!) und dieses übers Netzwerk mounten und dann dort in das derart lokal gemountete Filesystem hineinbackuppen. Das wäre in dem Fall die einzige Möglichkeit Hardlinks und Zugriffsrecht entsprechend gewährleisten zu können. Einen Komfortablen Weg, daß Deine User dann auch an die gebackuppten Daten drankommen hast Du dann natürlich nicht.

Für [FONT="Courier New"]rsync[/FONT] muß es übrigens kein Mac OS X Server sein, irgendein Mac mit Tiger (10.4.10) ist da völlig ausreichend.

Der Vollständigkeit noch die Platzbedarfszahlen von meinem [FONT="Courier New"]$HOME[/FONT] Backup (per rsync+ssh, Hardlinks und allem was so Spaß macht.) (Ich habe davon Abstand genommen noch mehr Backups aufzulisten da es wirklich enorm lange dauert so einen Report bei 1.6 Mio Files und Hardlinks je Backupordner zusammenzutragen.)

68G    Pepi-BauxiteBeauty-2007.08.26-03.17.56
1.5G    Pepi-BauxiteBeauty-2007.08.27-01.56.11
1.4G    Pepi-BauxiteBeauty-2007.08.28-02.53.12

Das Initiale (älteste) Backup benötigt also 68GB auf meinem Backuplaufwerk. Die beiden inkrementellen Backups nur jeweils zusätzlich den genannten Speicherplatz.

Als Beispiele hier noch eine Userin die normale Bürotätigkeiten durchführt. (Bestellungen, Verrechnung, eMail, Korrespondenz, Buchhaltung, also grundsätzlich eher textlastige Daten.) 32 Tage Backups des kompletten Home Directories der Userin. Man kann gut einen Tag erkennen wo mal ein bissl mehr Daten angekommen sind. Wenn man diesen einen statistischen Ausrutscher rausrechnet sind wie bei Total 5GB für die 32 Tage.

4.5G    ilse-2007.08.25-04.04.39
 21M    ilse-2007.08.26-04.04.43
 16M    ilse-2007.08.27-04.04.43
 22M    ilse-2007.08.28-04.04.55
 26M    ilse-2007.08.29-04.04.42
 34M    ilse-2007.08.30-04.05.18
 32M    ilse-2007.08.31-04.05.16
 14M    ilse-2007.09.01-04.04.37
 13M    ilse-2007.09.02-04.04.37
 18M    ilse-2007.09.03-04.04.32
 31M    ilse-2007.09.04-04.04.35
 24M    ilse-2007.09.05-04.04.49
 26M    ilse-2007.09.06-04.04.47
 31M    ilse-2007.09.07-04.42.27
 15M    ilse-2007.09.08-04.05.07
 26M    ilse-2007.09.09-04.04.47
 13M    ilse-2007.09.10-04.04.42
 31M    ilse-2007.09.11-04.04.38
 27M    ilse-2007.09.12-04.04.57
 12M    ilse-2007.09.13-04.04.39
 13M    ilse-2007.09.14-04.04.37
 14M    ilse-2007.09.15-04.04.23
 14M    ilse-2007.09.16-04.04.27
 11M    ilse-2007.09.17-04.04.19
 28M    ilse-2007.09.18-04.04.44
1.9G    ilse-2007.09.19-04.04.35
 35M    ilse-2007.09.20-04.04.32
 33M    ilse-2007.09.21-04.04.29
 10M    ilse-2007.09.22-04.04.36
 11M    ilse-2007.09.23-04.04.59
 12M    ilse-2007.09.24-04.04.59
 26M    ilse-2007.09.25-04.05.19
7.0G    total

Zum Vergleich ein SharePoint auf dem ein bissl mehr Daten gelagert werden, wo sich aber auch nicht wirklich viel tut, es sei denn es kommen mal ein paar Fotos von einer Veranstaltung dazu. Der Rest sind auch hier eher Textdokumente. Dieser SharePoint wird hier täglich gbackupped, die Differenzen sind dementsprechend überschaubar.

 92G    Bureau-2007.09.18-04.06.06
 63M    Bureau-2007.09.19-04.07.43
4.8M    Bureau-2007.09.20-04.05.55
8.1M    Bureau-2007.09.21-04.05.47
243M    Bureau-2007.09.22-04.05.53
3.1M    Bureau-2007.09.23-04.06.15
764K    Bureau-2007.09.24-04.06.16
4.4M    Bureau-2007.09.25-04.06.41
 92G    total

Zum Vergleich der selbe Datenbestand hier in einem wöchentlichen Backupzyklus der vom täglichen Backup vollständig entkoppelt ist. Bitte zu beachten, daß ich hiermit Daten bis April 2007 rekonstruieren kann! (Gesamtplatzbedarf, knapp 2x)

 78G    Bureau-Weekly-2007.04.01-05.00.01
4.6G    Bureau-Weekly-2007.04.08-05.00.01
4.8G    Bureau-Weekly-2007.04.15-05.00.01
 37M    Bureau-Weekly-2007.04.22-05.00.01
 34M    Bureau-Weekly-2007.04.29-05.00.01
182M    Bureau-Weekly-2007.05.06-05.00.01
123M    Bureau-Weekly-2007.05.13-05.00.00
5.0G    Bureau-Weekly-2007.05.20-05.00.00
5.0G    Bureau-Weekly-2007.05.27-05.00.01
5.0G    Bureau-Weekly-2007.06.03-05.00.01
5.0G    Bureau-Weekly-2007.06.10-05.00.01
5.0G    Bureau-Weekly-2007.06.17-05.00.01
5.0G    Bureau-Weekly-2007.06.24-05.00.01
8.2G    Bureau-Weekly-2007.07.01-05.00.01
341M    Bureau-Weekly-2007.07.08-05.00.00
 38M    Bureau-Weekly-2007.07.15-05.00.01
1.7G    Bureau-Weekly-2007.07.22-05.00.00
1.5G    Bureau-Weekly-2007.07.29-05.00.01
401M    Bureau-Weekly-2007.08.05-05.00.00
 58M    Bureau-Weekly-2007.08.12-05.00.01
 46M    Bureau-Weekly-2007.08.19-05.00.01
5.4G    Bureau-Weekly-2007.08.26-05.00.01
5.9G    Bureau-Weekly-2007.09.02-05.00.00
295M    Bureau-Weekly-2007.09.09-05.00.01
 19M    Bureau-Weekly-2007.09.16-05.00.01
309M    Bureau-Weekly-2007.09.23-05.00.00
142G    total

Letztes Beispiel ein Datenbestand eines Händlers (Apple und viel Profi Foto Equipment). Daher ein umfangreiches Archiv, sehr Bildlastige Daten, etwas Video.

320G    Daten-2007.09.16-02.00.00
2.0M    Daten-2007.09.17-02.00.00
6.5G    Daten-2007.09.18-02.00.00
504M    Daten-2007.09.19-02.00.01
 54M    Daten-2007.09.20-02.00.00
412M    Daten-2007.09.21-02.00.00
211M    Daten-2007.09.22-02.00.01
1.2G    Daten-2007.09.23-02.00.01
2.0M    Daten-2007.09.24-02.00.00
4.9M    Daten-2007.09.25-02.00.01
329G    total

Ich glaube anhand dieser Beispiele sollte nun wirklich klar sein, daß Du eine Backup-Lösung die entsprechende Filesystem Spezialitäten wie eben konkret Hardlinks nutzen kann in Deinem Fall wirklich sinnvoll einsetzen kannst. Der Geschwindigkeitsvorteil ist bei meinen Backups mit Delta und Hardlinks bis zu einem Faktor 500 schneller als ein entsprechendes Vollbackup. (Bezogen auf lokale Disk to Disk Backups!)
Gruß Pepi