12-08-2018, 18:41
Lass uns die Windows-Fehlermeldung aufschlüsseln:
"Die Schattenkopien des Volumes C: wurden gelöscht weil der Speicher für die Schattenkopie nicht rechtzeitig wachsen konnte in der Zeit. Erwägen Sie die IO Last auf dem System zu reduzieren oder wählen Sie ein Volumen für die Schattenkopie, das nicht mit Schattenkopien versehen wird."
Kompakte Fehlermeldungen wie die obige müssen mehrmals mit hoher Konzentration und viel Kaffee gelesen werden...
Wenn ein Backup mit VSS gemacht wird, wird ein Schatten der Partition (Beispiel C
erstellt. Das Backup erfolgt durch das Lesen vom Schatten, nicht vom tatsächlichen Laufwerk C:.
Was ist ein Schatten? Eine 'falsche' und konsistente Ansicht der Festplatte aus der Vergangenheit. Die Festplatte wird live gesichert, das bedeutet, dass andere Anwendungen ständig Dateien ändern. Aber wir wollen eine konsistente Ansicht, nicht eine Live-Ansicht.
Erinnere dich daran, was passiert, wenn du nachts mit einer sehr langen Belichtungszeit ein Foto machst und es Bewegung gibt? Es wird verschwommen aussehen.
Was du möchtest, ist ein Schnappschuss, so schnell, dass es keine Bewegung gibt und das Bild scharf ist. Bei Backups wollen wir eine 100% exakte Wiedergabe dessen, wie das C:-Laufwerk zu einem bestimmten Zeitpunkt aussah.
Und diese Darstellung muss so lange aufrechterhalten werden, wie das Backup dauert. Diese Darstellung des genauen Inhalts der Festplatte aus der Vergangenheit ist ein 'Volumeschatten', der von VSS bereitgestellt wird.
Jetzt muss VSS diesen vergangenen Blick auf den Inhalt des Laufwerks ständig 'fälschen', und das ist harte Arbeit, wenn viele Anwendungen auf die Festplatte schreiben und den Inhalt ändern. VSS muss alle geänderten Sektoren puffern, um den vergangenen Inhalt der geänderten Sektoren zu bewahren.
Daher gilt: Je mehr Schreibaktivität auftritt, desto mehr Pufferarbeit muss VSS leisten. VSS verwendet eine versteckte Datei, um diese Änderungen an den Sektoren zu puffern. Daher kann der Puffer möglicherweise knapp werden, wenn diese Pufferdatei zu groß wird (als Folge von zu vielen geänderten Sektoren auf der Festplatte während des Backups).
Aber das Problem hier ist nicht der Speicherplatz.
Die Fehlermeldung sagt "speicher konnte in der Zeit nicht wachsen" und das bedeutet, dass die ZEIT das Problem ist. Wenn diese Pufferaktivitäten zu lange dauern, weil es zu viele sind, die durch "zu viel" Schreiben auf die Festplatte verursacht werden, müsste VSS möglicherweise das gesamte System drosseln, um aufzuholen und den Schatten lebendig zu halten. Aufgrund eines festgelegten Zeitlimits innerhalb von VSS entscheidet es sich dann, das Schiff zu verlassen und den Schatten zu löschen. Natürlich schlägt das Backup dann fehl, weil das Gerät, von dem gelesen wird, plötzlich verschwunden ist.
Um zusammenzufassen: Dies ist eine Situation, in der "zu viel" auf die Festplatte geschrieben wird, mehr als die Hardware in angemessener Zeit verarbeiten kann. "Angemessen" ist einfach ein Zeitlimit innerhalb von VSS, das nicht geändert werden kann.
Was verursacht "zu viel" Schreiben auf die Festplatte? Die Nachricht sagt dir tatsächlich, worauf du achten sollst: "Erwägen Sie die IO Last auf dem System zu reduzieren". Das bedeutet, es gibt Dienste/Anwendungen, die die Festplatte mit Blockänderungen belasten. Denk daran, dass jeder geänderte Block von VSS in einer Pufferdatei 'gerettet' werden muss, sodass jeder geschriebene Sektor letztendlich die Festplatte zweimal treffen wird.
Berücksichtige, dass dies eine mechanische Festplatte ist. Daher gibt es Sektorensuchzeiten von 10-50 ms, möglicherweise für die am stärksten betroffenen Sektoren.
Berücksichtige zudem, dass das Laufwerk stark fragmentiert sein kann. Fragmentierung erfordert, dass die Köpfe viel mehr bewegen müssen, und dies erhöht die Suchzeit.
Berücksichtige eine möglicherweise ungünstige Konfiguration: Jemand hat eine Desktop-Festplatte genommen und sie mit 10 VMs beladen, die wahrscheinlich festplattenintensiv sind. Eine Desktop-Festplatte ist kein geeignetes Medium für VM-Aktivitäten, die sehr intensiv sind. 10 VMs sind die Last von 10 ganzen Servern! Das auf eine billige Desktop-Festplatte für Produktionszwecke zu setzen, ist, nun ja, sagen wir 'uninformiert'....
Das bringt uns zu einer weiteren wichtigen Richtlinie:
Wenn du Server entwirfst und baust (oder sie maßgeschneidert bestellst, wenn du allergisch gegen Elektronik bist), musst du die Last unbedingt auf separate RAID-Arrays (oder zumindest Festplatten) isolieren.
Du könntest ein riesiges RAID-Array für deine VMs oder DBs mit sagen wir 64TB Platz aufbauen, alles in einem Stück. Problem: VSS funktioniert derzeit nicht mit mehr als 16TB (was ein Problem ist, da die größte HDD heute bereits 14TB beträgt).
Zweites Problem: Selbst wenn es 64TB unterstützen würde, arbeitet VSS auf Partitionsebene.
Wenn du also 64TB alles in einer Partition unterbringst, muss VSS alle Änderungen der gesamten 64TB-Partition während eines Backups puffern, selbst wenn du nur eine kleine 100GB-VM sichern möchtest....
Siehst du, das wäre ebenfalls ungünstig....aber du wirst es in zu vielen Unternehmen finden...
Mindestens könntest du die 64TB in kleinere Partitionen aufteilen und weiterhin dasselbe RAID-Array darunter verwenden, das ist in Ordnung. Dann platziere die VMs strategisch so, dass die Schreib-Last aller VMs zusammen verteilt ist, nicht die meisten in einer Partition.
Noch besser für die Leistung und Backups: Verwende völlig separate RAID-Arrays.
"Die Schattenkopien des Volumes C: wurden gelöscht weil der Speicher für die Schattenkopie nicht rechtzeitig wachsen konnte in der Zeit. Erwägen Sie die IO Last auf dem System zu reduzieren oder wählen Sie ein Volumen für die Schattenkopie, das nicht mit Schattenkopien versehen wird."
Kompakte Fehlermeldungen wie die obige müssen mehrmals mit hoher Konzentration und viel Kaffee gelesen werden...
Wenn ein Backup mit VSS gemacht wird, wird ein Schatten der Partition (Beispiel C
erstellt. Das Backup erfolgt durch das Lesen vom Schatten, nicht vom tatsächlichen Laufwerk C:. Was ist ein Schatten? Eine 'falsche' und konsistente Ansicht der Festplatte aus der Vergangenheit. Die Festplatte wird live gesichert, das bedeutet, dass andere Anwendungen ständig Dateien ändern. Aber wir wollen eine konsistente Ansicht, nicht eine Live-Ansicht.
Erinnere dich daran, was passiert, wenn du nachts mit einer sehr langen Belichtungszeit ein Foto machst und es Bewegung gibt? Es wird verschwommen aussehen.
Was du möchtest, ist ein Schnappschuss, so schnell, dass es keine Bewegung gibt und das Bild scharf ist. Bei Backups wollen wir eine 100% exakte Wiedergabe dessen, wie das C:-Laufwerk zu einem bestimmten Zeitpunkt aussah.
Und diese Darstellung muss so lange aufrechterhalten werden, wie das Backup dauert. Diese Darstellung des genauen Inhalts der Festplatte aus der Vergangenheit ist ein 'Volumeschatten', der von VSS bereitgestellt wird.
Jetzt muss VSS diesen vergangenen Blick auf den Inhalt des Laufwerks ständig 'fälschen', und das ist harte Arbeit, wenn viele Anwendungen auf die Festplatte schreiben und den Inhalt ändern. VSS muss alle geänderten Sektoren puffern, um den vergangenen Inhalt der geänderten Sektoren zu bewahren.
Daher gilt: Je mehr Schreibaktivität auftritt, desto mehr Pufferarbeit muss VSS leisten. VSS verwendet eine versteckte Datei, um diese Änderungen an den Sektoren zu puffern. Daher kann der Puffer möglicherweise knapp werden, wenn diese Pufferdatei zu groß wird (als Folge von zu vielen geänderten Sektoren auf der Festplatte während des Backups).
Aber das Problem hier ist nicht der Speicherplatz.
Die Fehlermeldung sagt "speicher konnte in der Zeit nicht wachsen" und das bedeutet, dass die ZEIT das Problem ist. Wenn diese Pufferaktivitäten zu lange dauern, weil es zu viele sind, die durch "zu viel" Schreiben auf die Festplatte verursacht werden, müsste VSS möglicherweise das gesamte System drosseln, um aufzuholen und den Schatten lebendig zu halten. Aufgrund eines festgelegten Zeitlimits innerhalb von VSS entscheidet es sich dann, das Schiff zu verlassen und den Schatten zu löschen. Natürlich schlägt das Backup dann fehl, weil das Gerät, von dem gelesen wird, plötzlich verschwunden ist.
Um zusammenzufassen: Dies ist eine Situation, in der "zu viel" auf die Festplatte geschrieben wird, mehr als die Hardware in angemessener Zeit verarbeiten kann. "Angemessen" ist einfach ein Zeitlimit innerhalb von VSS, das nicht geändert werden kann.
Was verursacht "zu viel" Schreiben auf die Festplatte? Die Nachricht sagt dir tatsächlich, worauf du achten sollst: "Erwägen Sie die IO Last auf dem System zu reduzieren". Das bedeutet, es gibt Dienste/Anwendungen, die die Festplatte mit Blockänderungen belasten. Denk daran, dass jeder geänderte Block von VSS in einer Pufferdatei 'gerettet' werden muss, sodass jeder geschriebene Sektor letztendlich die Festplatte zweimal treffen wird.
Berücksichtige, dass dies eine mechanische Festplatte ist. Daher gibt es Sektorensuchzeiten von 10-50 ms, möglicherweise für die am stärksten betroffenen Sektoren.
Berücksichtige zudem, dass das Laufwerk stark fragmentiert sein kann. Fragmentierung erfordert, dass die Köpfe viel mehr bewegen müssen, und dies erhöht die Suchzeit.
Berücksichtige eine möglicherweise ungünstige Konfiguration: Jemand hat eine Desktop-Festplatte genommen und sie mit 10 VMs beladen, die wahrscheinlich festplattenintensiv sind. Eine Desktop-Festplatte ist kein geeignetes Medium für VM-Aktivitäten, die sehr intensiv sind. 10 VMs sind die Last von 10 ganzen Servern! Das auf eine billige Desktop-Festplatte für Produktionszwecke zu setzen, ist, nun ja, sagen wir 'uninformiert'....
Das bringt uns zu einer weiteren wichtigen Richtlinie:
Wenn du Server entwirfst und baust (oder sie maßgeschneidert bestellst, wenn du allergisch gegen Elektronik bist), musst du die Last unbedingt auf separate RAID-Arrays (oder zumindest Festplatten) isolieren.
Du könntest ein riesiges RAID-Array für deine VMs oder DBs mit sagen wir 64TB Platz aufbauen, alles in einem Stück. Problem: VSS funktioniert derzeit nicht mit mehr als 16TB (was ein Problem ist, da die größte HDD heute bereits 14TB beträgt).
Zweites Problem: Selbst wenn es 64TB unterstützen würde, arbeitet VSS auf Partitionsebene.
Wenn du also 64TB alles in einer Partition unterbringst, muss VSS alle Änderungen der gesamten 64TB-Partition während eines Backups puffern, selbst wenn du nur eine kleine 100GB-VM sichern möchtest....
Siehst du, das wäre ebenfalls ungünstig....aber du wirst es in zu vielen Unternehmen finden...
Mindestens könntest du die 64TB in kleinere Partitionen aufteilen und weiterhin dasselbe RAID-Array darunter verwenden, das ist in Ordnung. Dann platziere die VMs strategisch so, dass die Schreib-Last aller VMs zusammen verteilt ist, nicht die meisten in einer Partition.
Noch besser für die Leistung und Backups: Verwende völlig separate RAID-Arrays.
