11
VMware - ESXi HDD verkleinern möglich?
Hi@all
Vorab der Ist-Zustand:
HP-Server (vmt. ein 350DL) mit einem (aus meiner Erinnerung) Raid6 mit einer Spare-Platte.
Darauf befindet sich eine VM mit W2K16, Windows hat 250GB, Datenlaufwerk aktuell ca 1050GB.
Gesichert wird das Ganze per Veeam B&R
Weil ein paar Fremdtechniker nicht hinter sich aufgeräumt hatten (und ich das leider nicht schnell genug realisiert hatte) ist das Datenlaufwerk immer voller geworden, so dass ich in den zwei Monaten mehrfach das Laufwerk, welches bis dato "nur" ca. 800GB benötigt hat, immer mehr vergrößern musste (schlussendlich auf ca 1070GB, mit einem Rest von ca 85GB.
Leider habe ich es jetzt an einen Punkt gebracht, wo Veeam nicht mehr will, weil es nicht genügend Platz auf dem SSD-Verbund für sich hat ;-( Die täglichen Abendsicherungen (inkrementel) geht mit einer Warnmeldung noch durch, eine 13 Uhr Sicherung mit den Änderungen des Tages auch, aber die Voll-Backups nicht mehr. (alles geht auf eine NAS, eine täglich rollierende SSD für den Transport/Tresor) nimmt dann die gesicherten Daten entgegen
Verkleinern der D ist schon erfolgt, aber ESXi lässt mich die Laufwerke nur vergrößern.
Was kann man sinnvoll noch tun, wo das Kind schon in den Brunnen gefallen ist ?
Am "einfachsten" wäre es natürlich das Backup zurückzuspielen, aber aus obigen Gründen fällt das Flach.
Acronis KÖNNTE noch als Server-Variante uninstalliert rumfliegen, wäre dann aber von ca. 2013 und müsste entsprechend nachinstalliert werden. Dann ein Backup von D, Laufwerk neu aufbauen und Daten zurück?
Oder mittels eines anderen Backup-Programms (welches) ähnlich vorgehen?
Oder mit Robocopy eine Datensicherung anschubbsen und diese zurückspielen?!
Oder eine weitere SSD einbauen und das System damit vergrößern?
Zur Info:
Im Herbst wir das System modernisiert, bis dahin möchte ich es "günstig" lauffähig halten.
Es handelt sich um einen Server, wo auch Datenbanken drauf laufen, da bin ich nicht sicher, ob Robocopy die Online wegsichern mag, deswegen würde ich am liebsten Offline arbeiten.
Vielen Dank für eure Hilfe (und die eine oder andere Mitleidsträne
Gruß´
Carsten
Vorab der Ist-Zustand:
HP-Server (vmt. ein 350DL) mit einem (aus meiner Erinnerung) Raid6 mit einer Spare-Platte.
Darauf befindet sich eine VM mit W2K16, Windows hat 250GB, Datenlaufwerk aktuell ca 1050GB.
Gesichert wird das Ganze per Veeam B&R
Weil ein paar Fremdtechniker nicht hinter sich aufgeräumt hatten (und ich das leider nicht schnell genug realisiert hatte) ist das Datenlaufwerk immer voller geworden, so dass ich in den zwei Monaten mehrfach das Laufwerk, welches bis dato "nur" ca. 800GB benötigt hat, immer mehr vergrößern musste (schlussendlich auf ca 1070GB, mit einem Rest von ca 85GB.
Leider habe ich es jetzt an einen Punkt gebracht, wo Veeam nicht mehr will, weil es nicht genügend Platz auf dem SSD-Verbund für sich hat ;-( Die täglichen Abendsicherungen (inkrementel) geht mit einer Warnmeldung noch durch, eine 13 Uhr Sicherung mit den Änderungen des Tages auch, aber die Voll-Backups nicht mehr. (alles geht auf eine NAS, eine täglich rollierende SSD für den Transport/Tresor) nimmt dann die gesicherten Daten entgegen
Verkleinern der D ist schon erfolgt, aber ESXi lässt mich die Laufwerke nur vergrößern.
Was kann man sinnvoll noch tun, wo das Kind schon in den Brunnen gefallen ist ?
Am "einfachsten" wäre es natürlich das Backup zurückzuspielen, aber aus obigen Gründen fällt das Flach.
Acronis KÖNNTE noch als Server-Variante uninstalliert rumfliegen, wäre dann aber von ca. 2013 und müsste entsprechend nachinstalliert werden. Dann ein Backup von D, Laufwerk neu aufbauen und Daten zurück?
Oder mittels eines anderen Backup-Programms (welches) ähnlich vorgehen?
Oder mit Robocopy eine Datensicherung anschubbsen und diese zurückspielen?!
Oder eine weitere SSD einbauen und das System damit vergrößern?
Zur Info:
Im Herbst wir das System modernisiert, bis dahin möchte ich es "günstig" lauffähig halten.
Es handelt sich um einen Server, wo auch Datenbanken drauf laufen, da bin ich nicht sicher, ob Robocopy die Online wegsichern mag, deswegen würde ich am liebsten Offline arbeiten.
Vielen Dank für eure Hilfe (und die eine oder andere Mitleidsträne
Gruß´
Carsten
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: 672431
Url: https://administrator.de/forum/vmware-esxi-hdd-verkleinern-moeglich-672431.html
Ausgedruckt am: 16.04.2025 um 16:04 Uhr
11 Kommentare
Neuester Kommentar
Ich habe von zwei Methoden gehört, aber beide selbst noch nicht genutzt.
a) Du installierst irgendwo den VMware Converter und "konvertierst" die VM von VMware auf VMware. In dem Prozess kannst du die Platten verkleinern, allerdings brauchst du dann auf dem Target Platz während die VM auf der Quelle bleibt. Wenn Target = Quelle hast du ein Platzproblem wie jetzt auch.
b) Irgendwo habe ich mal gelesen das man die Partition verkleinern kann (das geht z.B. mit gparted) und dann die Dateien auf dem Speicher manipulieren kann. Ich würde da unbedingt von abraten, das ist eher so eine Lösung wo man wirklich 0 Byte frei hat und der Laden steht. Wenn es überhaupt funktioniert.
Ansonsten wäre Restore aus dem inkrementellen Backup (das du hast?) der bessere Weg. Du könntest die Datendateien der aktuellen VM ja runter laden, zur Sicherheit. Und dann den Restore testen.
a) Du installierst irgendwo den VMware Converter und "konvertierst" die VM von VMware auf VMware. In dem Prozess kannst du die Platten verkleinern, allerdings brauchst du dann auf dem Target Platz während die VM auf der Quelle bleibt. Wenn Target = Quelle hast du ein Platzproblem wie jetzt auch.
b) Irgendwo habe ich mal gelesen das man die Partition verkleinern kann (das geht z.B. mit gparted) und dann die Dateien auf dem Speicher manipulieren kann. Ich würde da unbedingt von abraten, das ist eher so eine Lösung wo man wirklich 0 Byte frei hat und der Laden steht. Wenn es überhaupt funktioniert.
Ansonsten wäre Restore aus dem inkrementellen Backup (das du hast?) der bessere Weg. Du könntest die Datendateien der aktuellen VM ja runter laden, zur Sicherheit. Und dann den Restore testen.
Leider ist das letzte Vollbackup jetzt gut 1,5 Wochen alt...
Deswegen würde ich dazu tendieren, dass die Daten frisch gesichert werden und mit einem neuen, verkleinerten zurückgespielt werden. Und an diesem Konstrukt fehlt mir etwas die Erfahrung, wollte also sammeln und gucken, was geht UND sinnvoll ist (zur Not auch das RAID vergößern).
Gruß
Deswegen würde ich dazu tendieren, dass die Daten frisch gesichert werden und mit einem neuen, verkleinerten zurückgespielt werden. Und an diesem Konstrukt fehlt mir etwas die Erfahrung, wollte also sammeln und gucken, was geht UND sinnvoll ist (zur Not auch das RAID vergößern).
Gruß
Hallo
Erlaube bitte ein Frage dazu: Du hast die Veeam BR Installation auf dem gleichen Raid wie die Arbeitsmaschinen als VM? Nein, oder?
Ansonsten, wenn im DL350 noch zwei Slots frei sein sollten, dort ein Raid1 mit 2 SATA SSD 2TB hochgezwirbelt und die Maschine dorthin verschoben. Dann kannst Du sauber zurückmigrieren und verkleinern.
Viel Erfolg,
Macleod
Erlaube bitte ein Frage dazu: Du hast die Veeam BR Installation auf dem gleichen Raid wie die Arbeitsmaschinen als VM? Nein, oder?
Ansonsten, wenn im DL350 noch zwei Slots frei sein sollten, dort ein Raid1 mit 2 SATA SSD 2TB hochgezwirbelt und die Maschine dorthin verschoben. Dann kannst Du sauber zurückmigrieren und verkleinern.
Viel Erfolg,
Macleod
1
In jedem Fall wäre ein weiteres Storage, wenn auch nur temporär, sehr hilfreich.
Moin,
Richte in Veeam B&R mal die Synthetischen FullBackups ein. Dann hast du ein sauberes FullBackup und kannst das für einen Restore nutzen.
Alternativ, wenn irgendwo eine 2TB-Platte rum fliegt: mit Acronis (oder Anschein Reflect) die betroffene Disk sichern, die Disk aus dem VMware Datastore löschen, neue VMDK anlegen und das Acronis-Bsckup für einen Restore nutzen. Der erkennt die kleinere Platte und passt die Partitionsgrösse an. Die VMDK wächst dann ja passend mit.
Richte in Veeam B&R mal die Synthetischen FullBackups ein. Dann hast du ein sauberes FullBackup und kannst das für einen Restore nutzen.
Alternativ, wenn irgendwo eine 2TB-Platte rum fliegt: mit Acronis (oder Anschein Reflect) die betroffene Disk sichern, die Disk aus dem VMware Datastore löschen, neue VMDK anlegen und das Acronis-Bsckup für einen Restore nutzen. Der erkennt die kleinere Platte und passt die Partitionsgrösse an. Die VMDK wächst dann ja passend mit.
Naja shrinken.
Converter oder über die command line clonen. Ohne VCenter geht das auch. Meine man kann thin als Option mit geben.
Kopiervorgang sieht man nur am Ziel. Blockgrösse noch in GB umrechnen.
https://knowledge.broadcom.com/external/article/343140/cloning-and-conve ...
Thin ist da angegeben.
https://github.com/rizviz/clone-vm-esx/blob/main/clone-vm.sh
Geht auch ohne Script. Ist ja nur eine Zeile...
Kopiervorgang könnte man mit watch überwachen...
Nur muss man umrechnen, sonst hat man je nach Blockgrösse eine Überraschung. 😁
Platz muss aber ausreichend da sein. Sonst bleibt nur Backup, das nur belegten Speicher zurück schreibt
Converter oder über die command line clonen. Ohne VCenter geht das auch. Meine man kann thin als Option mit geben.
Kopiervorgang sieht man nur am Ziel. Blockgrösse noch in GB umrechnen.
https://knowledge.broadcom.com/external/article/343140/cloning-and-conve ...
Thin ist da angegeben.
https://github.com/rizviz/clone-vm-esx/blob/main/clone-vm.sh
Geht auch ohne Script. Ist ja nur eine Zeile...
Kopiervorgang könnte man mit watch überwachen...
Nur muss man umrechnen, sonst hat man je nach Blockgrösse eine Überraschung. 😁
Platz muss aber ausreichend da sein. Sonst bleibt nur Backup, das nur belegten Speicher zurück schreibt
1
Hab meine Doku wiedergefunden.
Liegt die VM mit oder ohne Delta vor?
VMDK clonen: vmkfstools -i "WS16-ALTEVM.vmdk" "WS16-NEUEVM.vmdk" -d thin -a buslogic
Delta clonen: vmkfstools -i "WS16-ALTEVM-000003.vmdk" "WS16-NEUEVM.vmdk" -d thin -a buslogic < Snapshot wird zusamemngefügt. Neuer Name ohne Nummern Suffix!
Ziel überwachen - wie weit sind wir?
s = zeigt allocated blocks an. Mit 1024 lässt sich GB errechnen. Hier ca. 23 GB
awk formatiert. Platzhalte $1 und $10 (weichen je nach Parametern ab!) für Größe und VMDK Namen.
ACHTUNG: Ist die Blockgröße. Stimmt die nicht, sind ggf. statt 60 GB dann 120 GB angezeigt. Kopieren wir 60 GB sind wir also bei 120 GB fertig. Muss man ggf. anpassen, um genau den Fortschritt zu sehen!
Ansonsten google bitte selber, wie man die ESXi Blocksize bestimmt und so dann die Ausgabe von ls umrechnet! Es ist auf jeden Fall eine gute Hilfe. Nur wenn die Size falsch ist, ist die VM auf dem Papier doppelt oder dreimal größer. Es passiert aber nix! Ist nur die falsche Umrechnung. Ansonsten siehst du hier aber gut, wenn 9.434 dort stehen, dass ca. 9 GB kopiert worden sind! Bitte dringend beachten !
Neue VM erstellen
1. Neue VM erstellen. Der Name muss exakt dem des Ordners/ des Päfix der VMDK entsprechen. So liegt alles im gleichen Ordner!
2. Einstellungen der neuen VM anpassen. Hier 1x Socket 8 Core -> 2x Socket 4 Core. Durch Sysprep wird die neue HW automatisch erkannt. RAM 12 GB
3. Vorgeschlagene NEUE Festlpatte aus Dialog löschen. Vorhandene Festplatte (../WS16-ASTKassen/WS16-ASTKassen.vmdk) suchen und einbinden.
Wir clonen also nur die Binary Disk Daten. VMX kann man auch so bearbeiten. Erstellt man aber über GUI eine "Zwilling", so reicht das meist völlig aus!
ACHTUNG: UEFI oder BIOS? Gerade bei alten Maschinen ggf. nochmal in die Settings der alten VM schauen!
Wenn die Einstellungen 1:1 passen wird im Prinzip nur die neue, verkleinerte HD eingehängt und wir sind fertig.
Man sieht auch beim Kopieren dass nach Ende der "echten Nutzdaten" da kopieren viel schnell geht.
Liegt die VM mit oder ohne Delta vor?
VMDK clonen: vmkfstools -i "WS16-ALTEVM.vmdk" "WS16-NEUEVM.vmdk" -d thin -a buslogic
Delta clonen: vmkfstools -i "WS16-ALTEVM-000003.vmdk" "WS16-NEUEVM.vmdk" -d thin -a buslogic < Snapshot wird zusamemngefügt. Neuer Name ohne Nummern Suffix!
Ziel überwachen - wie weit sind wir?
1
watch ls -lchas |awk '{print " "$1/1024000" "$10""}' s = zeigt allocated blocks an. Mit 1024 lässt sich GB errechnen. Hier ca. 23 GB
awk formatiert. Platzhalte $1 und $10 (weichen je nach Parametern ab!) für Größe und VMDK Namen.
ACHTUNG: Ist die Blockgröße. Stimmt die nicht, sind ggf. statt 60 GB dann 120 GB angezeigt. Kopieren wir 60 GB sind wir also bei 120 GB fertig. Muss man ggf. anpassen, um genau den Fortschritt zu sehen!
Ansonsten google bitte selber, wie man die ESXi Blocksize bestimmt und so dann die Ausgabe von ls umrechnet! Es ist auf jeden Fall eine gute Hilfe. Nur wenn die Size falsch ist, ist die VM auf dem Papier doppelt oder dreimal größer. Es passiert aber nix! Ist nur die falsche Umrechnung. Ansonsten siehst du hier aber gut, wenn 9.434 dort stehen, dass ca. 9 GB kopiert worden sind! Bitte dringend beachten !
Neue VM erstellen
1. Neue VM erstellen. Der Name muss exakt dem des Ordners/ des Päfix der VMDK entsprechen. So liegt alles im gleichen Ordner!
2. Einstellungen der neuen VM anpassen. Hier 1x Socket 8 Core -> 2x Socket 4 Core. Durch Sysprep wird die neue HW automatisch erkannt. RAM 12 GB
3. Vorgeschlagene NEUE Festlpatte aus Dialog löschen. Vorhandene Festplatte (../WS16-ASTKassen/WS16-ASTKassen.vmdk) suchen und einbinden.
Wir clonen also nur die Binary Disk Daten. VMX kann man auch so bearbeiten. Erstellt man aber über GUI eine "Zwilling", so reicht das meist völlig aus!
ACHTUNG: UEFI oder BIOS? Gerade bei alten Maschinen ggf. nochmal in die Settings der alten VM schauen!
Wenn die Einstellungen 1:1 passen wird im Prinzip nur die neue, verkleinerte HD eingehängt und wir sind fertig.
Man sieht auch beim Kopieren dass nach Ende der "echten Nutzdaten" da kopieren viel schnell geht.
1
PS:
Wir Clonen nur die Platten! Ich hatte mehrere Storage Volume. Normal sollt es auch gehen, wenn du in einen Unterordner clonst. Da der Ordnername dem VM Namen entspricht und auch Pfade so aufgebaut sind, muss es hier in diesem Fall gleich lauten.
Du kannst nachdem clonen die reinen virt. Festplatten auch manuell in die neue VM verschieben. Die haben wir ja ohne HD angelegt.
Es geht hier um einen Clone. Da die Platten verkleinert sind, könntest du diese auch einfach in die org. VM wieder einhängen. Müsste auch gehen.
Wenn du es zum ersten Mal machst wäre aber folgendes ggf. besser, damit du noch zurück kannst:
1. VM herunterfahren
2. VM aus ESXi Inventar entfernen - NICHT von der Platte löschen !
3. VM in eine Unterordner auf dem gleichen Storage verschieben
4. VM clonen
5. VM Einstellungen nachbauen und geclonte Festplatte einhängen
6. Neue/ alte VM in ESXi registrieren - VMX auswählen und ins Inventar aufnehmen.
7. Fertig.
vmkfstools -i "/vmfs/volumes/testnas10/WS16-Master0921/WS16-Master0921-000003.vmdk" "/vmfs/volumes/testnas172/WS16-Neuevm/WS16-Neuevm.vmdk" -d thin -a buslogic
Hier nochmal der komplette Befehl für das clonen von eihen Storage zum anderen. Du würdest die Pfade mit Unterordner etc. anpassen und auch den VM Namen gleich lassen!
Bei mir wurde geclont und mit Sysprep in der VM gearbeitet. Bleiben die Namen gleich hast du eine 1:1 Kopie. Du willst ja nur shrinken!
Beim Clonen hingegen wollen wir ja in eine neue VM clonen, um z.B. aus Master Image VMs zu generieren. Pass bitte hier auf die Sprachwahl auf und was andere dir sagen.
Wenn Pfade und Namen am Ende so aussehen wie in der VMX Datei bist du sicher! Das war es dann.
Hinweis zu den Namen
Die sollte gleich dem der VM sein! Da du aber die Platte einfach einhängst, kann die VMDK auch z.B.
meine-liebe-oma.vmdk
lauten. Trägt das System alles in die VMX ein. Um Verwechselungen zu vermeiden nimmt man den Ziel VM Namen! Der gleiche oder beim "echten" Clone den der produktiven VM: Master.vmdk -> ProdVM-vmdk
Für dich ist nur wichtig, dass beim Kommandozeilen Befehl mit "thin" die Bereitstellung so erfolgt! Und du dann eine kleinere VMDK erhälst!
Wir Clonen nur die Platten! Ich hatte mehrere Storage Volume. Normal sollt es auch gehen, wenn du in einen Unterordner clonst. Da der Ordnername dem VM Namen entspricht und auch Pfade so aufgebaut sind, muss es hier in diesem Fall gleich lauten.
Du kannst nachdem clonen die reinen virt. Festplatten auch manuell in die neue VM verschieben. Die haben wir ja ohne HD angelegt.
Es geht hier um einen Clone. Da die Platten verkleinert sind, könntest du diese auch einfach in die org. VM wieder einhängen. Müsste auch gehen.
Wenn du es zum ersten Mal machst wäre aber folgendes ggf. besser, damit du noch zurück kannst:
1. VM herunterfahren
2. VM aus ESXi Inventar entfernen - NICHT von der Platte löschen !
3. VM in eine Unterordner auf dem gleichen Storage verschieben
4. VM clonen
5. VM Einstellungen nachbauen und geclonte Festplatte einhängen
6. Neue/ alte VM in ESXi registrieren - VMX auswählen und ins Inventar aufnehmen.
7. Fertig.
vmkfstools -i "/vmfs/volumes/testnas10/WS16-Master0921/WS16-Master0921-000003.vmdk" "/vmfs/volumes/testnas172/WS16-Neuevm/WS16-Neuevm.vmdk" -d thin -a buslogic
Hier nochmal der komplette Befehl für das clonen von eihen Storage zum anderen. Du würdest die Pfade mit Unterordner etc. anpassen und auch den VM Namen gleich lassen!
Bei mir wurde geclont und mit Sysprep in der VM gearbeitet. Bleiben die Namen gleich hast du eine 1:1 Kopie. Du willst ja nur shrinken!
Beim Clonen hingegen wollen wir ja in eine neue VM clonen, um z.B. aus Master Image VMs zu generieren. Pass bitte hier auf die Sprachwahl auf und was andere dir sagen.
Wenn Pfade und Namen am Ende so aussehen wie in der VMX Datei bist du sicher! Das war es dann.
Hinweis zu den Namen
Die sollte gleich dem der VM sein! Da du aber die Platte einfach einhängst, kann die VMDK auch z.B.
meine-liebe-oma.vmdk
lauten. Trägt das System alles in die VMX ein. Um Verwechselungen zu vermeiden nimmt man den Ziel VM Namen! Der gleiche oder beim "echten" Clone den der produktiven VM: Master.vmdk -> ProdVM-vmdk
Für dich ist nur wichtig, dass beim Kommandozeilen Befehl mit "thin" die Bereitstellung so erfolgt! Und du dann eine kleinere VMDK erhälst!
Moin zusammen,
sorry für mein spätes Feedback..
Ein guter Freund, erfahrener Administrator UND der eigentliche Erschaffer der Servers inkl Backup hat versucht mir zu helfen, erfolglos.
Das Backup hört IMMER bei 420 +- 15 GB auf zu arbeiten.
Nur das C-Laufwerk zu sichern (250GB Partition, ca 200 GB Daten) funktioniert reibungslos. Das D-Laufwerk (ca 1050GB, davon aktuell ca 830 GB Daten) bricht sowohl als Einzelsicherung ab, als auch im Verbund mit der Sicherung von C.
Ich glaube, dass die Warnmeldung vom Veeam nur eine Warnmeldung ist, mehr nicht.
Wir haben ALLE Jobs (2 an der Zahl) neu erstellt, die Repositories geändert (da war aber auch ein Bug drin), mit den "Veeam-Administratoren" gespielt.. Ergebnis siehe oben.
Der Kumpel spürt, dass das im Zusammenhang mit dem Löschen der Daten, speziell irgendwelcher Freigaben/Berechtigungen) der externen Mitarbeiter liegt..
Ich kann das fast nicht glauben, aber hier fehlt mir die Erfahrung.
Habt ihr da noch einen Tipp?
Und ganz wichtig:
Soll ich eher einen neuen Thread dazu aufmachen?
Danke und Gruß
Carsten
Habt
sorry für mein spätes Feedback..
Ein guter Freund, erfahrener Administrator UND der eigentliche Erschaffer der Servers inkl Backup hat versucht mir zu helfen, erfolglos.
Das Backup hört IMMER bei 420 +- 15 GB auf zu arbeiten.
Nur das C-Laufwerk zu sichern (250GB Partition, ca 200 GB Daten) funktioniert reibungslos. Das D-Laufwerk (ca 1050GB, davon aktuell ca 830 GB Daten) bricht sowohl als Einzelsicherung ab, als auch im Verbund mit der Sicherung von C.
Ich glaube, dass die Warnmeldung vom Veeam nur eine Warnmeldung ist, mehr nicht.
Wir haben ALLE Jobs (2 an der Zahl) neu erstellt, die Repositories geändert (da war aber auch ein Bug drin), mit den "Veeam-Administratoren" gespielt.. Ergebnis siehe oben.
Der Kumpel spürt, dass das im Zusammenhang mit dem Löschen der Daten, speziell irgendwelcher Freigaben/Berechtigungen) der externen Mitarbeiter liegt..
Ich kann das fast nicht glauben, aber hier fehlt mir die Erfahrung.
Habt ihr da noch einen Tipp?
Und ganz wichtig:
Soll ich eher einen neuen Thread dazu aufmachen?
Danke und Gruß
Carsten
Habt
Jede Backup Software der letzten 10 - 15 Jahre lässt sich meist Offline problemlos verwenden. Jahr 2013 ist also kein Problem.
Abbrüche können auch bei virt. Festplatten auf defekt hinweisen - i/o....
1 TB kann man leicht aufteilen und die Pfade alle behalten - Mit z.B. junction arbeiten. Programme wie Mailstore lassen sich später noch anpassen. Store verschieben und wieder einhängen....
Unter Windows/ Linux ist es durchaus legitim Dateien via z.B. robocopy, rsync zu kopieren. Normal hat man ein Konzept und es lässt es nicht soweit kommen. Hier ist es aber nun egal.
Ich würde die Daten selektieren - was ist gerade wichtig und wird verwendet und was liegt seit Jahren als Archiv da. OS separat betrachten.
Du sicherst also OS als Image Wenn die 2. Platte nicht da ist und da Exchange, SQL oder Mailstore drauf läuft passier genau was? Anwendungen starten nur nicht mehr.
Außer Active Directory und Systemdateien kann man vieles verschieben, neu in Ordner einsortieren, etc. Passt nicht immer, aber sehr häufig!
Selektion, Unterteilung in Pfade die zu Diensten (SQL, Exchange, aktiven Profile) gehören mal durchführen. Die Tages aktuellen Daten mit robocopy auf andere Platte sichern. Kann virt. sein oder externe - USB.
Du musst dich freischwimmen! Entweder jetzt neuer Server oder zumindest aber die Daten unterteilen. Fehlt später was, kann man es einfach wieder rüber kopieren und gut ist. Programme und Dienste sind knallhart. Die machen sonst einfach nix. Man kann zwar nicht arbeiten, hat aber zunächst keinen Verlust oder Schaden! Nur Downtime.
Du merkst beim Kopieren auch rasch wo es ggf. hakt.
Eine andere Methode wäre die Daten forensisch zu sichern. Oder Der Backupsoftware blockweise Sicherung aufzudrücken und Fehler zu ignorieren. Damit die Sicherung durchläuft.
Nur auch dann hast du wieder einen großen Block da rumliegen. Da ihr eh erstmal frickeln wollte - warum auch immer - wäre es aber nun an der Zeit als erstes mal sich einen Überblick zu verschaffen!
Ein guter Test ist auch das umbenennen von Ordnern. Wenn das geht, greift kein anders Programm darauf zu!
In User Profile sammelt sich mitunter viel Müll. Man muss ja auch Firefox nicht 1:1 kopieren. Es reichen weniger als 10 Dateien um Passwörter und Historie hinzubekommen.
Bei anderen Programmen ist es teils ähnlich!
Du musst dich erstmal freischwimmen. 1 oder besser 2 USB Platten. Dann hättest du auch gerade/ ungerade Tage oder was auch immer eingehalten. Wenn die Daten dort einmal hin kopiert wurden, waren sie zumindest ja lesbar.
Beim Kopieren gibt es oft kein grau. Entweder es geht oder es geht nicht. Wenn die Daten also gesichert wurden - durch Dateikopie - kann man schonmal sagen dass du dann ein lauffähiges Backup der Daten hast!
1 TB klingt viel. Auch mit 1 GBit/s Ethernet oder USB 3 aber noch im Rahmen. Die Sicherung kann hier sogar erfolgen, wenn der Server eingeschaltet ist. Geringere Downtime.
Wenn du alles soweit mal wegkopiert hast, könnte man die jetzige VM HD löschen und zurück kopieren.
Euer Hauptproblem scheint ja gerade zu sein, dass ihr nicht genau wisst wie sich die über 1 TB aufteilen! Mal was loschen / verschieben / auslagern.
Wir hatten auch einmal WSUS mit 2 TB in Acronis - geht problemlos!
Wenn die Sicherung stockt kann es immer noch an Lesefehlern liegen. Wenn es kein Image ist ggf. auch was triviales wie der Virenscanner.
Es gibt nun viele Optionen:
- Image von C
- Offline-Image über Acronis ISO
- Dateien via Sync Tools wegkopieren
- Dateien unterteilen und nur bestimmte Pfade in Acronis Dateisicherung aufnehmen
- Dateien ohne Zugriff in den letzten Monaten - PowerShell Script ermitteln und sich den Pfad ansehen. Ggf. nur Datenbunker, der so wegkopiert werden kann und nicht zwingend wiederherstellt werden muss
Du musst wirklich dir einmal genau die Daten ansehen! So wie nur der Verdacht von I/O Fehler im Raum steht versuchen die lebenswichtigen, tagesaktuellen Dateien wegzukopieren.
USB Platten sind relativ günstig und einfach. Selbst die Sicherung auf Datenträgern die nicht für die Langzeitspeicherung gedacht sind ist erst mal besser als keine Sicherung zu haben.
So schnell schimmeln die Daten nicht. Du musst nur irgendwie jetzt einen Plan haben! Global Shrinken oder Backup Programm Wechsel muss da nicht der Beste sein!
Abbrüche können auch bei virt. Festplatten auf defekt hinweisen - i/o....
1 TB kann man leicht aufteilen und die Pfade alle behalten - Mit z.B. junction arbeiten. Programme wie Mailstore lassen sich später noch anpassen. Store verschieben und wieder einhängen....
Unter Windows/ Linux ist es durchaus legitim Dateien via z.B. robocopy, rsync zu kopieren. Normal hat man ein Konzept und es lässt es nicht soweit kommen. Hier ist es aber nun egal.
Ich würde die Daten selektieren - was ist gerade wichtig und wird verwendet und was liegt seit Jahren als Archiv da. OS separat betrachten.
Du sicherst also OS als Image Wenn die 2. Platte nicht da ist und da Exchange, SQL oder Mailstore drauf läuft passier genau was? Anwendungen starten nur nicht mehr.
Außer Active Directory und Systemdateien kann man vieles verschieben, neu in Ordner einsortieren, etc. Passt nicht immer, aber sehr häufig!
Selektion, Unterteilung in Pfade die zu Diensten (SQL, Exchange, aktiven Profile) gehören mal durchführen. Die Tages aktuellen Daten mit robocopy auf andere Platte sichern. Kann virt. sein oder externe - USB.
Du musst dich freischwimmen! Entweder jetzt neuer Server oder zumindest aber die Daten unterteilen. Fehlt später was, kann man es einfach wieder rüber kopieren und gut ist. Programme und Dienste sind knallhart. Die machen sonst einfach nix. Man kann zwar nicht arbeiten, hat aber zunächst keinen Verlust oder Schaden! Nur Downtime.
Du merkst beim Kopieren auch rasch wo es ggf. hakt.
Eine andere Methode wäre die Daten forensisch zu sichern. Oder Der Backupsoftware blockweise Sicherung aufzudrücken und Fehler zu ignorieren. Damit die Sicherung durchläuft.
Nur auch dann hast du wieder einen großen Block da rumliegen. Da ihr eh erstmal frickeln wollte - warum auch immer - wäre es aber nun an der Zeit als erstes mal sich einen Überblick zu verschaffen!
Ein guter Test ist auch das umbenennen von Ordnern. Wenn das geht, greift kein anders Programm darauf zu!
In User Profile sammelt sich mitunter viel Müll. Man muss ja auch Firefox nicht 1:1 kopieren. Es reichen weniger als 10 Dateien um Passwörter und Historie hinzubekommen.
Bei anderen Programmen ist es teils ähnlich!
Du musst dich erstmal freischwimmen. 1 oder besser 2 USB Platten. Dann hättest du auch gerade/ ungerade Tage oder was auch immer eingehalten. Wenn die Daten dort einmal hin kopiert wurden, waren sie zumindest ja lesbar.
Beim Kopieren gibt es oft kein grau. Entweder es geht oder es geht nicht. Wenn die Daten also gesichert wurden - durch Dateikopie - kann man schonmal sagen dass du dann ein lauffähiges Backup der Daten hast!
1 TB klingt viel. Auch mit 1 GBit/s Ethernet oder USB 3 aber noch im Rahmen. Die Sicherung kann hier sogar erfolgen, wenn der Server eingeschaltet ist. Geringere Downtime.
Wenn du alles soweit mal wegkopiert hast, könnte man die jetzige VM HD löschen und zurück kopieren.
Euer Hauptproblem scheint ja gerade zu sein, dass ihr nicht genau wisst wie sich die über 1 TB aufteilen! Mal was loschen / verschieben / auslagern.
Wir hatten auch einmal WSUS mit 2 TB in Acronis - geht problemlos!
Wenn die Sicherung stockt kann es immer noch an Lesefehlern liegen. Wenn es kein Image ist ggf. auch was triviales wie der Virenscanner.
Es gibt nun viele Optionen:
- Image von C
- Offline-Image über Acronis ISO
- Dateien via Sync Tools wegkopieren
- Dateien unterteilen und nur bestimmte Pfade in Acronis Dateisicherung aufnehmen
- Dateien ohne Zugriff in den letzten Monaten - PowerShell Script ermitteln und sich den Pfad ansehen. Ggf. nur Datenbunker, der so wegkopiert werden kann und nicht zwingend wiederherstellt werden muss
Du musst wirklich dir einmal genau die Daten ansehen! So wie nur der Verdacht von I/O Fehler im Raum steht versuchen die lebenswichtigen, tagesaktuellen Dateien wegzukopieren.
USB Platten sind relativ günstig und einfach. Selbst die Sicherung auf Datenträgern die nicht für die Langzeitspeicherung gedacht sind ist erst mal besser als keine Sicherung zu haben.
So schnell schimmeln die Daten nicht. Du musst nur irgendwie jetzt einen Plan haben! Global Shrinken oder Backup Programm Wechsel muss da nicht der Beste sein!
Zitat von @cardisch:
Das Backup hört IMMER bei 420 +- 15 GB auf zu arbeiten.
Ich glaube, dass die Warnmeldung vom Veeam nur eine Warnmeldung ist, mehr nicht.
Wir haben ALLE Jobs (2 an der Zahl) neu erstellt, die Repositories geändert (da war aber auch ein Bug drin), mit den "Veeam-Administratoren" gespielt.. Ergebnis siehe oben.
Also du hast nirgendwo die Warnmeldung gepostet, aber eine Warnmeldung ist eine Warnmeldung, eine Fehlermeldung ist keine Warnmeldung. Es wäre schon toll zu wissen, was Veeam sagt, um sich darauf eine Meinung zu bilden. Und ist das Backup nun vollständig, oder nicht? Auch das sollte Veeam eigentlich sagen können.Das Backup hört IMMER bei 420 +- 15 GB auf zu arbeiten.
Ich glaube, dass die Warnmeldung vom Veeam nur eine Warnmeldung ist, mehr nicht.
Wir haben ALLE Jobs (2 an der Zahl) neu erstellt, die Repositories geändert (da war aber auch ein Bug drin), mit den "Veeam-Administratoren" gespielt.. Ergebnis siehe oben.
Der Kumpel spürt, dass das im Zusammenhang mit dem Löschen der Daten, speziell irgendwelcher Freigaben/Berechtigungen) der externen Mitarbeiter liegt..
Sry aber mein Gras ist alle, ich kann das nicht spüren.Dein Problem ist wenig Speicherplatz. Eventuell zu wenig, für das aktuelle Backup. Sehr wenig, für Snapshots, die man ja vielleicht mal braucht. Definitiv zu wenig, für eine Rücksicherungstest. Du hast ein produktives System, das möglicherweise wegen diesem Problem ausfallen könnte. Ich würde das nicht wollen.
1
