Schnattis Server wird gewartet

[drdope]

Warum - sorry, falls die Frage behämmert ist - wäre es bspw. ungeschickt einfach die RAID-Synchro zu nutzen?
Quasi bei Backup-Bedarf eine "Backup-HDD" in eine freie Bay und synchronisieren lassen, indem ich sie als secondary deklariere? Weil's nur bei heruntergefahrenen VMs funktioniert?

Weil du jedesmal ein resynct machen mußt = die Integrität des Raid1 kompromitierst.
Wenn dir nun die andere HDD verreckt, hast du ein Problem...

Im Ernst: Diese fiesen Warnungen (ich müsste mal einen Screenshot liefern) beim RAID-Einrichten - bedeuten die tatsächlich, dass alle betroffenen HDDs beim Erstellen des Arrays komplett gecleant werden?

Leider ja... idR schreiben Raidcontroller eine Signatur auf die HDDs, die sie als Teil des Raidsets markiert.

Thema Backupsoftware:
Wenn du den kompletten ESXi inkl. VMs sichern willst, solltest du das Offline machen; Offline heißt hier -> ESXi und VMs laufen nicht.
Es wird ein externes OS gebootet (z.B. Acronis True Image, gpartetd), daß auch ein graphische Benutzeroberfläche bietet.
Im laufenden Betrieb kommst du aus den VMs nicht an den ESXi dran (ok geht schon irgendwie, aber das nennen wir gerade Spectre/Meltdown).
Laufende DBs sichern, ist immer ein bissl kritisch, wenn die Backupsoftware nicht weiss, daß da eine DB löppt.

Deine aktuelle Backupstrategie schaut ja so aus:
- DB des virtuellen Servers wird gesichert
- Office-Dokumente werden gesichert.

Macht der Server komplett die Grätsche, mußt du im Worst Case den ESXi neu aufsetzen/Einrichten, 2 VMs anlegen, dort jeweils ein passendes OS installieren und updates einspielen,
DB-Software installieren/aktualisieren und dann die Backups zurück spielen...
In der Zwischenzeit übernimmt der Zentralclient mit dem letzten VM-Server-DB-Backup dessen Funktion.

Vorteilhaft wäre es z.B. wenn du einigermaßen aktuelle Images der VMs bzw. deren VMDK- und Configdateien am Start hast, daß würde den Wiederherstellungsprozess deutlich beschleunigen.
Im Optimalfall hast du später auf den "Backupserver" schon einen ESXi installiert; dort befinden sich 1:1 Kopien der beiden VMs (powered down; mit identischen IP-Adressen; damit du an den Clients nicht ändern mußt).
Und im Worst Case A (Hauptserver geht platt) mußt du auf dem Backupserver nur das aktuellste DB-Backup einspielen, um weiter arbeiten zu können...
Aber auch das schützt nicht vor Feuer/Wasser/Diebstahl... sondern würde nur den Ausfall vom Hauptserver abdecken.

PS
Ich sehe einen Drehmel/eine Flex in deiner Zukunft...

Schaut das in allen Schächten so aus, oder sind nur einzelne nicht benutzbar... sehr strange...

[Schnatti]

Ok, das Resynchronisieren zu diesem Zweck funktioniert also per se, ist aber ein No-Go.
Das war mir soweit bewusst, dass es nicht optimal ist, aber im Sinne von "Die andere/abgeklemmte Mirror-HDD kann ja, falls das Sync schiefgeht, hinterher das RAID1 auch wieder neuaufbauen, also hat man ja ein Backup (wenn nicht gerade beide Sync scheitern)" fand ich das nicht generell abwegig. Zumindest solange ich ja keine der von dir aufgezeigten Backup-Software-Lösungen habe...

