14
SDELETE -z auf Produktiv-Server
Hi,
muss man Bedenken haben, wenn man SDELETE mit Option -z auf einem produktiven Server einsetzt?
Laut Beschreibung (und so wie ich es sehen kann) erzeugt SDELETE eine Datei auf dem Laufwerk - so groß wie möglich, sprich so groß wie freier Platz verfügbar - und füllt diese mit Null-Bytes. Anschließend löscht es die Datei.
Bedeutet das nicht, dass das Laufwerk zum Ende hin kurzzeitig voll ist (0 % frei) und dass dadurch aktive Prozesse dann u.U. ihre Daten nicht runterschreiben können? Oder ist da eine Sicherheitsreserve eingebaut, welche SDLETE an freien Platz auf der Platte belässt?
Weiß das jemand?
E.
muss man Bedenken haben, wenn man SDELETE mit Option -z auf einem produktiven Server einsetzt?
Laut Beschreibung (und so wie ich es sehen kann) erzeugt SDELETE eine Datei auf dem Laufwerk - so groß wie möglich, sprich so groß wie freier Platz verfügbar - und füllt diese mit Null-Bytes. Anschließend löscht es die Datei.
Bedeutet das nicht, dass das Laufwerk zum Ende hin kurzzeitig voll ist (0 % frei) und dass dadurch aktive Prozesse dann u.U. ihre Daten nicht runterschreiben können? Oder ist da eine Sicherheitsreserve eingebaut, welche SDLETE an freien Platz auf der Platte belässt?
Weiß das jemand?
E.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 292272
Url: https://administrator.de/contentid/292272
Printed on: April 24, 2024 at 04:04 o'clock
14 Comments
Latest comment
Hallo Emeriks,
kann ich nur dringend von abraten, das Tool bitte nur bei nicht genutzten Datenträgern anwenden, bei live Servern bekommst du mächtig Freude mit abgestürzten und sich abrupt beendenden Diensten.
Ein Kollege kann dir ein Lied davon singen, hat der nur einmal und nie wieder gemacht, das war Ihm eine Lehre.
Hatte das damals mal zum Spaß an der Freud auf einem virtualisierten Exchange auf dem unter anderem noch DFS und SQL-Server liefen nachgestellt... Ergebnis: Diverse Dienste streikten nach einer Weile Aktivität von sdelete. Beim Neustart dann sogar ein Bluescreen der sich aber nach dem zweiten Reboot verflüchtigte, die Exchange DB hatte wohl auch eine kleine "Inkontinenz" die sich aber mit eseutil wieder zurecht biegen ließ.
Fazit: Bitte nicht nachmachen und den Server vorher runterfahren und das offline tun außer du brauchst neue Herausforderungen oder bist Risikogeil
Grüße Uwe
kann ich nur dringend von abraten, das Tool bitte nur bei nicht genutzten Datenträgern anwenden, bei live Servern bekommst du mächtig Freude mit abgestürzten und sich abrupt beendenden Diensten.
Ein Kollege kann dir ein Lied davon singen, hat der nur einmal und nie wieder gemacht, das war Ihm eine Lehre.
Hatte das damals mal zum Spaß an der Freud auf einem virtualisierten Exchange auf dem unter anderem noch DFS und SQL-Server liefen nachgestellt... Ergebnis: Diverse Dienste streikten nach einer Weile Aktivität von sdelete. Beim Neustart dann sogar ein Bluescreen der sich aber nach dem zweiten Reboot verflüchtigte, die Exchange DB hatte wohl auch eine kleine "Inkontinenz" die sich aber mit eseutil wieder zurecht biegen ließ.
Fazit: Bitte nicht nachmachen und den Server vorher runterfahren und das offline tun außer du brauchst neue Herausforderungen oder bist Risikogeil
Grüße Uwe
Nun eine Aktive Datenbank wird sicherlich danach nicht mehr brauchbar sein da die Updaten möchte und bei 0 Speicherplatz ihre Daten Anfängt zu überschreiben aber nicht mehr alles reingeht.
Kollege hat mit sowas mal nicht nur die DB unwiederruflich geschrottet sondern auch alle eingehende Mails als 0 Byte angenommen.
Und Remote einloggen ging danach auch nicht mehr da der Dienst abgeschmiert ist da er die Logdatei nicht mehr schreiben konnte...
Aber sowas macht man nur im Offline Modus.
Und wenn du eine SSD hast siehst das ganze wieder anders aus xD
Aber jeder Versuch macht Klug ;)
Kollege hat mit sowas mal nicht nur die DB unwiederruflich geschrottet sondern auch alle eingehende Mails als 0 Byte angenommen.
Und Remote einloggen ging danach auch nicht mehr da der Dienst abgeschmiert ist da er die Logdatei nicht mehr schreiben konnte...
Aber sowas macht man nur im Offline Modus.
Und wenn du eine SSD hast siehst das ganze wieder anders aus xD
Aber jeder Versuch macht Klug ;)
Hallo,
auch sollte man dies Tool nicht auf Virtualisierungsplattformen einsetzen wo Storages nach dem Thin-Prinzip genutzt werden.
Stefan
auch sollte man dies Tool nicht auf Virtualisierungsplattformen einsetzen wo Storages nach dem Thin-Prinzip genutzt werden.
Stefan
Zitat von @StefanKittel:
auch sollte man dies Tool nicht auf Virtualisierungsplattformen einsetzen wo Storages nach dem Thin-Prinzip genutzt werden.
Zum shrinken von aufgeblähten thin provisioned vhds ist es unter Windows aber ganz nützlich ..., offline versteht sich natürlich.auch sollte man dies Tool nicht auf Virtualisierungsplattformen einsetzen wo Storages nach dem Thin-Prinzip genutzt werden.
Gruß grexit
Moin @122990,
Gruß,
Dani
Zitat von @122990:
Gruß grexit
Bietet dafür Microsoft nicht auch schon eine Funktionen im Hyper-V an?Zitat von @StefanKittel:
auch sollte man dies Tool nicht auf Virtualisierungsplattformen einsetzen wo Storages nach dem Thin-Prinzip genutzt werden.
Zum shrinken von aufgeblähten thin provisioned vhds ist es unter Windows aber ganz nützlich ..., offline versteht sich natürlich.auch sollte man dies Tool nicht auf Virtualisierungsplattformen einsetzen wo Storages nach dem Thin-Prinzip genutzt werden.
Gruß grexit
Gruß,
Dani
Schon, aber die arbeitet weniger effektiv wenn man die VM nicht vorher defragementiert und den nicht belegten Speicher nicht vorher mit Nullen überschreibt.
Gruß grexit
Gruß grexit
Zitat von @122990:
Schon, aber die arbeitet weniger effektiv wenn man die VM nicht vorher defragementiert und den nicht belegten Speicher nicht vorher mit Nullen überschreibt.
Schon, aber die arbeitet weniger effektiv wenn man die VM nicht vorher defragementiert und den nicht belegten Speicher nicht vorher mit Nullen überschreibt.
Dennoch lohnt es sich immer wieder einmal, darüber nachzudenken, in welchem Verhältnis Aufwände und Risiken zu den tatsächlichen Verbesserungen bestehen. "Gesundes Mittelmaß" ftw.
Wie groß wäre denn der gemessene Unterschied zwischen einer "uneffektiven" und einer "effektiven" Optimierung?
Zitat von @117471:
Dennoch lohnt es sich immer wieder einmal, darüber nachzudenken, in welchem Verhältnis Aufwände und Risiken zu den tatsächlichen Verbesserungen bestehen. "Gesundes Mittelmaß" ftw.
Wie groß wäre denn der gemessene Unterschied zwischen einer "uneffektiven" und einer "effektiven" Optimierung?
Also ein Beispiel aus meiner Praxiserfahrung:Dennoch lohnt es sich immer wieder einmal, darüber nachzudenken, in welchem Verhältnis Aufwände und Risiken zu den tatsächlichen Verbesserungen bestehen. "Gesundes Mittelmaß" ftw.
Wie groß wäre denn der gemessene Unterschied zwischen einer "uneffektiven" und einer "effektiven" Optimierung?
- Thin-Provisioned VHDX mit angewachsener Größe von 500GB.
- Belegt waren darin effektiv 250GB
- Größe nach Shrinking ohne weitere Maßnahmen mit 2maligen Anwenden Optimize-VHD = 420GB
- Größe nach Shrinking mit vorherigem defragmentieren und überschreiben der nicht belegten Bereiche mit sdelete -z und anschließendem Optimize-VHD = 260GB
Denke das sagt alles
Zitat von @122990:
Denke das sagt alles
Dem kann ich auch zustimmen, bei akuten Platzproblemen macht diese Methode eindeutig mehr Platz frei, als die reine Verwendung von Optimize-VHD.Denke das sagt alles
Grüße Uwe
Zitat von @colinardo:
Dem kann ich auch zustimmen, bei akuten Platzproblemen macht diese Methode eindeutig mehr Platz frei, als die reine Verwendung von Optimize-VHD.
Dem kann ich auch zustimmen, bei akuten Platzproblemen macht diese Methode eindeutig mehr Platz frei, als die reine Verwendung von Optimize-VHD.
O.K., wenn die Differenz so krass ist, wäre das natürlich eine Mühe wert.
Allerdings stellt sich mir dann die Frage, ob es nicht klüger ist, die virtuelle Platte in einem anderen System zu mounten und von dort zu beackern. Aber dazu haben Dir ja auch schon die Kollegen geraten
Zitat von @117471:
Allerdings stellt sich mir dann die Frage, ob es nicht klüger ist, die virtuelle Platte in einem anderen System zu mounten und von dort zu beackern. Aber dazu haben Dir ja auch schon die Kollegen geraten
Na das ist ja bei der Methode sowieso obligatorisch (aus einer VM sich selbst die VHD optimieren wie soll das denn auch gehen?? Allerdings stellt sich mir dann die Frage, ob es nicht klüger ist, die virtuelle Platte in einem anderen System zu mounten und von dort zu beackern. Aber dazu haben Dir ja auch schon die Kollegen geraten
) ...Macht man natürlich bei heruntergefahrener VM auf dem Host.
Hallo am Alle,
Danke für Eure Rückmeldungen!
Ja, es geht um eine VM unter VMware. Thick VMDK auf Thin SAN LUN (NetApp). Die NetApp meldet stetig Datenzuwachs im Volume, obwohl die Laufwerke aus VM-Sicht kaum voller werden. Ich habe aber ein Laufwerk ausgemacht, auf welchem von einem Server-Dienst (PACS) sehr exzessiv temporäre Daten geschrieben und kurz danach wieder gelöscht werden. Da NTFS die gelöschten Blöcke nicht sofort überschreibt bleiben diese Blöcke aus Sicht des SAN weiterhin als "benutzt". Hier kommen so ca. 90-100 GB die Woche zusammen. Die Idee ist, diese Blöcke einmal wöchentlich auszunullen.
Plan B: Da dieses Laufwerk fast ausschließlich nur für diese temporären Bewegungsdaten ist, überlege ich, das Laufwerk so zu verkleinern, dass Windows die Blöcke laufend überschreiben muss. Allerdings kann ich nicht 100% abschätzen, wie groß das Laufwerk min. sein muss. (z.Z. >600 GB frei). Hier werde ich aber mal den Hersteller abfragen.
Ich überlege ernsthaft mir eine eigene kleine Anwendung zu schreiben, welche mir z.B. Null-Byte-Dateien erzeugt, dabei aber auf freibleienden Speicherplatz achtet ...
Andere Ideen?
E.
Danke für Eure Rückmeldungen!
Ja, es geht um eine VM unter VMware. Thick VMDK auf Thin SAN LUN (NetApp). Die NetApp meldet stetig Datenzuwachs im Volume, obwohl die Laufwerke aus VM-Sicht kaum voller werden. Ich habe aber ein Laufwerk ausgemacht, auf welchem von einem Server-Dienst (PACS) sehr exzessiv temporäre Daten geschrieben und kurz danach wieder gelöscht werden. Da NTFS die gelöschten Blöcke nicht sofort überschreibt bleiben diese Blöcke aus Sicht des SAN weiterhin als "benutzt". Hier kommen so ca. 90-100 GB die Woche zusammen. Die Idee ist, diese Blöcke einmal wöchentlich auszunullen.
Plan B: Da dieses Laufwerk fast ausschließlich nur für diese temporären Bewegungsdaten ist, überlege ich, das Laufwerk so zu verkleinern, dass Windows die Blöcke laufend überschreiben muss. Allerdings kann ich nicht 100% abschätzen, wie groß das Laufwerk min. sein muss. (z.Z. >600 GB frei). Hier werde ich aber mal den Hersteller abfragen.
Ich überlege ernsthaft mir eine eigene kleine Anwendung zu schreiben, welche mir z.B. Null-Byte-Dateien erzeugt, dabei aber auf freibleienden Speicherplatz achtet ...
Andere Ideen?
E.
Hallo @emeriks,
Gruß,
Dani
Ja, es geht um eine VM unter VMware. Thick VMDK auf Thin SAN LUN (NetApp). Die NetApp meldet stetig Datenzuwachs im Volume, obwohl die Laufwerke aus VM-Sicht kaum voller werden.
Da du "LUN" geschrieben hast gehe ich davon aus, dass die Datastores via iSCSI angebunden sind?! Besteth die Möglichkeit auch NFS zu nutzen? Ich meine bei Block-Level (FC, ISCSI) bekommt das Storage nicht mit, ob Speicherplatz frei wird. Darum müssten die Werte von vSphere und Netapp die Zahlen abweichen. Mit NFS fällt die Ebene "LUN" heraus. Schau dir diesen Blogartikel dazu an.Gruß,
Dani
Nein, FC.
Und der Link bezieht sich auf NFS, nicht auf iSCSI !
Und der Link bezieht sich auf NFS, nicht auf iSCSI !
