97561
19.06.2014
12118
25
0
ESXi 5 - Veeam Snapshot löschen friert Produktivsystem ein (Exchange, DNS, DHCP, AD)
Moin zusammen,
wir sichern mit Veeam 1,49 TB auf einer VM weg. Leider friert beim Snapshotlöschen die VM ein und die oben genannten Dienste funktionieren nicht.
Wie kann man das verhindern. Das löschen dauert zwischen 3 - 5 Stunden. Es läuft ein SBS 2008 drauf.
Habt ihr eine Lösung die mir eventuell weiterhilft?
LG
Philip
wir sichern mit Veeam 1,49 TB auf einer VM weg. Leider friert beim Snapshotlöschen die VM ein und die oben genannten Dienste funktionieren nicht.
Wie kann man das verhindern. Das löschen dauert zwischen 3 - 5 Stunden. Es läuft ein SBS 2008 drauf.
Habt ihr eine Lösung die mir eventuell weiterhilft?
LG
Philip
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 241376
Url: https://administrator.de/forum/esxi-5-veeam-snapshot-loeschen-friert-produktivsystem-ein-exchange-dns-dhcp-ad-241376.html
Ausgedruckt am: 22.12.2024 um 20:12 Uhr
25 Kommentare
Neuester Kommentar
Moin zurück,
1. einen SBS auf ESXi und
2. einen SBS mit 1,5 TB Daten ...
Die Lösung:
Bring den SBS zurück aufs Blech und lass ihn nur als SBS arbeiten
LG, Thomas
Habt ihr eine Lösung die mir eventuell weiterhilft?
mal gucken ... Du hast:1. einen SBS auf ESXi und
2. einen SBS mit 1,5 TB Daten ...
Die Lösung:
Bring den SBS zurück aufs Blech und lass ihn nur als SBS arbeiten
LG, Thomas
1
Hi,
wir sichern auch VM's > 1 TB mit VEEAM. Das geht. Und auch das Löschen der Snapshots zum Ende des Jobs geht zügig.
Die Dauer der "Löschung" eines VM-Snapshots hängt im Wesentlichen vobn folgenden Faktoren ab:
1. Die Größe des Snapshots - also die Menge der Daten (Blöcke), welche seit der Erstellung des Snapshots an den im Snapshot enthaltenen Laufwerken geändert wurde
2. Der Laietungsfähigkeit des physikalischen Storage.
3. Der Aktivität auf den Laufwerken der virtuellen Laufwerke der VM beim "Löschen" des Snapshots.
Löschen in "" weil hier defacto nichts gelöscht wird, sondern die unter 1. erwähnten Blöcke in die jeweiligen VMDK's "reinkopiert" werden. Deshalb auch die Menge der Daten und die Leistungsfähigkeit des Storage interessant.
Ich würde erstmal folgendes abklopfen:
A. Wie groß wird der Snapshot während der Sicherung?
B. Was ist, wenn Du manuell einen Snapshot erststellst und den nach 5 min. wieder löschst. Wie schnell geht das dann?
C. Wieviel IOpS (Schreibzugriffe/s, Lesezugriffe/s) und wieviel KB/s (Schreiben) fallen im Normalfall während des Backups an? Dazu müsstest Du den Job mal aussetzen und stattdessen für dessen übliche Dauer die genannten Counter aufzeichen. Entweder mit Windows (perfmon) oder mit VMware (esxtop).
E.
wir sichern auch VM's > 1 TB mit VEEAM. Das geht. Und auch das Löschen der Snapshots zum Ende des Jobs geht zügig.
Die Dauer der "Löschung" eines VM-Snapshots hängt im Wesentlichen vobn folgenden Faktoren ab:
1. Die Größe des Snapshots - also die Menge der Daten (Blöcke), welche seit der Erstellung des Snapshots an den im Snapshot enthaltenen Laufwerken geändert wurde
2. Der Laietungsfähigkeit des physikalischen Storage.
3. Der Aktivität auf den Laufwerken der virtuellen Laufwerke der VM beim "Löschen" des Snapshots.
Löschen in "" weil hier defacto nichts gelöscht wird, sondern die unter 1. erwähnten Blöcke in die jeweiligen VMDK's "reinkopiert" werden. Deshalb auch die Menge der Daten und die Leistungsfähigkeit des Storage interessant.
Ich würde erstmal folgendes abklopfen:
A. Wie groß wird der Snapshot während der Sicherung?
B. Was ist, wenn Du manuell einen Snapshot erststellst und den nach 5 min. wieder löschst. Wie schnell geht das dann?
C. Wieviel IOpS (Schreibzugriffe/s, Lesezugriffe/s) und wieviel KB/s (Schreiben) fallen im Normalfall während des Backups an? Dazu müsstest Du den Job mal aussetzen und stattdessen für dessen übliche Dauer die genannten Counter aufzeichen. Entweder mit Windows (perfmon) oder mit VMware (esxtop).
E.
Hi emeriks,
natürlich ist das mit entsprechender Leistungsfähigkeit kein Problem, aber die Masse an Daten mit einem SBS2008 spricht ja schon Bände. Da wird der Server im Regelfall kein Bolide sein.
Grüße,
Christian
natürlich ist das mit entsprechender Leistungsfähigkeit kein Problem, aber die Masse an Daten mit einem SBS2008 spricht ja schon Bände. Da wird der Server im Regelfall kein Bolide sein.
Grüße,
Christian
Hi certifiedit,
mag sein, aber wenn der Snapshot z.B. bloß 1GB groß wäre, dann bräuchte es auch keinen Boliden. Mal abwarten, ob und was Philip an Daten liefert.
E.
mag sein, aber wenn der Snapshot z.B. bloß 1GB groß wäre, dann bräuchte es auch keinen Boliden. Mal abwarten, ob und was Philip an Daten liefert.
E.
Zitat von @emeriks:
Hi certifiedit,
mag sein, aber wenn der Snapshot z.B. bloß 1GB groß wäre, dann bräuchte es auch keinen Boliden. Mal
abwarten, ob und was Philip an Daten liefert.
E.
Hi certifiedit,
mag sein, aber wenn der Snapshot z.B. bloß 1GB groß wäre, dann bräuchte es auch keinen Boliden. Mal
abwarten, ob und was Philip an Daten liefert.
E.
Es ist aber das 1500fache, davon. Und dementsprechend...Doch, weil die Daten eben verarbeitet werden wollen und wie wir wissen ist der SBS an sich schon ein zickiges Gebilde.
und wie wir wissen ist der SBS an sich schon ein zickiges Gebilde
Nö, ist er nicht ... wenn man ihn dazu nutzt, wofür er gemacht ist 
. Und wenn man ihn nicht auf irgendwelche VMware-Teile rauf quetscht. Aber IT-Existenz besteht offensichtlich (fast) nur aus trial & error ...LG, Thomas
Zitat von @keine-ahnung:
> und wie wir wissen ist der SBS an sich schon ein zickiges Gebilde
Nö, ist er nicht ... wenn man ihn dazu nutzt, wofür er gemacht ist. Und wenn man ihn nicht auf irgendwelche
VMware-Teile rauf quetscht. Aber IT-Existenz besteht offensichtlich (fast) nur aus trial & error ...
LG, Thomas
> und wie wir wissen ist der SBS an sich schon ein zickiges Gebilde
Nö, ist er nicht ... wenn man ihn dazu nutzt, wofür er gemacht ist
. Und wenn man ihn nicht auf irgendwelcheVMware-Teile rauf quetscht. Aber IT-Existenz besteht offensichtlich (fast) nur aus trial & error ...
LG, Thomas
Das war eher auf das "ich will jedes Leistungsquäntchen haben" bezogen, als auf die Unbeherrschbarkeit. Die weitere Ausführung spar ich mir mal. Aber auf die Situation des TO gemünzt hast du vielleicht nicht ganz unrecht.
Es ist aber das 1500fache, davon. Und dementsprechend...Doch, weil die Daten eben verarbeitet werden wollen und wie wir wissen ist
der SBS an sich schon ein zickiges Gebilde.
der SBS an sich schon ein zickiges Gebilde.
Was redest Du denn da?
Wenn VEEAM (oder irgendein anderes Backup-Programm) 1,5 TB sichern, dann heißt das doch nicht, dass der Snapshot 1,5 TB groß ist! Der Snapshot kann dann auch nur 100 Mb groß sein, wenn man schnell genug ist.
E.
Zitat von @emeriks:
> Es ist aber das 1500fache, davon. Und dementsprechend...Doch, weil die Daten eben verarbeitet werden wollen und wie wir
wissen ist
> der SBS an sich schon ein zickiges Gebilde.
Was redest Du denn da?
Wenn VEEAM (oder irgendein anderes Backup-Programm) 1,5 TB sichern, dann heißt das doch nicht, dass der Snapshot 1,5 TB
groß ist! Der Snapshot kann dann auch nur 100 Mb groß sein, wenn man schnell genug ist.
E.
> Es ist aber das 1500fache, davon. Und dementsprechend...Doch, weil die Daten eben verarbeitet werden wollen und wie wir
wissen ist
> der SBS an sich schon ein zickiges Gebilde.
Was redest Du denn da?
Wenn VEEAM (oder irgendein anderes Backup-Programm) 1,5 TB sichern, dann heißt das doch nicht, dass der Snapshot 1,5 TB
groß ist! Der Snapshot kann dann auch nur 100 Mb groß sein, wenn man schnell genug ist.
E.
ich gehe aber mal davon aus, dass er gelegentliche Vollbackups löschen will und keine "run against backup size" Snapshots. Damit ist das komplett irrelevant, oder nicht? Die zu löschenden Backups werden ja nicht dadurch kleiner, dass er nun ein paar kleinere macht.
@certifiedit
wbb24 hat doch keine Probleme beim Löschen der Backups beschrieben sondern beim Löschen der von VEEAM erstellten Vmware-Snapshots. Das ist komplett was anderes.
E.
wbb24 hat doch keine Probleme beim Löschen der Backups beschrieben sondern beim Löschen der von VEEAM erstellten Vmware-Snapshots. Das ist komplett was anderes.
E.
Hallo,
das Problem hatten wir auch. Bei uns lag es an einem vorhanden Snapshot der schon mehrer Wochen alt war. Dieser war durch einen Absturz von Veeam hervorgegangen. Dabei wurde der durch Veeam erzeugte Snapshot nicht gelöscht.
Also hat Veeam/VMware einen Snapshot von einem Snapshot gemacht und die virtuelle Maschine war beim löschen des Snapshots kurzzeitig (ca. 10 Sekunden) nicht mehr erreichbar. Das ist für einen SQL natürlich... sagen wir mal schlecht. Auch das Erstellen des Snapshot dauerte ewig.
Schau einfach mal im vSphere Client im Snapshotmanager nach, ob vor der dem Backup schon ein Snapshot vorhanden ist. Diese muss dann gelöscht werden. Danach rennt das ganze wieder.
Gruß
Danny
das Problem hatten wir auch. Bei uns lag es an einem vorhanden Snapshot der schon mehrer Wochen alt war. Dieser war durch einen Absturz von Veeam hervorgegangen. Dabei wurde der durch Veeam erzeugte Snapshot nicht gelöscht.
Also hat Veeam/VMware einen Snapshot von einem Snapshot gemacht und die virtuelle Maschine war beim löschen des Snapshots kurzzeitig (ca. 10 Sekunden) nicht mehr erreichbar. Das ist für einen SQL natürlich... sagen wir mal schlecht.
Auch das Erstellen des Snapshot dauerte ewig.Schau einfach mal im vSphere Client im Snapshotmanager nach, ob vor der dem Backup schon ein Snapshot vorhanden ist. Diese muss dann gelöscht werden. Danach rennt das ganze wieder.
Gruß
Danny
Zitat von @emeriks:
@certifiedit
wbb24 hat doch keine Probleme beim Löschen der Backups beschrieben sondern beim Löschen der von VEEAM erstellten
Vmware-Snapshots. Das ist komplett was anderes.
E.
@certifiedit
wbb24 hat doch keine Probleme beim Löschen der Backups beschrieben sondern beim Löschen der von VEEAM erstellten
Vmware-Snapshots. Das ist komplett was anderes.
E.
Du weisst ja nicht, wo diese Snapshots gespeichert werden und da Veeam normalerweise ein hocheffizientes Programm ist geizt es bestimmt auch nicht bei den IOPS ;) -> Server stirbt, wenn entsprechend "optimal" eingerichtet.
@certifiedit
Sorry, aber Du weißt offensichtlich nicht, worum es hier geht.
VEEAM hat überhaupt keinen Einfluss darauf, wo VMware die Snapshots speichert. VEEAM beauftrat nur die Erstellung eines Snapshots. Wo, wie und warum - das "entscheidet" der ESX entsprechend seiner Konfiguration.
@d-g-l-80
Ja richtig! Hört sich sogar sehr wahrscheinlich an.
E.
Sorry, aber Du weißt offensichtlich nicht, worum es hier geht.
VEEAM hat überhaupt keinen Einfluss darauf, wo VMware die Snapshots speichert. VEEAM beauftrat nur die Erstellung eines Snapshots. Wo, wie und warum - das "entscheidet" der ESX entsprechend seiner Konfiguration.
@d-g-l-80
Ja richtig! Hört sich sogar sehr wahrscheinlich an.
E.
Hallo,
die Dateien des Snapshots werden wie von ESXi standardmäßig im Datastore\VM-Ordner gespeichert. Sie haben die Endung *.vmsn und wenn mehr als eine Datei vorhanden ist, sind auch mehrere Snapshots vorhanden. Alles ganz einfach
Gruß
Danny
die Dateien des Snapshots werden wie von ESXi standardmäßig im Datastore\VM-Ordner gespeichert. Sie haben die Endung *.vmsn und wenn mehr als eine Datei vorhanden ist, sind auch mehrere Snapshots vorhanden. Alles ganz einfach
Gruß
Danny
Mist zu langsam
Übrigens besteht bei vorhanden und lange aktiven Snapsshot immer die Gefahr, dass der Datastore vollläuft! Das verträgt der ESXi nicht so wirklich gut. Also im Snapshot-Manager einfach auf "Alle löschen" klicken und !nicht! auf "Wwechseln".
Gruß
Danny
Übrigens besteht bei vorhanden und lange aktiven Snapsshot immer die Gefahr, dass der Datastore vollläuft! Das verträgt der ESXi nicht so wirklich gut. Also im Snapshot-Manager einfach auf "Alle löschen" klicken und !nicht! auf "Wwechseln".
Gruß
Danny
Zitat von @emeriks:
@certifiedit
Sorry, aber Du weißt offensichtlich nicht, worum es hier geht.
VEEAM hat überhaupt keinen Einfluss darauf, wo VMware die Snapshots speichert. VEEAM beauftrat nur die Erstellung eines
Snapshots. Wo, wie und warum - das "entscheidet" der ESX entsprechend seiner Konfiguration.
@certifiedit
Sorry, aber Du weißt offensichtlich nicht, worum es hier geht.
VEEAM hat überhaupt keinen Einfluss darauf, wo VMware die Snapshots speichert. VEEAM beauftrat nur die Erstellung eines
Snapshots. Wo, wie und warum - das "entscheidet" der ESX entsprechend seiner Konfiguration.
Zeig mir mal die Zeile, in der ich gesagt habe, dass Veeam das beeinflusst? Ich sagte nur, dass hier das System überlastet ist, respektive sein kann. Natürlich wissen wir nicht, worum es hier genau geht, da kannst du dich schön mit einreihen, oder sitzt du vor dem System? ;)
Aber für die, die offensichtlich wissen ( ) um was es geht:
http://www.veeam.com/de/kb1681
Tags:
#VMSnapShotlöschen #VMware #Veeam #niedrigereGesamt-IOPS
LG
) um was es geht:http://www.veeam.com/de/kb1681
Tags:
#VMSnapShotlöschen #VMware #Veeam #niedrigereGesamt-IOPS
LG
Zitat von @certifiedit.net:
Aber für die, die offensichtlich wissen ( ) um was es geht:
http://www.veeam.com/de/kb1681
Aber für die, die offensichtlich wissen (
) um was es geht:http://www.veeam.com/de/kb1681
Wenn Du DAS gemeint hast, OK. Aber dann hast Du Dich die ganze Zeit seeeeehr missverständlich ausgedrückt.
E.
Zitat von @emeriks:
> Zitat von @certifiedit.net:
>
> Aber für die, die offensichtlich wissen ( ) um was es geht:
>
> http://www.veeam.com/de/kb1681
Wenn Du DAS gemeint hast, OK. Aber dann hast Du Dich die ganze Zeit seeeeehr missverständlich ausgedrückt.
E.
> Zitat von @certifiedit.net:
>
> Aber für die, die offensichtlich wissen (
) um was es geht:>
> http://www.veeam.com/de/kb1681
Wenn Du DAS gemeint hast, OK. Aber dann hast Du Dich die ganze Zeit seeeeehr missverständlich ausgedrückt.
E.
Stimmt, "sys liefert zu wenig IOPS" ist auch ziemlich missverständlich. Ich entschuldige mich hiermit bei allen, die das nicht verstanden haben
LG.
Doch keine Prügelei mehr heute ?
Ich fasse mal zusammen: IOPS?? VEEAM????
Warum zum Geier virtualisiert man einen SBS2008 auf einen ESXi? Der gehört dort nicht drauf. (Punkt) Wenn man sich zusätzliche Fehlerquellen a la der des TO einhandeln möchte, weil man entweder zu viel Zeit hat oder sich nicht nach Hause zu Mutti traut, dann nimmt man einen Hyper-V. Sind genauso viele zusätzliche Probleme möglich, ist aber von Bill autorisiert ...
LG, Thomas
?Ich fasse mal zusammen: IOPS?? VEEAM????
Warum zum Geier virtualisiert man einen SBS2008 auf einen ESXi? Der gehört dort nicht drauf. (Punkt) Wenn man sich zusätzliche Fehlerquellen a la der des TO einhandeln möchte, weil man entweder zu viel Zeit hat oder sich nicht nach Hause zu Mutti traut, dann nimmt man einen Hyper-V
. Sind genauso viele zusätzliche Probleme möglich, ist aber von Bill autorisiert ...LG, Thomas
1
Nein, heute nicht mehr.
Ich versuche nur - ganz pragmatisch - dem Philip zu helfen. Und da hilft es doch nicht wirklich, wenn man pauschal sagt, das Teil kann/darf virtuell nicht laufen und muss/sollte zurück auf Hardware.
Nur - das haben Christian und ich ja schon deutlich gemacht - man bräuchte mal ein paar Zahlen. Und der Philip scheint da gerade nicht dran zu sein ...
E.
Ich fasse mal zusammen: IOPS?? VEEAM????
Warum zum Geier virtualisiert man einen SBS2008 auf einen ESXi? Der gehört dort nicht drauf. (Punkt) Wenn man sich
zusätzliche Fehlerquellen a la der des TO einhandeln möchte, weil man entweder zu viel Zeit hat oder sich nicht nach
Hause zu Mutti traut, dann nimmt man einen Hyper-V. Sind genauso viele zusätzliche Probleme möglich, ist aber von
Bill autorisiert ...
Was qualifiziert einen SBS anders als einen "normalen" Windows Server? Die Tatsache, dass da alle möglichen Sachen auf einer Kiste laufen und dass diese mit angegebenen 1,5 TB recht viel Daten hat, sagt nicht hinreichend etwas über ihre Belastung aus. Mag sein, dass das von M$ not supported ist, aber wenn wir hier uns allein an sowas halten würden, dann könnten wir unser Rechenzentrum gleich zu machen.Warum zum Geier virtualisiert man einen SBS2008 auf einen ESXi? Der gehört dort nicht drauf. (Punkt) Wenn man sich
zusätzliche Fehlerquellen a la der des TO einhandeln möchte, weil man entweder zu viel Zeit hat oder sich nicht nach
Hause zu Mutti traut, dann nimmt man einen Hyper-V
. Sind genauso viele zusätzliche Probleme möglich, ist aber vonBill autorisiert ...
Ich versuche nur - ganz pragmatisch - dem Philip zu helfen. Und da hilft es doch nicht wirklich, wenn man pauschal sagt, das Teil kann/darf virtuell nicht laufen und muss/sollte zurück auf Hardware.
Nur - das haben Christian und ich ja schon deutlich gemacht - man bräuchte mal ein paar Zahlen. Und der Philip scheint da gerade nicht dran zu sein ...
E.
Zitat von @97561:
Moin zusammen,
wir sichern mit Veeam 1,49 TB auf einer VM weg. Leider friert beim Snapshotlöschen die VM ein und die oben genannten Dienste
funktionieren nicht.
Wie kann man das verhindern. Das löschen dauert zwischen 3 - 5 Stunden. Es läuft ein SBS 2008 drauf.
Habt ihr eine Lösung die mir eventuell weiterhilft?
LG
Philip
Moin zusammen,
wir sichern mit Veeam 1,49 TB auf einer VM weg. Leider friert beim Snapshotlöschen die VM ein und die oben genannten Dienste
funktionieren nicht.
Wie kann man das verhindern. Das löschen dauert zwischen 3 - 5 Stunden. Es läuft ein SBS 2008 drauf.
Habt ihr eine Lösung die mir eventuell weiterhilft?
LG
Philip
Hallo Philip,
dieses Problem hatte ich auch einmal.
Die VM verfügte damals über einen verweisten (mittlerweile riesengroßen) Snapshot, sodass der Snapshot-Rollback beim Sichern Stunden dauerte.
Ich habe dann diesen Snapshot gelöscht (hat 7 Stunden gedauert) - seitdem läuft jede Veeam-Sicherung sehr schnell durch.
Wichtig ist auch noch, dass der Veeamproxy über genug Speicherplatz verfügt - laut Veeam mind. 10 Gbyte (darauf wird ja auch bei der Installation von Veeam hingewiesen)
Gruß saber-rider
Moin erstmal und entschuldigt die verspätete Antwort.
Erst einmal folgendes:
Aussagen wie das der SBS nicht virtualisiert werden sollte sind vollkommener Quatsch! Denn folgndes ist auch klar, habt ihr schonmal beim SBS die Netzwerkkarte getauscht? Habt ihr euch schonmal angesehen was passiert wenn sich dei MACs ändern? Ob man dann nicht lieber etwas virtuallisiertes nimmt oder nicht bleibt jedem selbst überlassen.
So grundsätzlich läuft nicht wieder alles stabil und folgendes ist passiert:
1) Sicherung angestoßen nachdem die VSS Writer auf dem SBS nicht stabil liefen und die Veeam Kiste zu wenig Speicher hatte
2) Dann wurde die Sicherung abgebrochen der Snapshot gelöscht
3) VSS stabil neugestartet und dann lief die Sicherung erfolgreich durch
ABER:
Die User haben recht viel in der Nacht auf dem System weitergearbeitet und es wurde eine Vollsicherung durchgeführt. Zudem hatte der WSUS sich noch mit sämtlichen Updates dazwischengeschoben.
Heute läuft wieder alles stabil und die Raten sind in Orndung. Auch die Snapshots laufen gut durch.
Nur folgendes Problem bleibt:
Während der Sicherung friert das System regelmäßig für einige Momente ein. Gerade beim Snapshot löschen passiert dies. Woran das liegt ist mir leider nicht bekannt.
Zum Thema Performance noch folgendes:
- Server ist ausreichend dimoensioniert
- Massig Speicher (32 GB) sind verteilt
- Raid läuft sauber und es sind genügend Reserven vorhanden
- Alle Platten sind SAS Platten
- Anbindung an Veeam via GBit Lan (seperat zum normalen Netzwerk)
- Veeam Workstation hat ebenfalls 16 GB RAM und mehre TBs pro Platte...
So vielen Dank für eure Hilfe bisher, wollte hier keinen Kleinkrieg lostreten... Vielmehr hatte ich gehofft dass das Einfrieren bekannt sei.
Erst einmal folgendes:
Aussagen wie das der SBS nicht virtualisiert werden sollte sind vollkommener Quatsch! Denn folgndes ist auch klar, habt ihr schonmal beim SBS die Netzwerkkarte getauscht? Habt ihr euch schonmal angesehen was passiert wenn sich dei MACs ändern? Ob man dann nicht lieber etwas virtuallisiertes nimmt oder nicht bleibt jedem selbst überlassen.
So grundsätzlich läuft nicht wieder alles stabil und folgendes ist passiert:
1) Sicherung angestoßen nachdem die VSS Writer auf dem SBS nicht stabil liefen und die Veeam Kiste zu wenig Speicher hatte
2) Dann wurde die Sicherung abgebrochen der Snapshot gelöscht
3) VSS stabil neugestartet und dann lief die Sicherung erfolgreich durch
ABER:
Die User haben recht viel in der Nacht auf dem System weitergearbeitet und es wurde eine Vollsicherung durchgeführt. Zudem hatte der WSUS sich noch mit sämtlichen Updates dazwischengeschoben.
Heute läuft wieder alles stabil und die Raten sind in Orndung. Auch die Snapshots laufen gut durch.
Nur folgendes Problem bleibt:
Während der Sicherung friert das System regelmäßig für einige Momente ein. Gerade beim Snapshot löschen passiert dies. Woran das liegt ist mir leider nicht bekannt.
Zum Thema Performance noch folgendes:
- Server ist ausreichend dimoensioniert
- Massig Speicher (32 GB) sind verteilt
- Raid läuft sauber und es sind genügend Reserven vorhanden
- Alle Platten sind SAS Platten
- Anbindung an Veeam via GBit Lan (seperat zum normalen Netzwerk)
- Veeam Workstation hat ebenfalls 16 GB RAM und mehre TBs pro Platte...
So vielen Dank für eure Hilfe bisher, wollte hier keinen Kleinkrieg lostreten... Vielmehr hatte ich gehofft dass das Einfrieren bekannt sei.
Moin nochmal,
LG, Thomas
Aussagen wie das der SBS nicht virtualisiert werden sollte sind vollkommener Quatsch!
die Aussage hat hier auch niemand getroffen?LG, Thomas
Hallo Thomas,
ibezogen auf die "VMWare Teile" - aber vollkommen egal. Das Problem entsteht offenbar immer dann, wenn der Snapshot durch die Rücksicherung lange zum Konsolidieren braucht.
Für uns wäre deshalb das "Einfrieren" noch zu lösen, der Rest hat sich erklärt und ist auch vollkommen in Ordnung.
LG
Philip
ibezogen auf die "VMWare Teile" - aber vollkommen egal. Das Problem entsteht offenbar immer dann, wenn der Snapshot durch die Rücksicherung lange zum Konsolidieren braucht.
Für uns wäre deshalb das "Einfrieren" noch zu lösen, der Rest hat sich erklärt und ist auch vollkommen in Ordnung.
LG
Philip