Das Problem meines großen Serverausfalles bestünde mindestens darin, dass ich weder ESXi-, noch auch nur ein Betriebssystem, geschweige denn die DB-Software hier auf Datenträger liegen habe...die Installationen hat der Admin gemacht und von welchen Medien das kam, weiß ich nicht.
Würde mich auch nicht mal wundern, wenn die DB-Software mir gar nicht als CD/DVD zur Verfügung stehen "darf", sondern nur von einem Techniker der Softwarefirma vor Ort installiert wird. Das war zumindest bei der Ersteinrichtung der Fall, dafür läuft die Serversoftware mit Sicherheit auch zu komplex, als dass ich da mal eben was reinstalliere.

Dass der Zentralclient währenddessen hoffentlich durchhält und weiterwerkelt, das nehme ich erstmal als gesetzt, aber den Server in puncto dessen HDD-Inhalt mal eben zeitnah neu aufzusetzen, die Möglichkeit wäre aktuell gar nicht gegeben.
Drum war ja meine samstagnächtliche Befürchtung, dass das ESXi auch nach Rückbau der Hardware nicht laden möchte, so groß.
Halten wir fest: Der Server DARF nicht abschmieren.

Die Frage ist, was perspektivisch blöder ist:
Das RAID1 nochmal komplett mit beiden/allen drei Festplatten und Controller in den anderen Server zu migrieren und zu hoffen, dass ich es dort zum Laufen bekomme (genau das habe ich ja vorletzte Nacht so naiv in Angriff genommen)
ODER
Nur eine HDD samt Controller zu migrieren und das RAID1 dort versuchen neu aufbauen zu lassen.

Geht 1 richtig schief und ich cleane alleine beim RAID-Einrichten die HDDs versehentlich, habe ich hinterher gar nix mehr in der Hand.
Bei 2 habe ich die ganze Zeit ein unfunktionables RAID, aber die Gefahr eines Totalverlustes ist doch deutlich geringer, oder?

Leider ja... idR schreiben Raidcontroller eine Signatur auf die HDDs, die sie als Teil des Raidsets markiert.

Hier wird's ja auch wieder spannend.
Ich kann also nicht "einfach" einen neuen Controller nehmen und 2 im RAID1 laufende HDD auf diesen "übertragen", weil der Controller für seine Zuordnung dieser Platten in's Set diese erstmal plätten würde? Hurra...
Nicht, dass ich das jetzt direkt vorhatte, die neuen SSD sollten ja eh an den neuen Controller und irgendwann "blank" für das anstehende Serverupdate bereitgestellt werden.

Aber Gedanken in puncto meines angedachten Hardware-Transfers macht mir das schon.
Der Controller markiert die HDDs also, aber auf dem Controller selbst scheint die Raidset-Info ja auch nicht ausschließlich zu liegen, sonst hätte doch mein Transfer in den anderen Server nicht mit Verlust der RAID1-Info einhergehen dürfen. HDD und SAS-Modul waren doch identisch...
Irgendwas dergleichen scheint quasi noch auf dem Mainboard/BIOS hinterlegt zu sein. Aber wie soll ich das ändern, ohne dass das RAID-System samt HDD-Inhalt futsch geht? (was ja quasi mein aktueller GAU wäre)

[drdope]

Nochmal zu den Backups, weil es da keine eierlegende Wollmichsau als Lösung gibt, sondern immer nur Lösungen die für Person xy praktikabel ist.

Bei Bekannten hab ich das z.B. so realisiert:

Szenario A)

Arztpraxis mit Server und fünf Clients; alles läuft auf 0815-Desktop-Hardware.
Der "Chef" kümmert sich selbst um die Backups.
Die Clients werden 1x/Quartal (nach dem Quartalssoftwareupdate) per Image "manuell" gesichert.
Der Server wird täglich "manuell" per Image gesichert (MO-DO Diff-Image; FR Komplett-Image).
Es existieren mehrere externe 2,5' Backup-HDDs die nach dem Hanoi-Schema (Tag/Woche/Monat) rotieren.
Die Backup-HDDs schließt der Chef zu Hause an sein NAS und drückt den Sync-Button.
Es existiert beim Chef@Home ein zweiter "Server" und ein weiterer Client,
als Privatrechner für sich und seine Frau (= Hardware redundant vorhanden).

