Sequentielles Kopieren großer Datenmengen auf kleine Festplatten ("RAID0 Light")?

[daniel908]

Welches (Backup- / Klon- / Dateimanagement-Programm kann unter macOS große Datenmengen auf kleinere Festplatten kopieren, und zwar so, dass es jedesmal pausiert, wenn eine Festplatte voll ist, so dass man eine neue Festplatte anschließen und das Kopieren dann fortsetzen kann?

Quasi ähnlich wie ein RAID0 ohne Striping und mit seriellem statt parallelem Anschließen der Festplatten

Eine Funktion zum inkrementellen Aktualisieren des Backups (wohl mittels einer Datenbank, die trackt, was auf welcher Festplatte gespeichert ist, und Änderungserkennung auf der Quelle) wäre dann noch das i-Tüpfelchen, ist aber kein Muss, da ich diesen Vorgang nur ca. einmal pro Jahr mache und dann kann ich auch eine komplette Kopie machen.

Usecase: Ich möchte ein Backup von knapp 24TB Daten auf 6 Stück 4TB-Festplatten erstellen, so dass ich an die Daten später ggf. wieder leicht herankomme, ohne dass ich einen RAID-Controller benutzen muss und ohne das Risiko des kompletten Datenverlustes, wenn eine der Platten ausfällt. Und ohne Geldausgabe für einen weiteren RAID-Controller und eine Redundanz-Platte

Ich möchte auch vermeiden, dass ich selbst die Daten auswählen muss, die ich jeweils auf diese Festplatten kopiere.
Ich kenne solches Kopieren noch aus MS-DOS-Zeiten, wenn man "größere" Datenmengen auf Floppy-Disks kopiert hat. Ich glaube, damals ging sowas mit "xcopy". Daher hoffe ich, dass es das auch heute noch gibt.

 

[Wuchtbrumme]

xcopy hatte keinerlei Intelligenz zur Auswahl wie Du sagst.

Ein RAID0 ohne striping ist kein RAID0 und seriell statt parallel hat erst recht verwirrt, ich glaube aber, dennoch verstanden zu haben, was Du suchst.

Eine Software kenne ich nicht, ich meine nur, dass verschiedene Zipper das können (ein gegebenes Set an Files auf verschiedene Zieldatenträger aufteilen). Weiss aber nicht, ob die ein Archiv machen oder mehrere: je nach ZIP-File-Typ müssen alle Teile eines Archivs vorliegen, um jedes beliebige File extrahieren zu können, was gegen Deine Anforderung spricht. Aber es mag tolerantere Formate geben oder Zip-Programme, die die Archive einzeln erstellen.

Wahrscheinlich liesse sich das auch über die shell scripten. Vielleicht gibt es auf github Projekte dazu? Würde mich auch interessieren.

 

[daniel908]

Entschuldigung, wenn ich dich mit meinen Vergleichen verwirrt habe. Eigentlich sollten sie eher die Idee noch klarer machen.
Dass es kein RAID0 *ist* ist ja klar, daher schrieb ich ja "ähnlich wie...".

Zipper - das ist 'ne Idee. Ist natürlich dann wieder verkapselt, so dass ich nicht direkt übers Dateisystem an die Dateien herankomme. Aber vielleicht ist das ein Ansatz.

Über ein bash-Skript habe ich auch nachgedacht, mir ist aber keine Idee gekommen, wie das realisierbar wäre.
Außer vielleicht...
Eine for-Schleife über den output von "find", so dass jede Datei einzeln kopiert wird, und wenn das Kopieren fehlschlägt, weil die Platte voll ist, macht das Skript eine Pause und wartet aufs Fortführen. Dann müsste man aber wohl sicherstellen, dass die neue Platte im selben mountpoint eingehängt ist wie die alte, was bei macOS ja vom Volumen-name abhängt. Also müsste man sicherstellen, dass alle Festplatten denselben Namen haben.
Aber: Gibt es einen copy-Befehl, der die notwendige Verzeichnisstruktur gleich mit anlegt, wenn man nur eine Datei kopiert?

 

[FrankR]

Mit GNU tar sollte sowas machbar sein - siehe auch https://www.gnu.org/software/tar/manual/html_node/Multi_002dVolume-Archives.html. Ist aber schon über ein Jahrzehnt her, dass ich das mal in der Praxis genutzt habe (damals unter Linux mit Backup auf mehrere LTO Tapes). Wäre aber dann auch wieder "verkapselt" - d.h. wenn man da wieder an ein File aus dem Backup ran muss, muss man da sequentiell über die Platten gehen. Den "Volume Wechsel" müsste man wohl über das Script welches über die Kommandozeile angegeben werden kann, realisieren - alles etwas tricky und das ist nicht gerade das, was ich für ein Backup bevorzugen würde.

Am Saubersten wäre wahrscheinlich da selbst was zu programmieren, was die Dateien 1:1 kopiert und vor jeder Datei prüft, ob der Platz auf dem Ziel-Volumen noch ausreicht und wenn nicht zum Wechsel des Volumes auffordert - wenn Du nicht viel Programmiererfahrung hast, ist das aber eher nicht trivial.

 

[Wuchtbrumme]

falls es darum geht, ein NAS zu sichern, gibt es auch Backupfunktionen in besseren NAS, die blockweise auf ein anderes NAS sichern können.

Wenn man ganz schlicht an die Sache herangeht und einfach manuell Kopien z.B. übers Netzwerk auf diese unterschiedlichen Backuplaufwerke erstellt (wobei man ja relativ einfach pi mal Daumen größenmäßig passende Konvolute erstellen kann), dann könnte man mit NeoFinder den Inhalt aller Laufwerke indizieren. NeoFinder hat eine komfortable Suche und teilt einem dann mit, auf welchem der Laufwerke diese Datei in Original und Kopie zum Zeitpunkt des Snapshots war. NeoFinder ist ohnehin eine Empfehlung wert, das kann jedes Laufwerk indizieren, sofern es nur ein unterstütztes Dateisystem hat. Auch ZIP-Files können durchsucht werden und für eine Vielzahl von Dateien werden Metadaten (Videos, Fotos, ...) gesammelt und sind ersuchbar.

Es gibt aber Gründe, spezialisierte Software zu benutzen, die nach dem Schreiben auch z.B. mittels Hash (md5) oder überhaupt Binärvergleich feststellen, ob Kopie und Original identisch sind. Vor 20 Jahren noch konnte man das Problem haben, dass durch Bitfehler alleine auf dem Weg zur Festplatte Dateien zerstört wurden. BTDT. Das ist zum Glück zurückgegangen, SATA sei dank, aber wenn der Rechner auf dem RAM unerkannte Bitfehler hat, dann beeinflusst das das ganze System.

Müßte ich mich ans Skripten machen, würde ich vermutlich gucken, welche zu sichernden Verzeichnisse zusammen wie am besten auf jedes einzelne Laufwerk passen. So einen Algorithmus in Bash abzubilden um das automatisch hinzubekommen würde ich mir nicht zutrauen. Aber wenn man damit einen Satz an Backupverzeichnissen zusammengestellt hat, kann man das einfach als Skript mit rsync oder tar abfeuern.

 

[MacAlzenau]

Nur als Hinweis: es gibt bei MacUser einen Thread zur identischen Fragestellung.
Ich mein nur... bevor sich jemand viel Mühe und Gedanken macht, vielleicht mal schauen, ob der gleiche Vorschlag schon mal gemacht wurde und nicht gefallen hat.
Ist ja absolut kein triviales Problem.