Beim Testen von HDDs und SSDs ist mir aufgefallen, das sie immer langsamer werden, zumindest bei Schreib-Lesetests wie badblocks -wsv /dev/sdb Bei einer Quantum LP52S 950509405, 52,3 MB, SCSI, von circa 1990 und mit einem Aufkleber zu 1988, zeigte sich eine Testdauer von 8 m 37 s, also 517 s. Für die insgesamt 8 Durchgänge (Testmuster 0xaa, 55, ff, 00) ergibt das eine mittlere Transferrate von 52,3 MB * 8 / 517 s = 0,81 MB/s. Bei 25 Jahre später aktuellen, relativ großen und relativ schnellen HDDs zeigt sich eine mittlere Transferrate um 150 MB/s bei einer Größe von 8 TB. Das macht rund 150fache Transferrate bei rund 150.000facher Größe, folglich die rund 1000fache Schreib-Lesetest-Dauer! Das Bedeutet in der Praxis für einen Schreib-Lesetest mit den üblchen 4 Durchgängen, die auch zur Auffrischung der Magnetisierung empfehlenswert sind, das der Test nicht mehr eine kurze Kaffepause oder Rauchpause dauert sondern 5 Tage, eine ganze Arbeitswoche! Tests mit SSDs von vor 25 Jahren konnte ich nicht machen, aber der Trend ist dort gleich: Schreib-Lesetests dauern immer länger, im Mittel plus 32 % pro Jahr. Und auch bei SSDs zeigten sich hier einige Exemplare mit Lesefehlern, die durch einen Schreib-Lesetest beseitigt werden, so das auch bei SSDs aufgefrischt werden sollte, wobei es bei SSDs elektrische Ladungen statt Magnetisierungen sind.
Rolf F. schrieb: > Tests mit SSDs von vor 25 Jahren konnte ich nicht machen, aber der Trend > ist dort gleich: Schreib-Lesetests dauern immer länger, im Mittel plus > 32 % pro Jahr. glaube ich nicht. Du hast vermutlich nur an einer SATA-Schnittstelle gemessen - das ist schon nicht mehr aktuell. SSDs können weiter mehr als 1GB/s liefern - wenn es die Schnittstelle hergibt.
Rolf F. schrieb: alt > ergibt das eine mittlere Transferrate von 0,81 MB/s. neu > zeigt sich eine mittlere Transferrate um 150 MB/s Das passt aber absolut nicht zu Deinem reisserischen Titel. Du vergleichst ungleiche Datenmengen, einen Swimmingpool mit dem Feuerwehrschlauch füllen dauert auch länger als ein Glas aus dem Wasserhahn, ist ein Pool jetzt schlechter als ein Glas?
Bei SSD's kannst du heute aber nicht mehr sicher sein, dass die logischen Blocks den Physikalischen Blocks entsprechen. Da kommt ein spezieller Algorithmus zum Einsatz, der das intelligent verteilt, so dass die Blocks gleichmäßig beschrieben werden. Und ob damit die Zellen 'aufgefrischt' werden steht auf einem anderen Blatt.
So wie ich das verstanden habe benutzt du das Verhältnis von Schnittstellen-Transferrate zu Kapazität als Maßeinheit. Da die Kapazität schneller wächst als die Transferrate werden Speichermedien tatsächlich "langsamer". Aber "Transferrate/Kapazität" ist IMHO keine praxisrelevante Größe. Es gibt halt an, wie schnell man eine Platte komplett voll schreiben oder komplett auslesen kann (als Kehrwert). Deswegen sind Schreib- und Lesetests der kompletten Platte auch nicht mehr relevant. Bei der Seagate Archive V2 8TB hast du laut Datenblatt etwa einen Lesefehler pro 10E14 Bits. Die Platte hat 8*8*10E12 = 6.4E13 Bits. Da ist es mittlerweile also wahrscheinlicher, bei einer gesunden Platte einen Fehler zu finden, als keinen Fehler zu finden*. Da hilft dann nur zusätzliche Redundanz auf Dateisystemebene oder mit einem RAID oder, wie bei ZFS, mit einer Mischung daraus. *Nochmal, weil es so wichtig ist: Bei einer gesunden 8TB-Platte sind Lesefehler beim Kompletttest statistisch die Regel, nicht die Ausnahme! Gruß Konrad
> 150fache Transferrate bei rund 150.000facher Größe
Also ich finde 150 fach und 50.000 fach bei 1/10 des Preises Klasse!
Das Problem ist doch nicht die Zeit für badblocks.
Das Problem ist: die Platten sind zu billig geworden. Wenn voll kaufe
ich 2TB dazu. Und nach ein paar Jahren finde ich nichts mehr.
Rolf F. schrieb: > Das macht rund 150fache Transferrate bei rund 150.000facher Größe, > folglich die rund 1000fache Schreib-Lesetest-Dauer! Abgesehen davon, dass der Titel des Threads eine komplett andere Aussage beinhaltet, stimmt Deine Feststellung zumindest größenordnungsmäßig. Und was willst Du damit aussagen? Dass früher alles besser war? Oder dass alle doof sind außer Mutti? Wir müssen uns doch nur anschauen, welche Einfluss die wichtigsten Parameter auf die die Kapazität und Übertragungsrate *zwischen dem nackten Datenträger und der angeschlossenen Elektronik" haben: 1. Datendichte der einzelnen Magnetscheibe Eine Erhöhung der Datendichte bewirkt, dass zum einen mehr Daten pro Spur und zum anderen mehr Spuren pro Plattenstapel untergebracht werden können. Mehr Daten pro Spur führen zu einer proportionalen Erhöhung der Datenrate, sollten also keine Verschlechterung der relativen Übertragungsraten bewirken. Die Spuren pro Plattenstapel (z.B. Zylinder) können aber nur nacheinander ausgelesen werden. Bei der gleichen Zahl von Köpfen pro Spur skaliert also die Übertragungsraten umgekehrt proportional zur Spurdichte. 2. Köpfe pro Scheibe Früher gab es einige Hersteller, die Festplatten mit mehreren unabhängig voneinander beweglichen Kopfträgern herstellten. Das hat sich jedoch als äußerst fehleranfällig und teuer erwiesen. Solche Festplatten konnten natürlich theoretisch ihre Übertragungsraten vervielfachen. Auf Grund des hohen Aufwandes kamen sie aber nur im Großrechnerbereich zum Einsatz. 3. Anzahl der Scheiben Da die Scheiben (genauer: Oberflächen) eines Stapel simultan gelesen/geschrieben werden können, erhöht sich die Übertragungsraten mit der Zahl der Oberflächen. Heutzutage müssen Festplatten aber möglichst dünn sein, um sie z.B. in Notebook einsetzen zu können, was die Zahl der Schreiben/Oberflächen reduziert. In der "Hochphase" gab es aber dicke Briketts mit locker zwanzig Scheiben. Neben der Dicke gibt es aber auch noch einen anderen wichtigen Grund, die Zahl der Scheiben zu begrenzen: die thermische Ausdehnung. Auf Grund der deutlich geringeren Spurdichten konnte man früher davon ausgehen, dass die Köpfe aller Oberflächen gleich gegenüber den Spuren ausgerichtet waren und deswegen nur eine Oberflächen die Servoinformationen tragen musste. Bei noch älteren Platten entsprach der Spurabstand sogar der festen Schrittweite des Schrittmotors, der zur Kopfträgerpositionierung eingesetzt wurde. Da heutzutage aber die Spurdichten so hoch sind, dass die Positionsregelung für die jeweils aktive Oberfläche separat erfolgen muss, kann man nicht mehr über möglichst viele Oberflächen die Übertragungsrate erhöhen. Ganz im Gegenteil würde die Übertragungsrate heute mit zunehmender Oberflächenzahl sogar sinken. Neben der o.a. thermischen Ausdehnung müssen heutzutage auch akustische Störungen ausgeregelt werden. 4. Drehzahl Die Übertragungsraten skalieren natürlich linear mit der Drehzahl des Plattenstapels. Aus rein mechanischen Gründen ist man aber schon recht lange am technisch sinnvollen Maximum von ca. 10.000 Upm, bei weniger sehr teuren Serverplatten 15.000 Upm angelangt, also etwa einer Verdreifachung gegenüber früher. Da ist also nichts mehr an Geschwindigkeit herauszuholen. 5. Positioniergeschwindigkeit Früher lag die typischen Spurwechselzeit bei 40ms bis 65ms, heutzutage bei 4ms. Da jedoch die Anzahl der Spuren weit überproportional angestiegen ist, benötigt das Durchklackern aller Spuren ein Vielfaches des damals üblichen Zeit.
Konrad schrieb: > Aber "Transferrate/Kapazität" ist IMHO keine praxisrelevante Größe. Doch, diese Größe bestimmt ganz entscheidend den Zeitbedarf für die Durchführung einer Datensicherung! Früher konnte man noch problemlos eine tägliche Vollsicherung von Platte A nach B (oder Band C) schaufeln. Heutzutage wäre das ziemlich illusorisch, so dass man schon eine deutliche Unterstützung durch das Dateisystem und intelligentere Datensicherungsalgorithmen benötigt, um die Daten auf eine Art und Weise zu sichern, die einem im Falls eines Ausfalls die Wiederherstellunng der relevanten Daten ermöglicht. Ich schreibe ganz bewusst nicht "aller Daten". Gerade neulich musste ich versuchen, einem Kunden seine Illusion einer täglichen Vollsicherung auf Magnetband zu rauben.
Andreas S. schrieb: > Konrad schrieb: >> Aber "Transferrate/Kapazität" ist IMHO keine praxisrelevante Größe. > > Doch, diese Größe bestimmt ganz entscheidend den Zeitbedarf für die > Durchführung einer Datensicherung! Früher konnte man noch problemlos > eine tägliche Vollsicherung von Platte A nach B (oder Band C) schaufeln. > Heutzutage wäre das ziemlich illusorisch, so dass man schon eine > deutliche Unterstützung durch das Dateisystem und intelligentere > Datensicherungsalgorithmen benötigt, um die Daten auf eine Art und Weise > zu sichern, die einem im Falls eines Ausfalls die Wiederherstellunng der > relevanten Daten ermöglicht. Ich schreibe ganz bewusst nicht "aller > Daten". > Gerade neulich musste ich versuchen, einem Kunden seine Illusion einer > täglichen Vollsicherung auf Magnetband zu rauben. Genau das meine ich. Aber es beginnt schon beim Testen vor dem ersten Verwenden, denn nach schlechten Erfahrungen starte ich bei Datenträgern immer, auch beim USB-Speicherstick, mit mindestens einem Badblocks-Lauf (badblocks -wsv -c 65536 -t random -o log.txt /dev/<device> 2>&1 | tee logg.txt). Dieses erste Testen, das übrigends auch Fakes erkennt, die mehr anzeigen als physikalisch vorhanden ist, dauert immer länger. Deshalb verwende ich für ein Backup immer rsync, damit nur Änderungen übertragen werden, und ich plane zumindest einen Lauf über Nacht ein. Ebenso beim Speichertest, den ich auch über Nacht laufen lasse. Neues RAM teste ich mit Memtest86+ vom Knoppix und auch das Testen vom Arbeitsspeicher dauert immer länger; 1 MB von 1990 zu Testen dauert weniger lange als 64 GiB DDR4 von 2015.
:
Bearbeitet durch User
Wer zwingt dich, die 150.000facher Größe auch auszunutzen? Benutzt du nur eine 2GB Partion, bekommst du für 1/10 des Preises die 150 fache Kapazität bei 150 facher Transferrate. Der Test braucht genau so lange wie früher. Dein Problem erinnert an Dagobert Duck: "Es ist schon ein Kreuz, wenn man 3 Kubikhektar Gold besitzt. Alleine die Lagerung kostet schon ein Vermögen."
Noch einer schrieb: > Dein Problem erinnert an Dagobert Duck: "Es ist schon ein Kreuz, wenn > man 3 Kubikhektar Gold besitzt. Alleine die Lagerung kostet schon ein > Vermögen." :-) Sehr treffender Vergleich.
Konrad schrieb: > *Nochmal, weil es so wichtig ist: Bei einer gesunden 8TB-Platte sind > Lesefehler beim Kompletttest statistisch die Regel, nicht die Ausnahme! Halte ich für ein Gerücht. Wenn dem wirklich so wäre, dann müssten ja alle Wahnsinnig sein, die auf so großen Platten Daten speichern. Nur weil der Hersteller nicht mehr garantieren möchte muss die Platte nicht tatsächlich so schlecht sein. Wie dieser Wert zustande kommt ist ohnehin völlig undurchsichtig.
Sebastian V. schrieb: > Halte ich für ein Gerücht. Wenn dem wirklich so wäre, dann müssten ja > alle Wahnsinnig sein, die auf so großen Platten Daten speichern. Nur > weil der Hersteller nicht mehr garantieren möchte muss die Platte nicht > tatsächlich so schlecht sein. Wie dieser Wert zustande kommt ist ohnehin > völlig undurchsichtig. in 99,99% der Fälle wo solchen Datenmengen privat gespeichert werden spielt es aber keine Rolle ob ein Byte mal falsch ist.
Fragt sich nur, wie man sich das mit den 10^14 Bits vorstellen soll. Immerhin arbeiten die Disks mit 4KB Sektoren, und wenn der futsch ist, dann kommt wahrscheinlich nicht nur 1 Bit falsch raus. Gibts also alle 1,5 Scans statistisch ein falsches Bit, oder alle tausend Scans einen ziemlich falschen Block?
:
Bearbeitet durch User
Konrad schrieb: > *Nochmal, weil es so wichtig ist: Bei einer gesunden 8TB-Platte sind > Lesefehler beim Kompletttest statistisch die Regel, nicht die Ausnahme! Da man bei RAID Systemen klugerweise automatisch Scans laufen lässt, um deren Konsistenz zu prüfen, kann man daraus eine Vorstellung entwickeln, wie sich diese Theorie in die Praxis umsetzt. Denn die System vermelden, wenn sie was zu reparieren haben. Und da ist es keineswegs so, dass beim Scan eines 30TB Systems aus 08/15 SATAs jedesmal Fehler auftreten.
:
Bearbeitet durch User
A. K. schrieb: > Und da ist es keineswegs so, dass beim > Scan eines 30TB Systems jedesmal Fehler auftreten. vermutlich sind es dann aber nicht die billigsten Consumer Festplatten.
Peter II schrieb: > vermutlich sind es dann aber nicht die billigsten Consumer Festplatten. In diesem Fall schon, weil reine Archivsysteme für anspruchslose Fälle. Da stecken gewöhnliche Hitachi Deskstar 7K3000 3TB drin (HDS72303), mit den üblichen 10^14. Kann sein, dass bei den wöchentlichen Checks mal was gefunden wurde, aber wenn, dann extrem selten.
:
Bearbeitet durch User
A. K. schrieb: > Fragt sich nur, wie man sich das mit den 10^14 Bits vorstellen soll. > Immerhin arbeiten die Disks mit 4KB Sektoren, und wenn der futsch ist, > dann kommt wahrscheinlich nicht nur 1 Bit falsch raus. Gibts also alle > 1,5 Scans statistisch ein falsches Bit, oder alle tausend Scans einen > ziemlich falschen Block? Im Datenblatt http://www.seagate.com/www-content/product-content/hdd-fam/seagate-archive-hdd/en-us/docs/archive-hdd-dS1834-3-1411us.pdf ist von "Nonrecoverable Read Errors per Bits Read" die Rede. D.h. ECC uncorrectable, in den SMART-Daten angezeigt als "Current Pending Sector Count". Diese Blöcke werden wieder "gut" wenn man was neues draufschreibt. Das (S)ATA-Inferface liefert dann command aborted (ABRT), d.h. es werden keine Daten an den Host übergeben.
Andreas S. schrieb: > Konrad schrieb: >> Aber "Transferrate/Kapazität" ist IMHO keine praxisrelevante Größe. > > Doch, diese Größe bestimmt ganz entscheidend den Zeitbedarf für die > Durchführung einer Datensicherung! Früher konnte man noch problemlos > eine tägliche Vollsicherung von Platte A nach B (oder Band C) schaufeln. Ne, der Zeitbedarf einer Sicherung wird nur durch die Transferrate und die Datenmenge bestimmt, die Größe des Speichermediums hat da nichts mit zu tun. Ausser die HDD ist komplett voll und nicht über LVM und co abstrahiert, dann hast du recht. Aber auch in diesem Fall ist "Transferrate/Kapazität" im Alltag völlig egal, weil, wie du sagst, niemand regelmäßig ein neues Voll-Backup anlegt. Ausser beim ersten beschreiben (und das ist nicht "Alltag"). Sebastian V. schrieb: > Konrad schrieb: >> *Nochmal, weil es so wichtig ist: Bei einer gesunden 8TB-Platte sind >> Lesefehler beim Kompletttest statistisch die Regel, nicht die Ausnahme! > > Halte ich für ein Gerücht. Wenn dem wirklich so wäre, dann müssten ja > alle Wahnsinnig sein, die auf so großen Platten Daten speichern. Nur > weil der Hersteller nicht mehr garantieren möchte muss die Platte nicht > tatsächlich so schlecht sein. Wie dieser Wert zustande kommt ist ohnehin > völlig undurchsichtig. Du hast, im Durchschnitt, alle 10TB einen Bitfehler. Ob du die Daten auf kleinen oder großen Platten speicherst ist egal. Es gibt afaik von Google eine Studie zu Ausfallraten zu HDDs, ich weiß nicht ob da auch Bitfehlerraten untersucht wurden. Wenn ja kannst du gerne mal schauen, ob die auf mehr oder weniger als 1/10E14 kommen, so lange bleibe ich erstmal bei meiner Behauptung.
Konrad schrieb: > Ne, der Zeitbedarf einer Sicherung wird nur durch die Transferrate und > die Datenmenge bestimmt, die Größe des Speichermediums hat da nichts mit > zu tun. Kannst Du nicht lesen, bist Du dumm oder willst Du mir einfach nur falsche Äußerungen unterstellen? Ich habe in der von Dir zitierten Textpassage überhaupt keine Aussage über die Speicherkapazität getroffen, sondern nur über das Verhältnis. Durch das Fortlassen meiner Äußerung "[...], die einem im Falls eines Ausfalls die Wiederherstellunng der relevanten Daten ermöglicht. Ich schreibe ganz bewusst nicht "aller Daten"." unterstellst Du mir ferner, dass ich bei meinen Betrachtungen keine Rücksicht auf die tatsächliche Belegung der Datenträger bzw. Dateisysteme nähme. Die vollständige Datensicherung eines Datenträgers bestünde ja schließlich in einer bitweise identischen Kopie seiner Blockstruktur. Diese Sicherung kann z.B. bei Boot-Dateisystemen durchaus angebracht sein, um die Wiederherstellungszeit zu minimieren. Die erste deutliche Einsparung von Datensicherungvolumen bestünde natürlich in der dateiweisen Sicherung, die nächste durch Beschränkung auf Teile der Verzeichnisbäume. Darüber hinausgehende Techniken widmen sich der Erkennung und Vermeidung unnötiger mehrfacher Sicherung gleicher Inhalte (Deduplizierung). > Ausser die HDD ist komplett voll und nicht über LVM und co > abstrahiert, dann hast du recht. Was hierbei Volume Manager zu suchen haben, ist mir rätselhaft. > Aber auch in diesem Fall ist > "Transferrate/Kapazität" im Alltag völlig egal, weil, wie du sagst, > niemand regelmäßig ein neues Voll-Backup anlegt. Ausser beim ersten > beschreiben (und das ist nicht "Alltag"). Selbst beim ersten Beschreiben wird man meist keine volle bitidentische Datensicherung auf Blockebene machen, sondern auf Dateiebene bleiben. > Du hast, im Durchschnitt, alle 10TB einen Bitfehler. Ob du die Daten auf > kleinen oder großen Platten speicherst ist egal. Nein, die Erkennung von Bitfehlern hängt auch sehr stark von den zugrundeliegenden Aufzeichnungsverfahren und Speicherzellgrößen ab. Deine Betrachtung gilt nur bei Datenträgern gleicher Technologie.
Einfach inkrementelles Backup auf Dateiebene geht innerhalb von Minuten. Bitweise Kopieren ist sowas von gestern.
Lukas S. schrieb: > Einfach inkrementelles Backup auf Dateiebene geht innerhalb von Minuten. Bei einigermaßen großen Verzeichnisbäumen ist häufig die Suchzeit für die geänderten Dateien der begrenzende Faktor und nicht die Transferrate für die Dateiinhalte, insbesondere wenn die Dateilisten in der Datenbank der Backup-Server eingetragen werden müssen. > Bitweise Kopieren ist sowas von gestern. Bitweises Kopieren ist z.B. bei Failover-Szenarien in Clustern sowas von heute, ebenso für überschaubare Boot-Dateisysteme. Für die allgemeine Sicherung von Dateisystemen hat es jedoch kaum mehr Relevanz.
Bitweises Kopieren ist auch bei einer Desaster Recovery nicht von gestern. Und da kommt es auch auf die Zeit an
ich_eben schrieb: > Bitweises Kopieren ist auch bei einer Desaster Recovery nicht von > gestern. Und da kommt es auch auf die Zeit an Wenn man mal erlebt hat, wie lange es dauern kann, eine riesige Menge kleiner Files im Gänsemarsch auf Platte zu schieben.
Andreas S. schrieb: > Kannst Du nicht lesen, bist Du dumm oder willst Du mir einfach nur > falsche Äußerungen unterstellen? Ja. Andreas S. schrieb: > Die vollständige Datensicherung eines Datenträgers bestünde ja > schließlich in einer bitweise identischen Kopie seiner Blockstruktur. Andreas S. schrieb: > Selbst beim ersten Beschreiben wird man meist keine volle bitidentische > Datensicherung auf Blockebene machen, sondern auf Dateiebene bleiben. Reden wir nun bei "Sicherung" über bitgenaue Kopien oder über Dateisicherungen? Ich bin, weil es um große HDDs ging, von letzterem ausgegangen. Ich erwidere gerne deine Argumente (ausser die ad hominem), aber zuerst musst du dich entscheiden worüber wir reden. Besten Gruß Konrad
Konrad schrieb: > Reden wir nun bei "Sicherung" über bitgenaue Kopien oder über > Dateisicherungen? Ich bin, weil es um große HDDs ging, von letzterem > ausgegangen. Aha? Du hast irgendwelche Leistungswerte auf Geräteebene aufgeführt. > Ich erwidere gerne deine Argumente (ausser die ad hominem), > aber zuerst musst du dich entscheiden worüber wir reden. Ich muss da gar nichts entscheiden. Wichtig ist lediglich, im Zuge der Argumentation die richtigen Begrifflichkeiten zu verwenden, und das habe ich getan. Datensicherung ist ein hinreichend abstrakter Begriff, der sowohl dateiweise als auch dateisystemweise oder geräteweise Vorgänge umfasst.
Ich versuche nochmal, meine Position auf den Punkt zu bringen, wir trollen irgendwie an einander vorbei... Also kurz und knapp: Wenn man Daten als Dateien sichert, ist die Metrik des OP unbedeutend, weil man die Gesamtmenge seiner Daten sichert, nicht die Menge, die auf das Medium passt. Wenn man Daten auf Blockebene sichert macht die Metrik Sinn. Nur finde ich das Praxisfern, eben weil man heute eigentlich (wenn überhaupt) nur Systemdaten auf Blockebene sichert, und das sind meist <100GB auf einer SSD, also genauso in wenigen Minuten erledigt wie 1980. Andreas S. schrieb: > Ich muss da gar nichts entscheiden. Wichtig ist lediglich, im Zuge der > Argumentation die richtigen Begrifflichkeiten zu verwenden, und das habe > ich getan. Datensicherung ist ein hinreichend abstrakter Begriff, der > sowohl dateiweise als auch dateisystemweise oder geräteweise Vorgänge > umfasst. Klar musst du nicht. Das sagt man nur so. Aber wenn du dich nicht festlegst, weiß ich nicht was du meinst. Aber ich habe oben beide Deutungen erwähnt, also Feuer frei :D Vielleicht erkläre ich dir dann auch die Sache mit dem LVM ;) Konrad
Insgesamt muß man natürlich sagen, wer ein dickes Buch gekauft hat, braucht immer mehr Zeit zum lesen gegenüber einem Zettel. Konrad schrieb: > das Praxisfern Es ist ein großer Unterschied ob man einzelne Dateien oder komplette Platten 1:1 kopiert. Bei einzelnen Dateien muß immer das Directory gepflegt werden sobald diese Datei fertig ist. Das verbraucht auch viel Zeit für Kopfpositionierungen.
Andreas S. schrieb: > Lukas S. schrieb: >> Einfach inkrementelles Backup auf Dateiebene geht innerhalb von Minuten. > > Bei einigermaßen großen Verzeichnisbäumen ist häufig die Suchzeit für > die geänderten Dateien der begrenzende Faktor und nicht die Transferrate > für die Dateiinhalte, insbesondere wenn die Dateilisten in der Datenbank > der Backup-Server eingetragen werden müssen. Ja, ich sehe das bei jedem Backup mit Rsync mit einem Monitor wie Gkrellm, denn Rsync beginnt erstmal mit der Suche nach geänderten Dateien, wobei sich auch bei mittelschnellen SSHDs nur 1 % der Transferrate zeigt, meist zwischen 1 und 2 MB/s. Und bei über einer Million Dateien dauert das nicht nur ein paar Sekunden.
Rolf F. schrieb: > Und bei über einer Million Dateien dauert das nicht nur ein paar > Sekunden. Bei Bandlaufwerken führen diese Datenbank- und Suchoperationen vor allem dazu, dass der kontinuierlich ans Bandlaufwerk lieferbare Datenstrom zeitweise ins Stocken gerät, so dass das Bandlaufwerk dann im Start-Stopp-Betrieb arbeitet und unglaublich langsam wird, vorzeitig verschleißt und durch das erforderliche Schreiben von Synchronisationsmuster nur einen Bruchteil der Bandkapazität ausnutzen kann. Je nach Backup-Programm kann man auch noch Puffer aktivieren, was diesen Effekt etwa mildern kann. Bei plattenbasierte Datensicherungen spielt das aber keine nennenswerte Rolle, d.h. weder Geschwindigkeits- und Platzverlust noch vorzeitiger Verschleiß.
Lukas S. schrieb: > Einfach inkrementelles Backup auf Dateiebene geht innerhalb von Minuten. Diese pauschale Aussage ist falsch. Man nehme einen (virtuellen) David-Server, ein Storage-System mit 250MB/sec, und sichere 250 GB Mails inkrementell, wobei die Mails von David alle in Kleinst-Dateien (i.d.R. 3 Stück pro Mail - ohne Anhänge) gespeichert werden. Allein die Zeit, um festzustellen, dass sich gegenüber dem letzten Backup nichts geändert hat, dauert mehr als 12 Stunden. > Bitweise Kopieren ist sowas von gestern. Obiges beschriebenes System direkt blockweise auf Sicherungsplatte - inkl. Betriebssystem und Netphone Telefonanlage für 100 User: unter 1 Stunde.
:
Bearbeitet durch Moderator
Frank M. schrieb: > Lukas S. schrieb: >> Einfach inkrementelles Backup auf Dateiebene geht innerhalb von Minuten. > > Diese pauschale Aussage ist falsch. > > Man nehme einen (virtuellen) David-Server, ein Storage-System mit > 250MB/sec, und sichere 250 GB Mails inkrementell, wobei die Mails von > David alle in Kleinst-Dateien (i.d.R. 3 Stück pro Mail - ohne Anhänge) > gespeichert werden. > > Allein die Zeit, um festzustellen, dass sich gegenüber dem letzten > Backup nichts geändert hat, dauert mehr als 12 Stunden. Ok, das ist der Ist-Zustand, aber das müsste man optimieren können, indem man ein Dateisystem verwendet, bei dem die letzte Modifikationszeit auch in den übergeordneten Verzeichnissen verzeichnet wird. Dann sieht man schon beim Vergleich der Metadaten der Top-Verzeichnisse das keine Änderung vorliegt und ist in einer Millisekunde fertig. Wenn sich aber viel geändert hat, bringt diese Optimierung praktisch nichts.
Rolf F. schrieb: > Ok, das ist der Ist-Zustand, Nö, der Ist-Zustand ist, dass ein blockweises Image der Maschine in unter 1h erstellt wird - Host ist ein Xen-Server, also Linux. Restore der kompletten Maschine, welche danach sofort wieder startbereit ist, dauert genauso lange. > aber das müsste man optimieren können, indem man ein Dateisystem verwendet, Filesystem: NTFS, da (virtueller) Windows-Server. Sorry, habe ich vergessen zu schreiben. Und bitte nicht damit kommen, dass der schwache Durchsatz von der virtuellen Maschine herrührt. Auch diese bekommt die 250MB/sec vom Storage-System. Wahrscheinlich würde es etwas bringen, die Platten im Storage, auf denen der David-Server liegt, durch SSDs zu ersetzen, da wohl die meiste Zeit beim Datei-Durchnudeln bei einem inkrementellen Backup durch Postionierung der Köpfe vergeudet wird. Das neue Storage (16 TB netto, 32TB brutto), welches für diesen Sommer geplant ist, wird daher komplett SSDs verwenden. Aber trotzdem werde ich nicht davon abrücken, die Maschine als Komplett-Image in der Nacht sichern zu lassen. Es gibt für mich nur ein Argument gegen blockweises Sichern: Der Verlust einer einzelnen Datei wegen eines Benutzer-/Software-Fehlers. Das ist aber dank der "Schattenkopien" unter Windows überhaupt kein Problem mehr. Da zaubert man die versehentlich gelöschte Datei innerhalb von Sekunden wieder hervor und der User wundert sich....
:
Bearbeitet durch Moderator
Frank M. schrieb: > Das neue Storage (16 TB netto, 32TB brutto), welches für diesen Sommer > geplant ist, wird daher komplett SSDs verwenden. Aber trotzdem werde ich > nicht davon abrücken, die Maschine als Komplett-Image in der Nacht > sichern zu lassen. Wobei man blockweise Replikate öfters auch inkrementell fahren kann. Sei es im Speichersystem, sei es auf Basis des Virtualisierungs-Systems. Man hat auch nicht in jedem Unternehmen die Nacht zur freien Verfügung. > Es gibt für mich nur ein Argument gegen blockweises Sichern: Der Verlust > einer einzelnen Datei wegen eines Benutzer-/Software-Fehlers. Yep. Disaster-Recovery und Wiederherstellung einzelner Files/Directories sind zunächst völlig verschiedene Anwendungsfälle, für die ggf. auch verschiedene Backup-Mechanismen verwendet werden. > Das ist > aber dank der "Schattenkopien" unter Windows überhaupt kein Problem > mehr. Da zaubert man die versehentlich gelöschte Datei innerhalb von > Sekunden wieder hervor und der User wundert sich.... Wobei man da etwas auf die Rechte achten sollte, da manche Ransomware vorsorglich die Schattenkopien wegzuräumen versucht.
Rolf F. schrieb: > indem man ein Dateisystem verwendet, bei dem die letzte > Modifikationszeit auch in den übergeordneten Verzeichnissen verzeichnet > wird. Welches wäre das beispielsweise?
A. K. schrieb: > Wobei man blockweise Replikate öfters auch inkrementell fahren kann. Jepp, darüber habe ich in letzter Zeit auch schon öfters nachgedacht. So kann man die Vorteile von beiden Verfahren nutzen.
:
Bearbeitet durch Moderator
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.