Szenario B)

Gebäudereiningung mit ESXi-Server für VM-Server, sechs VM-Office-Clients und einen VM-HBCI-Banking-Client.
Auf allen Systemen läuft Windows.
Als Client-Hardware kommen gebrauchte Thin-Clients zum Einsatz, die sich per RDP mit den VMs verbinden.
Die Backups laufen alle automatisiert/zeitgesteuert per Acronis True Image auf ein der Firma stehendes NAS.
DB-Backup erfolgt nochmals einzeln aus der DB-Software selbst auf das NAS.
Das NAS synct sich per VPN/rsync mit Chefs NAS@Home (symetrische Glasfaseranbindung ist was feines).
Das NAS@Home sichert Chef mit One-Touch-Backup und mehreren externen 2,5' HDDs nach Hanoi-Schema.

Demnächst ist geplant den ESXi-Server gegen ein größeres QNAP-NAS zu tauschen.
--> https://geizhals.de/qnap-turbo-stati...a1632418.html?
Darauf laufen dann perspektivisch die VMs per VirtualisationStation, welches auch eine relativ komfortabel Backuplösung gleich mit bringt.
--> https://www.qnap.com/solution/virtua...ation-3/de-de/
Bin ich mal gespannt drauf...

Und jetzt kommen wir mal zu deinem Konkreten Fall:
(war am schreiben, während du geantwortet hast)

Szenario C)

Wenn du keine Installer für ESXi/Server-VM/DB-Software hast ist das doof...
An die Installer von ESXi/Server-VM kommt man ran, wie es bei der DB-Software aussschaut -> k.A.

In dem Fall würde zu einer Lösung ähnlich Szenario A raten (Medistar = die Praxissoftware, die der Bekannte nutzt, gibt seine Installer nämlich auch nicht raus).
Ein komplettes Image, daß man bei Bedarf zurück spielen kann, is deshalb sehr hilfreich, um nicht von den Reaktionszeiten des externen Dienstleisters abhängig zu sein.
Weil:

Halten wir fest: Der Server DARF nicht abschmieren.

Ich schlage mal als risikolose Alternative zu deinen Ideen vor:
Image des alten Servers erstellen; auf dem neuen Server das SSD-RAID anlegen; Image des alten Servers auf das neue SSD-Raid spielen.

So Bastelgeschichten, wo man immer drauf hoffen muß, daß etwas klappt und dabei die Funktion des alten Servers ggf. kompromittiert, sind immer "unelegant", weil risikobehaftet, denn:

Halten wir fest: Der Server DARF nicht abschmieren.

Schau dir mal Clonezilla an:
--> https://clonezilla.org
Ist kostenlos und sollte zu dem Zweck taugen...

Eine elegantere Lösung wäre z.B. auf der SD-Karte des Idrac-Moduls ein bootfähiges Image von (z.B. Acronis True Image/Clonezilla o.Ä.) zu haben.
Per KVM over IP ein reboot des Servers zu veranlassen; von der SD-Karte booten; Image des Servers auf eine SMB-Freigabe des NAS schreiben; Server wieder in den ESXi booten, das Image-Verzeichnis auf dem NAS per One-Touch-Backup auf eine externe HDD sichern...
Das ganze kann man natürlich auch Quick und Dirty lokal mit CD-ROM/USB-Stick als Bootmedium um externer HDD als Backup/Image-Tank machen...

[Schnatti]

Ok, dann gehe ich es mal zunächst wieder langsam an.

