LTO4 reale Geschwindigkeit

lokal sollte das an sich kein Problem sein,
Wir sichern mit LTO3 ca. 476 GB in ca. 5 Std. übers Netzwerk
Der Rest hängt von der Festplatte und der Software ab.

576 GB/pro Stunde macht bei Deiner Datenmenge doch gerade mal eine halbe Stunde, oder? Wenn deine Platten SataII oder SCSI sind, sollte das ganze nicht länger als eine Stunde dauern.

Gruß, Arch Stanton

Hi
du solltest dazu sagen welche Datenarten du hast:
Beispiel: eine 15k HD kann 120GB Daten/s holen WENN die Daten groß sind. Hast du einen Webserver mit seinen kB großen Daten zu sichern oder ein cvs Repo dann kannst du mit wenigen MB/s rechnen (Was LTO4 selbst im langsamsten Modus zu wenig ist und skipping eingelegt wird). Wenn du durchschnittliche Filegrößen (treesize pro) im oberen MB hast dann sollte dein LTO zufrieden sein. Beim ersten Beispiel bietet sich ein Dump an (vorher Dir zu einer großen Daten (zippen) und dann diese sichern. Latenzen können beim Netz noch relevant sein, aber mit Gigbit sollte das gehen. Wie gesagt ist die durchschnittliche Filegröße da relevant. Bei uns lief z.B. monatelang ein Backup pro Nacht an einem 9GB großen cvs Repo (bestand aus etwa 5Mio Dateien) für etwa 6h; das Band und Streamer das mitmachten war ein Wunder. Nach einem kurzen 7zip Skript wurde das Verzeichnis ausgenommen, ein dump mit ntbackup (ACLs gehen sonst verloren) und danach komprimieren. Nun dauerte das gesamte nur noch 2.5h und der Streamer hatte eine 2GB Datei zu sichern in wenigen Sekunden.

Gruß
Sam

Dann rechne doch mal Gesamtdatenmenge/Anzahl=Durchschnittsgröße; nach den Angaben bisher hast du 250GB/600k=410kB/Datei. Das bedeutet das dein Array/Volumen/HD/.... für einen kont. Datenstrom bei LTO4 (vermute du hast ein billigeres HalfHeight Laufwerk) von 80MB/s (die werden ja noch komprimiert) [das ist bei den HH Laufwerken afair die drittschnellste Datenrate auf die sie runterfahren können] bereits min 200 Zugriffe benötigst, also 5ms. Das ist schon ganz ordentlich selbst für 15k HDs. Und das erlaubt noch keine großen Latenzen oder Fragmentierung. Ich habe in meiner Arbeit ein Volumen mit 23TB Daten und einer durchschnittlichen Dateigröße von 3.2MB. Die Volle Monatssicherung dauert bei uns auch knapp 2d obwohl vier Roboter mit LTO4 dran arbeiten. Das ist zwar eine ganz andere Größe als bei dir, aber durch die 8 mal größere Durchschnittsmenge kann ich sowas noch durchbekommen (die architektur startete vor 5 Jahren mit der ungefähr selben Durchschnittsgröße und 400GB und zwei LTO2); da war das Backup in zwei Stunden durch; erst mit den kleinen Files (cvs, Apache und wiki) vor drei Jahren wurde das ein Spaß; die großen Dateien sind da eine wahre Wohltat obwohl sie den Größenanteil ausmachen.
Gruß
Sam

Hi
wenn du ein unfragmentiertes System mit "einer" 15k HD hast und nichts sonst auf dem System zugreift dann kannst du die 80MB/s kriegen ja. Ich kenne ja dein System darunter nicht. Sofern du ein fragmentiertes RAID5 mit 7k2 HDs hast kannst du evtl mehrere Stunden dafür brauchen. 80MB/s ist der drittschnellste Speed den diese LTO4 HH Laufwerke können und mit denen sie ja befüttert werden müssen. Du kannst ja mal nach LTO und skipping im google suchen da findest du sicher nette Berichte dazu. Jedes DLT braucht einen minimum Datenstrom. Um dies zu gewährleisten können ab LTO2 die Laufwerke die recht hohe Datenrate reduzieren um skipping zu vermeiden. Die Fullhigh Laufwerke nehmen das wesentlich besser auf als deren HH pendants. Die niedrigste Rate ist bei LTO4 afair irgendwo bei 5MB/s (siehe doku zum Laufwerk). Das klingt viel aber wenn du so ein normales 10k Laufwerk hast kann es bei 130 Zugriffen pro Sekunde (=130 IOPS) bereits erschöpft sein; wenn du viele kleinstdateien im untersten kB Bereich hast (wie meine Apache, wiki, cvs Dateien) dann schaffst du trotz der guten 130 Zugriffe nur wenige hundert kB/s. Dann beginnt das Skipping. Gerade die billigen HH Laufwerke hatten wir schon zahlreiche zerschrottet dadurch. Storage ist eine eigene Wissenschaft für sich, die aber recht einfach durchschaubar ist. Als Admin (ich betreue auch nur fette Server keine Storages im SAN Sinne) sollte man zumindest mal die Eckdaten kennen und wissen was wichtig ist.

Dein Storage sollte halt zum Backup passen, bzw umgekehrt.

Hi Marco
dann solltest du schnell was dagegen tun! Wenn das Band (jede Tapetechnik) nicht mit seiner min Geschwindigkeit betankt wird, dann beginnt er das sog. Skipping (Google oder wikipedia); das Laufwerk (hoffe du hast das gute FullHigh Laufwerk) und Bänder gehen da ratzt fatz kaputt (ist wie ein Auto das nur Vollstart und Vollbremsung kennt. Bei dir wird sich ein file Dump anbieten, sprich vorher von dem System State ein Image ziehen (zip, ntbackup auf file, ...) dann geht es ohne; auch die 1.5h sind schon verdächtig. Siehe meine letzte Mail vom 14.7; das Problem geht mit kaputten Bändern schnell ins Geld und gerade unsere HalfHigh Laufwerke waren monatlich defekt (Hersteller konnte uns dann nachweisen das wir es unsachgemäß behandelt haben und seither liegen zwei IBM LTO4 HH Laufwerke hier rum; leider werde ich als Supporter immer erst gerufen wenn's gekracht hat....)
Gruß
Sam

Hi
Deine 72MB/Min sind viel zu wenig (=1.3MB/s und rund 5MB unkomprimiert sidn das absolute Min; daher dauert dein Backup auch so lange; wenn du mal dabei bist hörst du deutlich das Skipping), UND du hast die Schrott HalfHigh Laufwerke; Skipping macht das Band weil es nur bestimmte Bandgeschwindigkeiten kann und wenn du deren Speed unterschreitest geht das Laufwerk auf Full Stop spielt zurück und wieder dort wo aufgehört wurde; selbst bei einmal die Woche kannst du doch einen Dump im Hintergrund ziehen; mit Snapshot Techniken umso einfacher; da es ja auf die Dateien im Hintergrund zugreift hast du nicht mal eine Downtime; unser Backup (auch BE10.1) arbeitet nur mit Dumps; damit ist der Server 24/7 voll verfügbar und ich habe doch einen täglichen 21Uhr Snapshot; ist Im Advanced Disk Backup bzw File Open mit dabei. Da ich deine Umgebung ja nur ansatzweise kenne kann ich deine Aufgabe nur ansatzweise nachverfolgen, doch bis dato gab es immer Lösungen für alles
Gruß
Sam