Problem mit der Kapazität von Backup-Bändern
Hi Leute,
ich habe hier einen Linux-Rechner auf dem Yosemite Server Backup 9.1.01 läuft.
Zum Einsatz kommt ein HP Streamer, der LTO 1 Bänder mit einer unkomprimierten Kapazität von 100GB "schluckt".
Diese Bänder zeigt das System mit knapp 98GB an - so weit, so gut.
Die tatsächlich auf die Bänder geschriebene Datenmenge beträgt normalerweise ca. 140GB. Dabei wird dann eine Restkapazität von ca. 10 GB angezeigt.
D.h. die Daten werden vor dem Schreiben komprimiert.
Da relativ viele Bild-Dateien auf der Platte sind, hält sich die Quote in Grenzen...
Nun habe ich 2 Bänder (identischer Typ wie der Rest, 100GB netto - angezeigt ebenfalls 98GB), auf die jeweils nur ca. 125GB geschrieben werden können. Dann verbleiben noch ca. 60MB Rest.
Die Auswahl für das Backup ist identisch. Am Tag vorher und am Tag nachher mit anderen Bändern funktioniert alles problemlos...
Sind da eventuell "Bad Blocks" auf dem Band? Müssten die aber nicht bei der Gesamtkapazität berücksichtigt werden?
Inzwischen habe ich einige der Bänder gegen neue, frisch aus der Verpackung ersetzt. Auch diese Bänder werden mit 98GB Kapazität im System angezeigt.
Das Backup vom Freitag wurde bei diesmal ca. 119GB gesicherten Daten und noch ca. 3000 fehlenden Objekten abgebrochen - mir der Meldung, die Kapazität sei erschöpft.
Ciao
dirk
ich habe hier einen Linux-Rechner auf dem Yosemite Server Backup 9.1.01 läuft.
Zum Einsatz kommt ein HP Streamer, der LTO 1 Bänder mit einer unkomprimierten Kapazität von 100GB "schluckt".
Diese Bänder zeigt das System mit knapp 98GB an - so weit, so gut.
Die tatsächlich auf die Bänder geschriebene Datenmenge beträgt normalerweise ca. 140GB. Dabei wird dann eine Restkapazität von ca. 10 GB angezeigt.
D.h. die Daten werden vor dem Schreiben komprimiert.
Da relativ viele Bild-Dateien auf der Platte sind, hält sich die Quote in Grenzen...
Nun habe ich 2 Bänder (identischer Typ wie der Rest, 100GB netto - angezeigt ebenfalls 98GB), auf die jeweils nur ca. 125GB geschrieben werden können. Dann verbleiben noch ca. 60MB Rest.
Die Auswahl für das Backup ist identisch. Am Tag vorher und am Tag nachher mit anderen Bändern funktioniert alles problemlos...
Sind da eventuell "Bad Blocks" auf dem Band? Müssten die aber nicht bei der Gesamtkapazität berücksichtigt werden?
Inzwischen habe ich einige der Bänder gegen neue, frisch aus der Verpackung ersetzt. Auch diese Bänder werden mit 98GB Kapazität im System angezeigt.
Das Backup vom Freitag wurde bei diesmal ca. 119GB gesicherten Daten und noch ca. 3000 fehlenden Objekten abgebrochen - mir der Meldung, die Kapazität sei erschöpft.
Ciao
dirk
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 192742
Url: https://administrator.de/forum/problem-mit-der-kapazitaet-von-backup-baendern-192742.html
Ausgedruckt am: 10.05.2025 um 06:05 Uhr
11 Kommentare
Neuester Kommentar
Hi.
Du musst bei der Berechnung der Backupmenge immer von der Netto Kapazität der Bänder ausgehen. Alles andere ist Glücksache.
LG Günther
Du musst bei der Berechnung der Backupmenge immer von der Netto Kapazität der Bänder ausgehen. Alles andere ist Glücksache.
LG Günther
Ich habe identische Bänder (100GB Netto) und weitgehend identische Daten (ca. 140GB) auf 10 von derzeit 13 Bänder passt alles drauf - auf momentan 3 Bänder nicht.
DAS ist es, was ich nicht verstehe...
Ciao
dirk
DAS ist es, was ich nicht verstehe...
Ciao
dirk
Moin,
Der Hersteller garantert Dir 100GB was abzüglich Overhead 98GB ergeben kann.
Da die Bänder heutztage mit sehr hohen Dichten arbeiten und daher Fehlerfreiheit nur innerhalb gewisser Grenzen erreicht werden kann, bauen die da eine Puffer ein, damit auch unter ungünstigen Umständen 100GB erreicht werden.
Wenn Du mehr bekommst freu Dich.
wenn der Platz nciht reicht, kauf Dir größere Bandkapazitäten.
lks
PS: Das ist wie mit den Disketten früher. Die konnte man lochen und die Rückseite benutzen. Kein Hersteller hat Dir aber garantiert, daß das tatsächlich funktioniert, außer bei denen, die explizit als DS ausgewiesen waren.
Der Hersteller garantert Dir 100GB was abzüglich Overhead 98GB ergeben kann.
Da die Bänder heutztage mit sehr hohen Dichten arbeiten und daher Fehlerfreiheit nur innerhalb gewisser Grenzen erreicht werden kann, bauen die da eine Puffer ein, damit auch unter ungünstigen Umständen 100GB erreicht werden.
Wenn Du mehr bekommst freu Dich.
wenn der Platz nciht reicht, kauf Dir größere Bandkapazitäten.
lks
PS: Das ist wie mit den Disketten früher. Die konnte man lochen und die Rückseite benutzen. Kein Hersteller hat Dir aber garantiert, daß das tatsächlich funktioniert, außer bei denen, die explizit als DS ausgewiesen waren.
Zitat von @Lochkartenstanzer:
Der Hersteller garantert Dir 100GB was abzüglich Overhead 98GB ergeben kann.
Da die Bänder heutztage mit sehr hohen Dichten arbeiten und daher Fehlerfreiheit nur innerhalb gewisser Grenzen erreicht
werden kann, bauen die da eine Puffer ein, damit auch unter ungünstigen Umständen 100GB erreicht werden.
Der Hersteller garantert Dir 100GB was abzüglich Overhead 98GB ergeben kann.
Da die Bänder heutztage mit sehr hohen Dichten arbeiten und daher Fehlerfreiheit nur innerhalb gewisser Grenzen erreicht
werden kann, bauen die da eine Puffer ein, damit auch unter ungünstigen Umständen 100GB erreicht werden.
Ja, da habe ich auch kein Problem mit.
Wenn Du mehr bekommst freu Dich.
Mehr ist bei komprimierbaren Dateien kein Problem, da im Laufwerk hardware-komprimiert wird.
wenn der Platz nciht reicht, kauf Dir größere Bandkapazitäten.
Darum geht es nicht.
Es geht darum, dass die Backups der (sich nur unwesentlich ändernden Platte) mal auf die Bänder passen und mal nicht.
WENN sie draufpassen, gibt die Backupsoftware eine verbleibende Restkapazität von 10GB an.
Beispiel:
Montag - passt, 139GB gesichert, 9.8 GB Rest
Dienstag - passt nicht, 129GB gesichert,Band voll
Mittwoch - passt, 139GB gesichert, 9.9 GB Rest
Wenn beim Montagsbackup das Band zu 99% voll wäre und dann am Dienstag so viele Daten dazukommen, dass die Kapazität überschritten wäre, würde ich das ja noch verstehen - aber dann würde es am Mittwoch auch nicht funktionieren.
PS: Das ist wie mit den Disketten früher. Die konnte man lochen und die Rückseite
benutzen. Kein Hersteller hat Dir aber garantiert, daß das tatsächlich funktioniert,
außer bei denen, die explizit als DS ausgewiesen waren.
benutzen. Kein Hersteller hat Dir aber garantiert, daß das tatsächlich funktioniert,
außer bei denen, die explizit als DS ausgewiesen waren.
Nein, dass ist was anderes.
HP sagt, dass auf das Band in dem Laufwerk zwischen 100GB und 200GB draufpassen, je nach dem wie stark sich die Daten komprimieren lassen...
Ciao
dirk
Nein, dass ist was anderes.
HP sagt, dass auf das Band in dem Laufwerk zwischen 100GB und 200GB draufpassen, je nach dem wie stark sich die Daten komprimieren
lassen...
HP sagt, dass auf das Band in dem Laufwerk zwischen 100GB und 200GB draufpassen, je nach dem wie stark sich die Daten komprimieren
lassen...
Due vermischt da zwei Sachen. Einmal die kapazität, die sehr stark von den Daten abhängt. Das können zwar jedesmal die gleichen Daten sein, aber zumidenst die verwaltungsdaten sind jedesmal anderes, so daß die Komprimierung ganz anders sein kann.
Und das sind die Nettodaten, d.h die reale Roh-(Netto-)Datenmenge die aufs Band paßt! Und die kann je nach Bandlänge variieren. Du hast nur die garantie für 100GB. Du hast nur die Garantie, daß 100GB draufpassen. Alles weitere ist nur "Glück". Wenn Du als sichergehen willst, daß deien Daten draufpassen, mußt Du ein Laufwerk nehmen, das als Rohdatenmenge mindestens Deine Datenmenge frißt.
Bei Deinem beispiel oben mit Mo/Di/Mi ist es ganz eindeutig so, daß aus irgendeinem grund die Komprimierung nicht wie an den beiden anderen tagen war und Du deshalb Pech hattest. Das kann an den leicht veränderten Daten liegen. Das kann an den Bandeigenschaften liegen, das kann aber auch mal "Wetter" liegen, z.B. daß die Kompromierungsfimrware einen Bug hat, der nur in bestimtmen Situationen getriggert wird. etc.
Tatsache ist: Wenn Du garantierte Kapazitäten brauchst, mußt Du auch Backup-Systeme verwenden, die diese gewährleisten. Alles andere ist Glücksspiel.
Glaub mir, das habe ich bei Kuden oft genug durchexerziert.
lks
Es kommt auch noch hinzu, daß die optimale Kapazität nur im Streaming-Modus erreicht wird.
D.h. es müssen durchgehend genügend Daten ans Laufwerk gehen, damit es weiterschreiben kann.
Wenn die Daten ausgehen, wird ein Marker aufs Band geschrieben und wieder angesetzt, wenn wieder Daten kommen.
Diese Marker brauchen auch Platz. Und wenn man nur langsame Datenquellen hat, dann können da schnell viele Marker zustandekommen.
D.h. es müssen durchgehend genügend Daten ans Laufwerk gehen, damit es weiterschreiben kann.
Wenn die Daten ausgehen, wird ein Marker aufs Band geschrieben und wieder angesetzt, wenn wieder Daten kommen.
Diese Marker brauchen auch Platz. Und wenn man nur langsame Datenquellen hat, dann können da schnell viele Marker zustandekommen.
Zitat von @AndreasHoster:
Es kommt auch noch hinzu, daß die optimale Kapazität nur im Streaming-Modus erreicht wird.
Es kommt auch noch hinzu, daß die optimale Kapazität nur im Streaming-Modus erreicht wird.
o.K. Daran habe ich nciht gedacht. Es braucht nur an dem tag ein anderer Job gleichzeitig zu laufen, der den Backup-Job ausbremst, weil er auf die gleichen Daten zugreift. Und schon hast Du verloren, weil das Tape nur noch Stop-and-Go spielt.
Wie lange dauern denn die jeweiligen Backups an den Tagen?
lks
Erfolgreiches Backup am 11.10. - 131,2GB - 3:47:43h
Erfolgreiches Backup am 10.10. - 131,1GB - 3:52:22h
Fehlgeschlagenes Backup am 9.10. - 113,0GB - 1:50:45h
OK - irgendwas stimmt da nicht. Aber nicht in der vermuteten Richtung...
Das fehlgeschlagene Backup am 4.10. waren 125,9GB in 3:07:06h - was auch schneller wäre als bei den erfolgreichen Backups.
Gleiches z.B. am 7.9.: 117GB in 2:40:16h
Wenn das ja alles am gleichen Wochentag wäre - ist es aber nicht...
Die Suche nach automatischen Updates beginnt erst Nachts um 2:00. Dann läuft höchstens noch der Vergleich des Backups mit den Daten auf der Platte.
Ciao
dirk
Um zu testen, ob es evtl. am Band liegt, habe ich das gestrige Backup aufs gleiche Band schreiben lassen, wie das fehlgeschlagene Backup am 9.10.
NAch 3:45:21h kam die Meldung, dass die maximale Kapazität erreicht sei - bei 126,5GB...
Nun ja - ich werde wohl mal schauen, dass ich die Menge der zu sichernden Daten verringere...
Ciao
dirk
NAch 3:45:21h kam die Meldung, dass die maximale Kapazität erreicht sei - bei 126,5GB...
Nun ja - ich werde wohl mal schauen, dass ich die Menge der zu sichernden Daten verringere...
Ciao
dirk
Hallo diwaffm,
wie wäre es wenn Du das Backup aufteilst? Du kannst doch das Backup leicht mit einem RDX Laufwerk ergänzen.
Diese Laufwerke kosten nicht die Welt und dann kannst Du den Backup Job einfach "splitten", denn jetzt
herzugehen und einfach weniger zu sichern ist auch nicht so richtig die Krone der Weisheit. Klar kosten die
RDX Medien eine Menge mehr Geld als die Bänder, aber wenn Du beides kombinierst, dann hast Du auf jeden Fall
alles gesichert und noch "Luft" nach oben hin.
Gruß
Dobby
wie wäre es wenn Du das Backup aufteilst? Du kannst doch das Backup leicht mit einem RDX Laufwerk ergänzen.
Diese Laufwerke kosten nicht die Welt und dann kannst Du den Backup Job einfach "splitten", denn jetzt
herzugehen und einfach weniger zu sichern ist auch nicht so richtig die Krone der Weisheit. Klar kosten die
RDX Medien eine Menge mehr Geld als die Bänder, aber wenn Du beides kombinierst, dann hast Du auf jeden Fall
alles gesichert und noch "Luft" nach oben hin.
Gruß
Dobby
Zitat von @108012:
wie wäre es wenn Du das Backup aufteilst? Du kannst doch das Backup leicht mit einem RDX Laufwerk ergänzen.
wie wäre es wenn Du das Backup aufteilst? Du kannst doch das Backup leicht mit einem RDX Laufwerk ergänzen.
Also wenn aufteilen, dann auf ein zweites LTO1 Laufwerk, was ich noch im Keller habe.
Allerdings weiß ich nicht, wie sich YSB in der Richtung verhält.
Vor Jahren habe ich das mal mit Commvault Galaxy gemacht - da klappte das eigentlich ganz gut
ciao
dirk