Einen Clonezilla-USB-Stick habe ich eben erstellt (also schon bootfähig, so viel hab ich gerade noch verstanden ; das iDRAC-Modul hat nur der neue Server, also mache ich's per USB).
Den würde ich dann demnächst mal nach Feierabend an den aktuellen alten Server klemmen, den ich zuvor komplett mit allen VM heruntergefahren habe.
Die Bootreihenfolge im BIOS ändern und die Miezi einfach mal loslassen, dann hoffen dass das CloneZilla-Interface einen automagisch durch den Klonvorgang schickt.

Bis dahin treib ich nochmal 2 HDDs auf, außer ich bekomme morgen wie von Geisterhand die 3. HDD wieder als lebendig angezeigt.
Wenn das klappt, habe ich zumindest erst einmal eine aktuelle Backup-HDD.
Oder würdest du statt der physischen Kopie lieber versuchen aus CloneZilla heraus den NAS anzusteuern und dort eine Image zu erstellen?
Wenn ich allerdings folgendes sehe, wie es mir entgegenhüpfen wird



dann weiß ich nicht, ob mein Jägerlatein dafür reichen wird, das NAS zu finden...

Die Analogie zu der Arztpraxis-Software erscheint mir im übrigen auch sehr passend.

P.S.:
Hast du hier eine Idee bzgl. der CPU-Taktfrequenz im neuen Server?



Kann man die CPU-Leistung per BIOS drosseln? Oder ist was kaputt? Oder rede ich mir nur Probleme ein und das ist normal?

[drdope]

Clonezilla hat auch eine sehr gute Online-Doku:
--> https://clonezilla.org/clonezilla-us...live-usage.php
Kannst das Szenario ja mal einen anderen Rechner (weniger wichtigen Rechner) durchspielen, bis du dir sicher bist, was du da machst.


Die dritte HDD kannst du auch mal testweise an/in einem anderen Rechner hängen und alle Partitionen löschen
--> ggf. blockt der Raid-Controller selbige nur, weil sie ein Filesystem mit identischer UUID hat aber lt. Controller nicht mehr "synced" ist.
Im Bios tauchen nämlich drei HDDs auf:



Da sieht man btw auch schön, daß die ganzen "Dell-HDDs" nur umgelabelte Seagate/Western Digital/Toshiba-HDDs sind, genauso wie der
Dell-Raid-Controller sich als umgelabelter LSI-Controller zu erkennen gibt.


Das Backup auf das NAS sollte flotter gehen, als auf ein externes Laufwerk, weil der Server kein USB 3.0 hat, aber GB-LAN, was ca. 3-4x flotter ist als USB 2.0.
Wenn du das Image auf dem NAS ablegen willst, machst du das via Samba oder NFS.
Dazu nutzt du entweder eine bestehende Freigabe auf dem NAS oder legst dafür eine neue an.
Last but not least mußt du dann Clonezilla eine freie IP im Subnet (idR 192.168.x.x) des NAS geben (entweder manuell oder per DHCP; damit sich beide Geräte auch logisch im gleichen Netz bewegen) und den Pfad zur Freigabe sowie Login/PW der Freigabe hinterlegen.
Auch da gilt wieder rtfm (read the fine/f*ck*ng manual)!


Ich würde nochmal das Bios des "neuen" Servers durchschauen (CPU-Settings/Powermanagement-Settings).
Ein laden der Defaults kann auch nicht Schaden... imho ist da der CPU-Takt-Multiplier und/oder der Frontsidebus nicht richtig eingestellt.

Achja:
Bootreihenfolge im Bios mußt du nicht zwingend ändern, die meisten Boards bieten an, beim booten per Tastenkombination ein temporäres Bootdevice für den nächsten Start zu wählen.


edit: ein paar Anmerkungen hinzugefügt/Details ergänzt.

[Schnatti]

Alles notiert und soweit fast verstanden.

Ich bin gespannt wie ein Flitzebogen...
Mein Tipp: Das NAS wird sich nicht greifen lassen.

Zwei kleine Verständnisprobleme:
a) Clonezilla soll eine eigene IP bekommen, damit es mit im Netzwerk hängt? Das geht hoffentlich in CloneZilla selbst oder wie meinst du das? Wieso reicht hier nicht die fixe IP des Servers selbst?
b) Wieso ist das USB2/3-Thema relevant, wenn die HDDs am SATA/SAS hängen? Am USB-Port klemmt doch nur der Clonezilla-Stick...

[drdope]

a) weil es mehrere Wege gibt einem lokalen Rechner eine eindeutige IP-/DNS-Adresse zu verpassen und ich nicht nicht weiß, wie das bei dir eingerichtet wurde.
(Im Router kann man z.B konfigurieren, daß ein im Netzwerk vorhandener Rechner mit MAC-Adresse xy (auch eine UUID) immer die selbe IP bekommt -> wenn dem so ist, kennt man die Server-IP und den DNS Namen des Rechners.
Wenn dem nicht so ist, muß man ggf. jedem Rechner manuell ein IP aus dem lokalen LAN zuweisen, um dessen Adresse zu kennen...
Hab keine Ahnung, wie dein lokales LAN konfiguriert wurde...


b) weil du als (externes) Backup-Ziel entweder via SMB/NFS ein Netzwerklaufwerk (GB-LAN -> ca. 125MB/s) oder eine USB 2.0-Laufwerk auswählen kannst (ca. 60MB/s in der Theorie); in der Praxis landet bei letzterem Pi mal Daumen bei der Hälfte der Bandbreite...
Die Bandbreite zum Backup-Laufwerk limitiert hier/ist der Flaschenhals, den aus auszuhebeln gilt...

[Schnatti]

Hab keine Ahnung, wie dein lokales LAN konfiguriert wurde...

Du wirst die Antwort kennen: Ich auch nicht.

b) weil du als (externes) Backup-Ziel entweder via SMB/NFS ein Netzwerklaufwerk (GB-LAN -> ca. 125MB/s) oder eine USB 2.0-Laufwerk auswählen kannst (ca. 60MB/s in der Theorie); in der Praxis landet bei letzterem Pi mal Daumen bei der Hälfte der Bandbreite...
Die Bandbreite zum Backup-Laufwerk limitiert hier/ist der Flaschenhals, den aus auszuhebeln gilt...

Ok, ich dachte ich würde auf ein internes Laufwerk klonen.
Dafür böte sich doch das HotSwapping an, erschien es mir...
Ein externes USB-Laufwerk habe ich gar nicht, wollte ich gerade sagen, aber ich habe "neulich" wegen meines Festplattencrashdilemmas ja doch so ein Dingens erstanden.
Könnte nur mit 250MB ein bisschen klein sein.

[drdope]

a) Clonezilla soll eine eigene IP bekommen, damit es mit im Netzwerk hängt? Das geht hoffentlich in CloneZilla selbst oder wie meinst du das? Wieso reicht hier nicht die fixe IP des Servers selbst?

Noch mal zur Erklärung:
Wenn die fixe IP des Servers im ESXi "statisch" eingerichtet wurde, und auf dem Gerät nun Clonezilla als OS gebootet wird selbiges nicht die Konfig des ESXi übernehmen.
Best Case -> Der Router verteilt statisch anhand der individuellen Mac-Adresse jedem Rechner eine "feste" IP.
Alternative 1 (default-config der meisten Router) -> Der Router verteilt wahllos aus einem DHCP/IP-Adressenpool lokale IPs nach dem Motto wer zuerst kommt, wird zuerst bedient.
Alternative 2 -> Der Router verteilt gar keine IPs, das muß ma Client händisch geschehen (eher unwahrscheinlich).

Schau mal in die Config-Oberfläche deines Router.
Da solltest du ein Menu finden, daß LAN/DHCP oder so ähnlich heißt.
Daran erkennst du (u.A), wie die IP-Zuteilung im LAN bei dir eingerichtet ist.

Das hängt von der individuell verwendeten Festplatte, der Qualität des Steckverbinders im Wechselrahmen und der Nutzungsweise ab. Die Serial-ATA-Steckverbinder interner Laufwerke sind laut der Firma WD für lediglich 50 Steckzyklen ausgelegt – fest eingebaute Festplatten werden eben selten ausgetauscht. In der Praxis vertragen pfleglich behandelte SATA-Verbinder aber viel mehr Kontaktierungen – schätzungsweise mehrere hundert. Andererseits hören wir ab und zu von c’t-Lesern, dass Verschleiß von Steckverbindern in SATA-Wechselrahmen oder an Festplatten zu Problemen führt. Wann das auftritt beziehungsweise wie häufig es sicher klappt, lässt sich nicht vorhersagen.
Für externe Geräte, die häufiger gewechselt werden, schreiben die jeweiligen Spezifikationen sehr viel mehr Steckzyklen vor. Für normal große USB-Buchsen sind 1500 Steckzyklen vorgesehen, für eSATA 5000 und für Micro-USB sogar 10 000.

--> https://www.heise.de/ct/hotline/Lebe...n-2182108.html

PS sicher das du 250MB meinst und nicht GB?
scnr!

[Schnatti]

Noch mal zur Erklärung:
Wenn die fixe IP des Servers im ESXi "statisch" eingerichtet wurde, und auf dem Gerät nun Clonezilla als OS gebootet wird selbiges nicht die Konfig des ESXi übernehmen.

Jetzt wird's mir schlüssig...
Ich war der Ansicht, dass die IP vermutlich gleich im BIOS vergeben wird und nicht bereits im "Betriebssystem" resp. Supervisor.

Schau mal in die Config-Oberfläche deines Router.
Da solltest du ein Menu finden, daß LAN/DHCP oder so ähnlich heißt.
Daran erkennst du (u.A), wie die IP-Zuteilung im LAN bei dir eingerichtet ist.

Hatte heute ein Telefonat mit dem Admin: Er meint, dass die IPs schon maßgeblich lokal eingerichtet sind, aber ein gewisser Nummernbereich auch per DHCP zur Verfügung steht.

Wenn ich die Zugangsdaten finde , schaue ich später mal auf den Router und forsche, wo ich die MAC-Adressen/IP-Assoziation ggf. hinterlegen kann.
Gehe ich recht in der Annahme, dass ich dann folgende MAC-Adresse hinterlegen müsste?
Und das wirklich je nachdem unterschiedlich, in welchen Netzwerkport das Kabel geht?



Schön erklärt jedenfalls mal wieder.

Und...P.S.: 250KB

[Schnatti]

Und kurz zum Thema CPU eine Bilderstrecke in chronologischer Abfolge:

Prozessor-Einstellungen


Power Management-Einstellung nativ


Power Management-Einstellung abgeändert


Resultat

[drdope]

Ich war der Ansicht, dass die IP vermutlich gleich im BIOS vergeben wird und nicht bereits im "Betriebssystem" resp. Supervisor.

Jein, IPs vergibst du primär im OS selbst; Ausnahme sind dedizierte Fernwartungports für KVMoverIP, wie z.B. das iDrac-Modul, welches du im Bios einrichtest.

Gehe ich recht in der Annahme, dass ich dann folgende MAC-Adresse hinterlegen müsste?
Und das wirklich je nachdem unterschiedlich, in welchen Netzwerkport das Kabel geht?

Genau, aber siehe unten...
Fun Fact -> auch jede VM hat eine virtuelle Netzwerkkarte mit eigener MAC-Adresse.

Das kann also so ausschauen:
Router --> 192.168.1.1
ESXi --> 192.168.1.2
VM_Server --> 192.168.1.3
VM_Wartung --> 192.168.1.4
NAS --> 192.168.1.5
Netzwerk-Drucker --> 192.168.1.6
Clients: 192.168.1.7 bis 192.168.1.12

Aber nochmal zu den IP-Adressen im Allgemeinen:

Bevor du dir da was "verkonfigurierst".

Du darfst keine IP-Adresse doppelt vergeben, sonst bekommst du Streß.
Mach dir erst mal einen Überblick welche IPs im LAN und ggf. WLAN überhaupt genutzt werden und wie das ganze eingerichtet ist.
Wenn du IPs von Servern/Netzwerkdrucken/NAS einfach veränderst, kann es sein, daß Dienste im LAN plötzlich nicht mehr erreichbar sind.
Z.B. könnte es sein, daß die Adresse des Servers irgendwo statisch in der Client-Software eingerichtet ist.

Grundsätzlich ist es aber für spätere Wartung/Administration von Vorteil zu Wissen, wie das ganze eingerichtet ist.
Wichtig ist für dich akut aber nur:
--> Es läuft ein DHCP-Server, also bekommt Clonezilla eine Adresse aus dem (im Router eingerichteten) DHCP-IP-Pool zugewiesen.
--> du mußt die IP-Adresse des NAS kennen, wenn du darauf zugreifen willst, um dort Images abzulegen.
Alles andere ist erst mal nur sekundär wichtig!

[Schnatti]

Ok, ich komme weitgehend mit.

Bevor ich übrigens gänzlich durch die Mini-IT-Prüfung falle, kann ich dir immerhin mitteilen, dass ich tatsächlich eine IP-Liste des LAN besitze...

Irgendwie hatte ich - was das IP-Gedöns angeht - so verstanden, als muss Clonezilla eine mir bekannte, eigene IP erhalten, damit ich gezielt klonen kann. Wenn es lediglich darum geht, dass es per DHCP irgendeine bekommt, um im LAN aktiv teilzunehmen, dann habe ich verstanden.
Ansonsten habe ich irgendwo (auf dem Verwaltungsrechner glaube ich) einen IP-Sniffer (?) gesehen, vermutlich könnte ich mit dem auch die des Clonezilla nach dem Booten herausbekommen...?

IP des NAS ist mir jedenfalls bekannt, daran sollte es nicht scheitern. Aber an meinen quasi nicht vorhandenen Kommandozeilen-Skills. Nach sowas schreit ja die Clonezilla-"GUI" förmlich, wenn ich es mal so "vorveruteilen" darf, aber ich lasse mich gern positiv überraschen.

Naja, heute kam ich weiter zu nix, das Sommerloch scheint vorbei zu sein - mal sehen ob ich die Woche Fortschritte erziele.

[Schnatti]

Ich hab das Chassis-Problem mal in's DELL-Forum gesetzt, die scheinen da recht flott zu antworten.
Bin mal gespannt ob ich einfach nur zu doof bin oder es tatsächlich nicht ohne weiteres passt...
Mann, wäre das doof, die Backplane nicht einfach elektiv nachrüsten zu können.

Das Problem ist halt, dass ich vom H200-Controller nicht ohne weiteres an die festverkabelten HDDs komme.
Ich habe zwar 2 miniSAS-miniSAS-Kabel mit dem Controller mitgeliefert bekommen, aber die würden eben nur in die Backplane passen und nicht an die SATA-Platten.
Nun gibt es zwar scheinbar Abhilfe, aber 60 Euro für ein Kabel investieren zu müssen, wäre schon bitter...und das ist noch das mit Abstand günstigste, das ich sehe!

[drdope]

Clonezilla braucht nur irgendeine valide IP aus dem lokalen Subnet.
Zum Backup auf eine SMB/Samba-Freigabe findest du hier noch mal eine detaillierte Anleitung:
--> https://www.raymond.cc/blog/guide-fo...ng-clonezilla/

Verlink' deine Anfrage im Dell-Forum (der Übersicht halber) bitte auch hier, dann brauchen wir nicht "stille Post" spielen.