Datensicherung HyperV Server
Hallo,
Ich würde gerne mal Eure Meinung und Gegenvorschläge (bitte mit Grund) wissen:
Ich habe einen MS 2019 HyperV mit folgenden 2019 Standard Servern:
1x AD Server
1x Exchange 2019
1x ERP-Server (SQL)
1x Allgemeiner APP Server
Mein Sicherungskonzept:
1.) tägliche Sicherung per "Windows Backup" auf Externe Festplatten, die ich täglich tausche.
2.) Samstags komplette Sicherung auf eine NAS in einer anderen Etage per Acronis.
3.) Sonntags werden die Datenverzeichnisse auf eine Weitere NAS im Serverraum gesichert, ebenfalls per Acronis.
Vielen Dank
BpRaBa
Ich würde gerne mal Eure Meinung und Gegenvorschläge (bitte mit Grund) wissen:
Ich habe einen MS 2019 HyperV mit folgenden 2019 Standard Servern:
1x AD Server
1x Exchange 2019
1x ERP-Server (SQL)
1x Allgemeiner APP Server
Mein Sicherungskonzept:
1.) tägliche Sicherung per "Windows Backup" auf Externe Festplatten, die ich täglich tausche.
2.) Samstags komplette Sicherung auf eine NAS in einer anderen Etage per Acronis.
3.) Sonntags werden die Datenverzeichnisse auf eine Weitere NAS im Serverraum gesichert, ebenfalls per Acronis.
Vielen Dank
BpRaBa
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1498085304
Url: https://administrator.de/contentid/1498085304
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
42 Kommentare
Neuester Kommentar
Hallo,
wenn Acronis + KnowHow vorhanden würde ich auch täglich auf die NAS sichern via Acronis.
Auch täglich die Daten auf die zweite NAS kopieren.
Persönlich würde ich mir nicht zutrauen das täglich die externe HDD gewechselt wird, wäre bei mir schon wegen Urlaub / Krankheit nicht zu machen. Aber wenn dies bei dir klappt dann würde ich dies beibehalten. Wir haben dafür ein Tapelaufwerk in einen anderen Brandabschnitt und eine Sicherung an einen externen Standort.
Also prinzipiell ist dein Weg einigermaßen in Ordnung, ich verstehe nur nicht warum Windows Backup verwendet wird wenn Acronis vorhanden ist.
Würde ich es einrichten würde ich wohl auch die Veeam Community Edition verwenden (bis zu 10 VM´s kostenlos).
Damit bist dann auch im Desaster Fall gerüstet, aber ich weiß ehrlich gesagt nicht was Acronis da mittlerweile drauf hat. Ist schon über 10 Jahre her als ich Acronis das letzte mal verwendet habe.
wenn Acronis + KnowHow vorhanden würde ich auch täglich auf die NAS sichern via Acronis.
Auch täglich die Daten auf die zweite NAS kopieren.
Persönlich würde ich mir nicht zutrauen das täglich die externe HDD gewechselt wird, wäre bei mir schon wegen Urlaub / Krankheit nicht zu machen. Aber wenn dies bei dir klappt dann würde ich dies beibehalten. Wir haben dafür ein Tapelaufwerk in einen anderen Brandabschnitt und eine Sicherung an einen externen Standort.
Also prinzipiell ist dein Weg einigermaßen in Ordnung, ich verstehe nur nicht warum Windows Backup verwendet wird wenn Acronis vorhanden ist.
Würde ich es einrichten würde ich wohl auch die Veeam Community Edition verwenden (bis zu 10 VM´s kostenlos).
Damit bist dann auch im Desaster Fall gerüstet, aber ich weiß ehrlich gesagt nicht was Acronis da mittlerweile drauf hat. Ist schon über 10 Jahre her als ich Acronis das letzte mal verwendet habe.
Kann noch Altaro in den Raum werfen, bisschen billiger zu beziehen als Veeam, weil per Server lizenziert und tut auch seinen Job zuverlässig. Man kann z.B. eine NAS als primäres Sicherungsziel auswählen und eine Medienrotation als Offsite Backup einrichten, so setzen wir es ein.
Jeden Tag tauschen wär mir zu aufwendig, wir haben vier kleine NAS die wöchentlich rotiert werden, um den Brandfall oder Ransomware Angriff abzudecken.
Jeden Tag tauschen wär mir zu aufwendig, wir haben vier kleine NAS die wöchentlich rotiert werden, um den Brandfall oder Ransomware Angriff abzudecken.
Zitat von @MirkoKR:
Ich halte das ganz einfach:
VMs exportieren
Zusätzlich ggf. disk2vhd der laufenden VMs.
Veeam, Acronis, etc sind natürlich zusätzlicher Schutz ...
.
Ich halte das ganz einfach:
VMs exportieren
Zusätzlich ggf. disk2vhd der laufenden VMs.
Veeam, Acronis, etc sind natürlich zusätzlicher Schutz ...
.
Hast du schonmal einen desaster recovery fall durchgespielt? Wie lange brauchst du in diesem Szenario bis deine Server wieder laufen? Klingt für mich jetzt etwas wackelig ;)
Zitat von @rzlbrnft:
Kann noch Altaro in den Raum werfen, bisschen billiger zu beziehen als Veeam, weil per Server lizenziert und tut auch seinen Job zuverlässig. Man kann z.B. eine NAS als primäres Sicherungsziel auswählen und eine Medienrotation als Offsite Backup einrichten, so setzen wir es ein.
Jeden Tag tauschen wär mir zu aufwendig, wir haben vier kleine NAS die wöchentlich rotiert werden, um den Brandfall oder Ransomware Angriff abzudecken.
Kann noch Altaro in den Raum werfen, bisschen billiger zu beziehen als Veeam, weil per Server lizenziert und tut auch seinen Job zuverlässig. Man kann z.B. eine NAS als primäres Sicherungsziel auswählen und eine Medienrotation als Offsite Backup einrichten, so setzen wir es ein.
Jeden Tag tauschen wär mir zu aufwendig, wir haben vier kleine NAS die wöchentlich rotiert werden, um den Brandfall oder Ransomware Angriff abzudecken.
Wie oben erwähnt, die Community Version wäre für den TE kostenlos. Allerdings natürlich mit Einarbeitungs- / Migrationsaufwand verbunden.
https://www.veeam.com/de/virtual-machine-backup-solution-free.html
Zitat von @SomebodyToLove:
Hast du schonmal einen desaster recovery fall durchgespielt? Wie lange brauchst du in diesem Szenario bis deine Server wieder laufen? Klingt für mich jetzt etwas wackelig ;)
Hast du schonmal einen desaster recovery fall durchgespielt? Wie lange brauchst du in diesem Szenario bis deine Server wieder laufen? Klingt für mich jetzt etwas wackelig ;)
Jepp.
Die exportierte VHD
konnte in einem Desktop Win10 PC nach < 30 min wieder ihren Dienst tuen...
... natürlich nur temporär ..
.
Moin...
also wenn du Acronis hast, ist der drops doch fast gelutscht... da ist alles bei, was gebraucht wird!
kaufe dazu noch ein RDX laufwerk, und sichere täglich oder wie auch immer auf RDX...
bei einigen kunden mache ich eine acronis sicherung aufs NAS und auf das RDX laufwerk... täglich.
was brauchst du mehr.... ?!?!
Frank
also wenn du Acronis hast, ist der drops doch fast gelutscht... da ist alles bei, was gebraucht wird!
kaufe dazu noch ein RDX laufwerk, und sichere täglich oder wie auch immer auf RDX...
bei einigen kunden mache ich eine acronis sicherung aufs NAS und auf das RDX laufwerk... täglich.
was brauchst du mehr.... ?!?!
Frank
Zitat von @user217:
Über Backupkonzepte kann man streiten mir wäre aber bei einem virtualisiert DC nicht wohl. Das ist falsch.
Über Backupkonzepte kann man streiten mir wäre aber bei einem virtualisiert DC nicht wohl. Das ist falsch.
was ist daran falsch???????!!!!
falsch ist, das nur ein DC da ist... egal ob Blech oder VM!
Frank
Zitat von @Vision2015:
was ist daran falsch???????!!!!
falsch ist, das nur ein DC da ist... egal ob Blech oder VM!
Frank
Zitat von @user217:
Über Backupkonzepte kann man streiten mir wäre aber bei einem virtualisiert DC nicht wohl. Das ist falsch.
Über Backupkonzepte kann man streiten mir wäre aber bei einem virtualisiert DC nicht wohl. Das ist falsch.
was ist daran falsch???????!!!!
falsch ist, das nur ein DC da ist... egal ob Blech oder VM!
Frank
Diese Meinung teile ich nicht.
Zitat von @user217:
Diese Meinung teile ich nicht.
Zitat von @Vision2015:
was ist daran falsch???????!!!!
falsch ist, das nur ein DC da ist... egal ob Blech oder VM!
Frank
Zitat von @user217:
Über Backupkonzepte kann man streiten mir wäre aber bei einem virtualisiert DC nicht wohl. Das ist falsch.
Über Backupkonzepte kann man streiten mir wäre aber bei einem virtualisiert DC nicht wohl. Das ist falsch.
was ist daran falsch???????!!!!
falsch ist, das nur ein DC da ist... egal ob Blech oder VM!
Frank
Diese Meinung teile ich nicht.
brauchst du ja auch nicht....
das war eine geschichte in den anfängen von der Virtualisierung... heute ist das eh latte.
begründe das doch mal, so rein technisch...
Frank
Windows Backup tut's an der Stelle granz brauchbar, wenn du nur eine Sicherungs-Ebene brauchst und keine granulare Wiederherstellung. Einzelne Dateien / Mails / sonstige Objekte sind ja damit nicht direkt wiederherstellbar. Dafür sichert das DIng aber den Host mit, was zwar landläufig als unwichtig angesehen wird, ich sehe hier aber auch "haben ist besser als brauchen".
Kleinere Umgebungen (HyperV + DC + 1 sonst. Server) sichere ich damit auch, und bei nur geringen Anforderungen an Granularität und Zeitfenster bei Wiederherstellung kann man damit leben. Bei einem on prem Exchange würde ich glaube ich zucken; Wiederherstellung von Exchange Objekten wäre hiermit vermutlich keine Freude. Dann doch auf Veeam (Community Edition wurde ja erwähnt) umsatteln.
Oder eine Mischung, wochentags die virtuellen Maschinen per Veeam und wochenends das gesamte DIng per WIndows Backup.
Und: Denk dran, dass WSB auf NAS/Shares nur einen Snapshot sichert, keine Historie. Zumindest war das zu Windows 2008er Zeiten so.
Kleinere Umgebungen (HyperV + DC + 1 sonst. Server) sichere ich damit auch, und bei nur geringen Anforderungen an Granularität und Zeitfenster bei Wiederherstellung kann man damit leben. Bei einem on prem Exchange würde ich glaube ich zucken; Wiederherstellung von Exchange Objekten wäre hiermit vermutlich keine Freude. Dann doch auf Veeam (Community Edition wurde ja erwähnt) umsatteln.
Oder eine Mischung, wochentags die virtuellen Maschinen per Veeam und wochenends das gesamte DIng per WIndows Backup.
Und: Denk dran, dass WSB auf NAS/Shares nur einen Snapshot sichert, keine Historie. Zumindest war das zu Windows 2008er Zeiten so.
AD/DNS/DHCP würde ich persönlich immer redundant halten, wenn irgendwie möglich.
Also aus meiner Erfahrung heraus kann man den DC virtualisieren solange der/die Hyper-V Server nicht in der Domäne sind.
Sobald ein Cluster konfiguriert wird (setzt Domäne vom Hyper-V Server voraus), sollte auch noch ein zusätzlicher DC als physikalischer Server vorhanden sein. Sonst könnte man, wenn die VM´s aus irgendeinen Grund nicht automatisch starten, sich selber aus den Hyper-V Servern ausschließen.
Zur not kann man das natürlich noch mit lokalen Administrator Konten lösen, aber je nach Größe sollten diese nicht für jeden verfügbar sein...
Aber persönlich bin ich nicht in so großen Umgebungen unterwegs und habe auch kein Hyper-V Cluster sondern nur Replikationen. Deshalb sind meine DC´s virtualisiert und meine Hyper-V Server nicht in der Domäne.
Grüße
Somebody
Also aus meiner Erfahrung heraus kann man den DC virtualisieren solange der/die Hyper-V Server nicht in der Domäne sind.
Sobald ein Cluster konfiguriert wird (setzt Domäne vom Hyper-V Server voraus), sollte auch noch ein zusätzlicher DC als physikalischer Server vorhanden sein. Sonst könnte man, wenn die VM´s aus irgendeinen Grund nicht automatisch starten, sich selber aus den Hyper-V Servern ausschließen.
Zur not kann man das natürlich noch mit lokalen Administrator Konten lösen, aber je nach Größe sollten diese nicht für jeden verfügbar sein...
Aber persönlich bin ich nicht in so großen Umgebungen unterwegs und habe auch kein Hyper-V Cluster sondern nur Replikationen. Deshalb sind meine DC´s virtualisiert und meine Hyper-V Server nicht in der Domäne.
Grüße
Somebody
Mahlzeit
Ein virtualisierter DC macht das selbe, wie einer auf Blech, nur das du halt einen Host auf einem Blech brauchst.
Bei mir ist selbst der Hyper-V-Host (W2019) Mitglied dieser Domäne.
Jetzt darfst du mir gern erklären, wo das Problem liegen soll?
Zumal es in einer richtigen IT-Umgebung niemals nur das (ein) Backup gibt.
Schnell wird mit so einer Aussage ein Hersteller diskreditiert.
PS: Ich nutze seit 1998 Backup Exec und betreue damit viele Kundenumgebungen und auch meine. Zusätzlich nutze ich aber auch häufig Veritas System Recovery.
Zitat von @user217:
Über Backupkonzepte kann man streiten mir wäre aber bei einem virtualisiert DC nicht wohl. Das ist falsch.
Dann musst du aber noch viel lernen.Über Backupkonzepte kann man streiten mir wäre aber bei einem virtualisiert DC nicht wohl. Das ist falsch.
Ein virtualisierter DC macht das selbe, wie einer auf Blech, nur das du halt einen Host auf einem Blech brauchst.
Bei mir ist selbst der Hyper-V-Host (W2019) Mitglied dieser Domäne.
Jetzt darfst du mir gern erklären, wo das Problem liegen soll?
Zitat von @BpRaBa:
Warum Windows Backup? Mir wurde damals schon in der Ausbildung eingetrichtert - Sicher dein Netzwerk immer auf zwei Arten und das mach ich jetzt schon seit der Zeit so...
Es schadet ganz sicher nicht, auf mehrere Arten Sicherungen anzufertigen.Warum Windows Backup? Mir wurde damals schon in der Ausbildung eingetrichtert - Sicher dein Netzwerk immer auf zwei Arten und das mach ich jetzt schon seit der Zeit so...
Es hat mir auch schon einmal das Leben gerettet, es war damals Symantec und da war das Backup beschädigt.
Ein beschädigtes Backup ist in jedem Fall nicht der Datensicherungslösung anzuheften, sondern dem, der diese erstellt und nicht ausreichend überprüft hat.Zumal es in einer richtigen IT-Umgebung niemals nur das (ein) Backup gibt.
Schnell wird mit so einer Aussage ein Hersteller diskreditiert.
PS: Ich nutze seit 1998 Backup Exec und betreue damit viele Kundenumgebungen und auch meine. Zusätzlich nutze ich aber auch häufig Veritas System Recovery.
Zitat von @MirkoKR:
Prinzipiell bin ich auch gegen NUR virtualisierten DC!
Aber. wenn von EINEM eine VHD Kopie vorliegt, kann diese im Notfall auch auf einem Win10+ Desktop Rechner laufen ...
.
Prinzipiell bin ich auch gegen NUR virtualisierten DC!
Aber. wenn von EINEM eine VHD Kopie vorliegt, kann diese im Notfall auch auf einem Win10+ Desktop Rechner laufen ...
.
Okay, ich merk schon. Du hast Eier so groß wie Luftballons
Zitat von @MirkoKR:
Prinzipiell bin ich auch gegen NUR virtualisierten DC!
Aber. wenn von EINEM eine VHD Kopie vorliegt, kann diese im Notfall auch auf einem Win10+ Desktop Rechner laufen ...
Prinzipiell bin ich auch gegen NUR virtualisierten DC!
Aber. wenn von EINEM eine VHD Kopie vorliegt, kann diese im Notfall auch auf einem Win10+ Desktop Rechner laufen ...
Da fängt es doch schon an. Wenn von einem DC,... es gehört sich nicht nur einen DC zu betreiben. Ohne DC steht die Arbeit, da ist es egal ob physisch oder virtualisiert. Ja ich kann eine Umgebung mit einem DC betreiben und den wieder herstellen. Aber mal ehrlich: In der Zeit kann doch so gut wie niemand arbeiten und evtl. muss ich erst Hardware beschaffen. Nur ein DC zu betreiben ist für mich am falschen Ende gespart. Im Desaster Fall, also wenn ein DC ausfällt, dann installier ich den einfach neu und der gleicht sich mit dem noch existierenden ab. Dauert keine Stunde und Arbeit ist weiterhin möglich.
Und warum nicht beide DCs virtuell laufen lassen? Wenn ich dafür sorge, das sie auf verschieden Hosts liegen, dann passt das. Auf jeden Host ein DC, fertig. Wenn dann die Hosts abschmieren, dann hab ich im Regelfall ganz andere Probleme, es sei denn ich habe alle Server redundant.
Und ein DC verbraucht keine Ressourcen, nur eine Lizenz. Es reicht wenn (maximal) ein DC eine grafische Oberfläche hat, die anderen können seelenruhig in einer Core-Installation vor sich hindümpeln. Das reicht für die Domäne. Das Problem bei DCs ist, dass sie meist noch mehr machen sollen. Fileserver oder Printserver, weil das ja den DC nicht überlastet. Das ist theoretisch richtig, aber im Recovery bricht dir das das Genick. Ein DC ist ein DC ist DC. Da gehört nichts weiter drauf.
Gruß
Doskias
Gegen virtualisierte DC ist nichts einzuwenden, solange der Hypervisor auf dem er läuft, nicht auf das AD angewiesen ist, also z.B. Hyper-V-Server als Standalone-Server ohne Domänenmitgliedschaft.
Wichtig ist nur, daß man entweder (mindestens) zwei haben sollte oder ein aktuelles(!) Backup aus dem man sehr schnell einen neuen DC hinzaubern kann.
Aber. wenn von EINEM eine VHD Kopie vorliegt, kann diese im Notfall auch auf einem Win10+ Desktop Rechner laufen ...
Daselbe trifft für eine bare-metal-DC zu. Da ist es sogar schwieriger, einen wieder aus dem Backup hervorzuzaubern, wenn die passende hardware nicht da ist. Da ist ein virtualisierter DC deutlich einfacher zu handhaben.
lks
Zitat von @user217:
Man virtualisiert keine Domänencontroller, es sollte immer min. ein Hardwarecontroller existieren.
Man virtualisiert keine Domänencontroller, es sollte immer min. ein Hardwarecontroller existieren.
Unsinn.
Das ist als ob man seine Autoschlüssel ins Handschuhfach wirft und drauf hofft das sich die Karre nicht selbst irgendwann absperrt.
Wenn Du das so machst, dann hast Du den Fehler gemacht, den Hypervisor mit in die Domain aufzunehmen. Der gehört i.d.R. nicht in die Domain, solange man keinen bare-metal-DC (Nachschlüssel) hat.
lks
PS: Man hat mindestens zwei Autoschlüssel!
Zitat von @Lochkartenstanzer:
Unsinn.
Wenn Du das so machst, dann hast Du den Fehler gemacht, den Hypervisor mit in die Domain aufzunehmen.
lks
PS: Man hat mindestens zwei Autoschlüssel!
Zitat von @user217:
Man virtualisiert keine Domänencontroller, es sollte immer min. ein Hardwarecontroller existieren.
Man virtualisiert keine Domänencontroller, es sollte immer min. ein Hardwarecontroller existieren.
Unsinn.
Das ist als ob man seine Autoschlüssel ins Handschuhfach wirft und drauf hofft das sich die Karre nicht selbst irgendwann absperrt.
Wenn Du das so machst, dann hast Du den Fehler gemacht, den Hypervisor mit in die Domain aufzunehmen.
lks
PS: Man hat mindestens zwei Autoschlüssel!
oder hat ADAC Premium
Frank
An alle, die hier geschrieben haben, dass ein Hyper-V-Host (der den einzigen DC hostet) nicht Mitglied der Domäne sein darf.
Bitte begründet eure Aussagen und schreibt nicht einfach nur, dass es nicht sein darf.
Hier die Argumente, weshalb es überhaupt kein Problem darstellt:
1.
Virtuelle Maschinen können automatisch starten, wenn der Host neugestartet wird.
Das sollte man für DCs prinzipiell einrichten und für viele andere VMs auch (teilweise ist zeitverzögert sinnvoll).
2.
Am Hyper-V-Host kann man sich auch mit lokalen Credentials anmelden, auch wenn dieser in der Domäne ist.
Dieser lokale Benutzer sollte dann natürlich Berechtigungen für Hyper-V haben, damit das verwaltet werden kann.
Schaut mal hier rein:
Den einzigen Hyper-V Host in die Domäne aufnehmen?
Natürlich ist es besser, wenn man mehr als einen DC hat.
Je größer die Umgebung ist und je mehr Admins daran beteiligt sind, desto mehr DCs sollten vorhanden sein.
Aber mal im Ernst.
Ich betreue viele KMU mit 5 - 15 Usern und einem Server (meistens Hyper-V-Host mit 2-6 VMs).
Warum brauchen die mehr als einen DC?
Wann und warum fallen bei euch eigentlich die DCs?
Bitte begründet eure Aussagen und schreibt nicht einfach nur, dass es nicht sein darf.
Hier die Argumente, weshalb es überhaupt kein Problem darstellt:
1.
Virtuelle Maschinen können automatisch starten, wenn der Host neugestartet wird.
Das sollte man für DCs prinzipiell einrichten und für viele andere VMs auch (teilweise ist zeitverzögert sinnvoll).
2.
Am Hyper-V-Host kann man sich auch mit lokalen Credentials anmelden, auch wenn dieser in der Domäne ist.
Dieser lokale Benutzer sollte dann natürlich Berechtigungen für Hyper-V haben, damit das verwaltet werden kann.
Schaut mal hier rein:
Den einzigen Hyper-V Host in die Domäne aufnehmen?
Natürlich ist es besser, wenn man mehr als einen DC hat.
Je größer die Umgebung ist und je mehr Admins daran beteiligt sind, desto mehr DCs sollten vorhanden sein.
Aber mal im Ernst.
Ich betreue viele KMU mit 5 - 15 Usern und einem Server (meistens Hyper-V-Host mit 2-6 VMs).
Warum brauchen die mehr als einen DC?
Wann und warum fallen bei euch eigentlich die DCs?
Zitat von @goscho:
Hier die Argumente, weshalb es überhaupt kein Problem darstellt:
1.
Virtuelle Maschinen können automatisch starten, wenn der Host neugestartet wird.
Das sollte man für DCs prinzipiell einrichten und für viele andere VMs auch (teilweise ist zeitverzögert sinnvoll).
Hier die Argumente, weshalb es überhaupt kein Problem darstellt:
1.
Virtuelle Maschinen können automatisch starten, wenn der Host neugestartet wird.
Das sollte man für DCs prinzipiell einrichten und für viele andere VMs auch (teilweise ist zeitverzögert sinnvoll).
Noch nie erlebt, daß ein Server nach einem Update oder aus irgendeinem anderen Grund "hochkam"? Wenn der Host nachdem Neustart den DC aus welchem Grund auch immer nicht "hochkriegt", hat man verloren, wenn man sich am Host nciht mehr anmelden kann.
2.
Am Hyper-V-Host kann man sich auch mit lokalen Credentials anmelden, auch wenn dieser in der Domäne ist.
Dieser lokale Benutzer sollte dann natürlich Berechtigungen für Hyper-V haben, damit das verwaltet werden kann.
Am Hyper-V-Host kann man sich auch mit lokalen Credentials anmelden, auch wenn dieser in der Domäne ist.
Dieser lokale Benutzer sollte dann natürlich Berechtigungen für Hyper-V haben, damit das verwaltet werden kann.
Das funktioniert aber nur, wenn man vorher sich Gedanken über die Berechtigungen gemacht hat.
Warum brauchen die mehr als einen DC?
Brauchen sie i.d.R. nur dann, wenn der DC keinen downtime haben darf.
Wann und warum fallen bei euch eigentlich die DCs?
Nach MS-Updates.
lks
Wann und warum fallen bei euch eigentlich die DCs?
Das istvdee Punkt den ich oben meint. Warum fallen DAS aus. Ich habe 3 davon in 18 Jahren erlebt:
1 x Stromausfall während Updates. Keine USV? Doch aber wenn die USV einen Kurzschluss verursacht und den Strom abstellt, dann hilft das auch nicht weiter.
2 x defektes Update von MS
In dem Fällen spreche in von einen Ausfall, da sie wirklich mit nem Bluescreen verendet sind. Wenn ich den Server zur Wartung oder Patch neu starte ist das kein Ausfall. Es gab auch noch Fälle wo Kryptotrojaner und Druckertreiber die DCs lahm gelegt haben, aber das war kein DC Fehler sondern File bzw. Printserver.
In den Fällen oben wurde der DC einfach verworfen und ein neuer installiert. Geht natürlich bei nem File oder Printserver auf de DC nicht so einfach. Da hat man dann bißchen mehr zu tun. Ich persönlich lich habe halt gerne zwei, damit bei einem Ausfall weiter gearbeitet werden kann. Es ist halt ne Kostenrechnung.
Was ist günstiger? Wenn die ganze Firma 1 bis 2 Stunden nicht arbeiten kann, oder eine zusätzliche Windows Lizenz für einen zweiten DC? Ist es günstiger eine zweite aliens zu kaufen, so dass für Wartung und Co einer auch mal zu meinen Geschäftsreisen runter gefahren werden kann oder will ich dem Admin/Systemhaus einen Wochenendzuschlag für Wartungen zahlen? Das sind auch Punkte die man bei einem zweiten DC nicht außer Acht lassen sollte, wenn es darum geht ob ich einen brauche oder nicht.
moin...
ich persönlich mach selten den Hyper-V host in die Domäne... und wenn ich das machen muss, gibbet eine verwaltungs domäne, und netz... aber auch nur wenn ich es zwingend für Replikation etc. brauche!
die verwaltung hat nix mit dem AD selber zu tun.... dann natürlich auch einen externen DC auf einem Blech!
Hier die Argumente, weshalb es überhaupt kein Problem darstellt:
1.
Virtuelle Maschinen können automatisch starten, wenn der Host neugestartet wird.
Das sollte man für DCs prinzipiell einrichten und für viele andere VMs auch (teilweise ist zeitverzögert sinnvoll).
was machste wenn die vm nicht startet, oder einfach nur ein blöder netzwerkfehler deine nerven strapaziert?
Schaut mal hier rein:
Den einzigen Hyper-V Host in die Domäne aufnehmen?
Natürlich ist es besser, wenn man mehr als einen DC hat.
Je größer die Umgebung ist und je mehr Admins daran beteiligt sind, desto mehr DCs sollten vorhanden sein.
was ist das für ein Blödsinn....die anzahl der DCs hat nix mit der menge an admins zu tun, sondern eher was mit verfügbarkeit ...
Aber mal im Ernst.
Ich betreue viele KMU mit 5 - 15 Usern und einem Server (meistens Hyper-V-Host mit 2-6 VMs).
Warum brauchen die mehr als einen DC?
in der größe ist das nicht nötig, es kommt aber auf die anforderungen des kunden an....
ich habe kunden, die haben 4 User und alles redundant.....
Wann und warum fallen bei euch eigentlich die DCs?
MS Updates... Kunden die selber was versauen... der sohn das kunden, der informatik studiert, oder davon gehört hat-der unbedingt was besser machen muss.... etc..etc...
Frank
Zitat von @goscho:
An alle, die hier geschrieben haben, dass ein Hyper-V-Host (der den einzigen DC hostet) nicht Mitglied der Domäne sein darf.
Bitte begründet eure Aussagen und schreibt nicht einfach nur, dass es nicht sein darf.
also das es nicht sein darf, würde ich nicht sagen... eher das es nicht sein muss!An alle, die hier geschrieben haben, dass ein Hyper-V-Host (der den einzigen DC hostet) nicht Mitglied der Domäne sein darf.
Bitte begründet eure Aussagen und schreibt nicht einfach nur, dass es nicht sein darf.
ich persönlich mach selten den Hyper-V host in die Domäne... und wenn ich das machen muss, gibbet eine verwaltungs domäne, und netz... aber auch nur wenn ich es zwingend für Replikation etc. brauche!
die verwaltung hat nix mit dem AD selber zu tun.... dann natürlich auch einen externen DC auf einem Blech!
Hier die Argumente, weshalb es überhaupt kein Problem darstellt:
1.
Virtuelle Maschinen können automatisch starten, wenn der Host neugestartet wird.
Das sollte man für DCs prinzipiell einrichten und für viele andere VMs auch (teilweise ist zeitverzögert sinnvoll).
2.
Am Hyper-V-Host kann man sich auch mit lokalen Credentials anmelden, auch wenn dieser in der Domäne ist.
Dieser lokale Benutzer sollte dann natürlich Berechtigungen für Hyper-V haben, damit das verwaltet werden kann.
klar...Am Hyper-V-Host kann man sich auch mit lokalen Credentials anmelden, auch wenn dieser in der Domäne ist.
Dieser lokale Benutzer sollte dann natürlich Berechtigungen für Hyper-V haben, damit das verwaltet werden kann.
Schaut mal hier rein:
Den einzigen Hyper-V Host in die Domäne aufnehmen?
Natürlich ist es besser, wenn man mehr als einen DC hat.
Je größer die Umgebung ist und je mehr Admins daran beteiligt sind, desto mehr DCs sollten vorhanden sein.
Aber mal im Ernst.
Ich betreue viele KMU mit 5 - 15 Usern und einem Server (meistens Hyper-V-Host mit 2-6 VMs).
Warum brauchen die mehr als einen DC?
ich habe kunden, die haben 4 User und alles redundant.....
Wann und warum fallen bei euch eigentlich die DCs?
Frank
Zitat von @Vision2015:
Je größer die Umgebung ist und je mehr Admins daran beteiligt sind, desto mehr DCs sollten vorhanden sein.
was ist das für ein Blödsinn....die anzahl der DCs hat nix mit der menge an admins zu tun, sondern eher was mit verfügbarkeit ...Naja, dann kann man jedem Admin seinen eigenen DC geben, damit es keinen Streit gibt. Wenn man beim Fußball jedem der 22 Spieler und natürlich den Schidsrichtern auch jeweils einen eigenen Ball geben würde, würde es auch viel weniger Streit auf dem Spielfeld geben.
lks
PS: Natürlich korreliert i.d.R. die Anzahl der Admins mit der Anzahl der Systeme und damit natürlich auch mit der Anzahl der DCs. Die Kausalität ist aber, daß durch entsprechende Anforderungen des Unternehmens die Anzahl der Admins und der DCs bestimtm wird und da der dann natürlich beides gleichzeitig wächst, wenn die Anforderungen steigen. Aber wie so oft werden mal Korrelationen und Kausalitäten verwechselt.
Zitat von @Lochkartenstanzer:
Naja, dann kann man jedem Admin seinen eigenen DC geben, damit es keinen Streit gibt. Wenn man beim Fußball jedem der 22 Spieler und natürlich den Schidsrichtern auch jeweils einen eigenen Ball geben würde, würde es auch viel weniger Streit auf dem Spielfeld geben.
ach menno... ich will aber auch meinen eigenen exchange haben... ich spiele sonst nicht mehr mit euch!!! Zitat von @Vision2015:
Je größer die Umgebung ist und je mehr Admins daran beteiligt sind, desto mehr DCs sollten vorhanden sein.
was ist das für ein Blödsinn....die anzahl der DCs hat nix mit der menge an admins zu tun, sondern eher was mit verfügbarkeit ...Naja, dann kann man jedem Admin seinen eigenen DC geben, damit es keinen Streit gibt. Wenn man beim Fußball jedem der 22 Spieler und natürlich den Schidsrichtern auch jeweils einen eigenen Ball geben würde, würde es auch viel weniger Streit auf dem Spielfeld geben.
lks
PS: Natürlich korreliert i.d.R. die Anzahl der Admins mit der Anzahl der Systeme und damit natürlich auch mit der Anzahl der DCs. Die Kausalität ist aber, daß durch entsprechende Anforderungen des Unternehmens die Anzahl der Admins und der DCs bestimtm wird und da der dann natürlich beides gleichzeitig wächst, wenn die Anforderungen steigen. Aber wie so oft werden mal Korrelationen und Kausalitäten verwechselt.
Frank
Moin.
Wenn NAS, dann würde ich es per iSCSI an den Server knüppeln und SMB auf dem NAS vollständig deaktivieren. Und natürlich die Verschlüsselungsfunktion der Backupsoftware aktivieren.
Ich habe persönlich noch nie gute Erfahrungen mit Acronis gemacht, daher kann ich zu den Features speziell dieser Software nix weiter sagen; gehe aber mal davon aus, dass die ziemlich "feature-even" zu den Mitbewerbern wie Veeam & Co. sein dürfte. Von selbstgestrickten Backups kann ich nur abraten, das hat meist auch nur Alibi-Funktion.
Grundlegend ist die 3-2-1-Strategie ein solider Ansatz, ich würde in deinem Fall z.B. vom NAS regelmäßig eine verschlüsselte Kopie der dort liegenden Daten auf ein externes Medium ziehen und dieses sicher lagern.
Last but not least: Ein ausgeklügeltes Backupszenario ist nett, aber ohne regelmäßige Recovery-Tests nutzlos...
Cheers,
jsysde
Zitat von @BpRaBa:
[...]1.) tägliche Sicherung per "Windows Backup" auf Externe Festplatten, die ich täglich tausche.
Alibi-Backup - erstens unverschlüsselt (wo lagerst du die externen Platten? Wer hat da Zugang zu?), zweitens -musste ich auch erst auf die harte Tour lernen- bedeutet "Sicherung erfolgreich abgeschlossen" beim Windows Backup _NICHT!_, dass man damit auch erfolgreich wiederherstellen könnte.[...]1.) tägliche Sicherung per "Windows Backup" auf Externe Festplatten, die ich täglich tausche.
[...]2.) Samstags komplette Sicherung auf eine NAS in einer anderen Etage per Acronis.
Schon besser - die Frage ist hier, welches NAS und wie ist es angebunden. Stellt das NAS einen SMB-Share für die Ablage der Backups bereit => böse, weil Angriffsziel für Ransomware und sonstigen Mist. Bei der Masse an Lücken, die im Wochenrhythmus z.B. bei QNAP auftauchen und teils erst Wochen später mühselig geschlossen werden, ein Unding. Von der halbherzigen Implementation von SMB2/3 mal ganz zu schweigen.Wenn NAS, dann würde ich es per iSCSI an den Server knüppeln und SMB auf dem NAS vollständig deaktivieren. Und natürlich die Verschlüsselungsfunktion der Backupsoftware aktivieren.
[...]3.) Sonntags werden die Datenverzeichnisse auf eine Weitere NAS im Serverraum gesichert, ebenfalls per Acronis.
Warum nur einmal die Woche? Kannst du bzw. können deine Chefs mit einem Gap von sechs Tagen leben? Auch hier die Frage nach der Konfig des NAS.Ich habe persönlich noch nie gute Erfahrungen mit Acronis gemacht, daher kann ich zu den Features speziell dieser Software nix weiter sagen; gehe aber mal davon aus, dass die ziemlich "feature-even" zu den Mitbewerbern wie Veeam & Co. sein dürfte. Von selbstgestrickten Backups kann ich nur abraten, das hat meist auch nur Alibi-Funktion.
Grundlegend ist die 3-2-1-Strategie ein solider Ansatz, ich würde in deinem Fall z.B. vom NAS regelmäßig eine verschlüsselte Kopie der dort liegenden Daten auf ein externes Medium ziehen und dieses sicher lagern.
Last but not least: Ein ausgeklügeltes Backupszenario ist nett, aber ohne regelmäßige Recovery-Tests nutzlos...
Cheers,
jsysde
Zitat von @Lochkartenstanzer:
Unsinn.
Wenn Du das so machst, dann hast Du den Fehler gemacht, den Hypervisor mit in die Domain aufzunehmen. Der gehört i.d.R. nicht in die Domain, solange man keinen bare-metal-DC (Nachschlüssel) hat.
lks
PS: Man hat mindestens zwei Autoschlüssel!
Zitat von @user217:
Man virtualisiert keine Domänencontroller, es sollte immer min. ein Hardwarecontroller existieren.
Man virtualisiert keine Domänencontroller, es sollte immer min. ein Hardwarecontroller existieren.
Unsinn.
Das ist als ob man seine Autoschlüssel ins Handschuhfach wirft und drauf hofft das sich die Karre nicht selbst irgendwann absperrt.
Wenn Du das so machst, dann hast Du den Fehler gemacht, den Hypervisor mit in die Domain aufzunehmen. Der gehört i.d.R. nicht in die Domain, solange man keinen bare-metal-DC (Nachschlüssel) hat.
lks
PS: Man hat mindestens zwei Autoschlüssel!
Das sehe ich anders. Alleine schon die Tatsache das Kerberos Tickets ohne Domain nicht funktionieren macht das ganze auf keinen Fall sicherer. Du wirst auf jeden Fall irgendeine Möglichkeit brauchen, um das Ding remote zu admininistrieren, und die ist viel leichter mit einem Domain joined Host abzusichern als mit einer Workgroup Maschine, z.B. mit Firewall Regeln die ohne Authentifizierung nichts durchlassen. Und Shared Nothing Live Migration funktioniert auch nur mit Domäne, das ist für mich ein wichtiges Feature bei Standalone Hosts.
Bei Altaro gibts da ne nette Abhandlung drüber.
https://www.altaro.com/hyper-v/domain-joined-hyper-v-host/
Und beim virtualisierten DC kommts auch nicht drauf an wo der drauf hängt, der Host fährt problemlos mit cached Credentials hoch und startet dann den DC drauf, gab noch nie ein Problem hier damit. Zudem hat jeder, der mehrere Standorte betreibt ohnehin einen DC der nicht auf dem gleichen Cluster draufhängt am laufen, das die Infrastrukturen in beiden Standorten ausfallen ist schon sehr unwahrscheinlich, und selbst dann fahren die ohne Probleme auch ohne DC hoch.
Zitat von @user217:
Man virtualisiert keine Domänencontroller, es sollte immer min. ein Hardwarecontroller existieren. Das ist als ob man seine Autoschlüssel ins Handschuhfach wirft und drauf hofft das sich die Karre nicht selbst irgendwann absperrt.
Man virtualisiert keine Domänencontroller, es sollte immer min. ein Hardwarecontroller existieren. Das ist als ob man seine Autoschlüssel ins Handschuhfach wirft und drauf hofft das sich die Karre nicht selbst irgendwann absperrt.
Keine Ahnung wo du die Info her hast, aber das ist schon seit 2008 R2 nicht mehr so, selbst das konnte ohne DC hochfahren und seine Maschinen starten. Und wenn du irgendeinen nicht-Windows Virtualisierungshost benutzt ist die Aussage eh hinfällig.
So sieht es Microsoft:
Vermeidung einzelner Fehlerquellen
Bei der Planung für die Bereitstellung virtualisierter Domänencontroller sollten Sie darauf achten, einzelne Fehlerquellen (d. h. Komponenten, deren Ausfall den Ausfall des gesamten Systems verursachen würde) möglichst zu vermeiden. Zu diesem Zweck empfiehlt es sich, Systemredundanz vorzusehen. Erwägen Sie beispielsweise die folgenden Empfehlungen (unter Berücksichtigung der potenziell höheren Verwaltungskosten):
Ob man sich jetzt daran hält oder nicht. Bzw. das "Risiko" eingeht oder kontrollieren kann ist jeden seine eigene Entscheidung.
Vermeidung einzelner Fehlerquellen
Bei der Planung für die Bereitstellung virtualisierter Domänencontroller sollten Sie darauf achten, einzelne Fehlerquellen (d. h. Komponenten, deren Ausfall den Ausfall des gesamten Systems verursachen würde) möglichst zu vermeiden. Zu diesem Zweck empfiehlt es sich, Systemredundanz vorzusehen. Erwägen Sie beispielsweise die folgenden Empfehlungen (unter Berücksichtigung der potenziell höheren Verwaltungskosten):
- Führen Sie mindestens zwei virtualisierte Domänencontroller pro Domäne auf anderen Virtualisierungshosts aus. Dadurch wird das Risiko verringert, bei Ausfall eines Virtualisierungshosts alle Domänencontroller zu verlieren.
- Verwenden Sie zur Ausführung der Domänencontroller unterschiedliche Hardware (z. B. unterschiedliche CPUs, Hauptplatinen oder Netzwerkadapter), wie auch für andere Technologien empfohlen. Dadurch minimieren Sie Auswirkungen von Fehlfunktionen, die auf bestimmte Elemente (z. B. Anbieterkonfigurationen, Treiber, Hardwaremodelle oder Hardwaretypen) beschränkt sind.
- Domänencontroller sollten möglichst auf Hardware ausgeführt werden, die sich in unterschiedlichen geografischen Regionen befindet. Dies verringert die Auswirkungen von Notfällen oder Fehlern an einem bestimmten Standort, an dem Domänencontroller gehostet werden.
- Versehen Sie all Ihre Domänen mit physischen Domänencontrollern. Dies verringert die Auswirkungen einer Fehlfunktion einer Virtualisierungsplattform (von der auch die von der Plattform abhängigen Hostsysteme betroffen wären).
Ob man sich jetzt daran hält oder nicht. Bzw. das "Risiko" eingeht oder kontrollieren kann ist jeden seine eigene Entscheidung.
Zitat von @SomebodyToLove:
So sieht es Microsoft:
Vermeidung einzelner Fehlerquellen
Bei der Planung für die Bereitstellung virtualisierter Domänencontroller sollten Sie darauf achten, einzelne Fehlerquellen (d. h. Komponenten, deren Ausfall den Ausfall des gesamten Systems verursachen würde) möglichst zu vermeiden. Zu diesem Zweck empfiehlt es sich, Systemredundanz vorzusehen. Erwägen Sie beispielsweise die folgenden Empfehlungen (unter Berücksichtigung der potenziell höheren Verwaltungskosten):
Ob man sich jetzt daran hält oder nicht. Bzw. das "Risiko" eingeht oder kontrollieren kann ist jeden seine eigene Entscheidung.
So sieht es Microsoft:
Vermeidung einzelner Fehlerquellen
Bei der Planung für die Bereitstellung virtualisierter Domänencontroller sollten Sie darauf achten, einzelne Fehlerquellen (d. h. Komponenten, deren Ausfall den Ausfall des gesamten Systems verursachen würde) möglichst zu vermeiden. Zu diesem Zweck empfiehlt es sich, Systemredundanz vorzusehen. Erwägen Sie beispielsweise die folgenden Empfehlungen (unter Berücksichtigung der potenziell höheren Verwaltungskosten):
- Führen Sie mindestens zwei virtualisierte Domänencontroller pro Domäne auf anderen Virtualisierungshosts aus. Dadurch wird das Risiko verringert, bei Ausfall eines Virtualisierungshosts alle Domänencontroller zu verlieren.
- Verwenden Sie zur Ausführung der Domänencontroller unterschiedliche Hardware (z. B. unterschiedliche CPUs, Hauptplatinen oder Netzwerkadapter), wie auch für andere Technologien empfohlen. Dadurch minimieren Sie Auswirkungen von Fehlfunktionen, die auf bestimmte Elemente (z. B. Anbieterkonfigurationen, Treiber, Hardwaremodelle oder Hardwaretypen) beschränkt sind.
- Domänencontroller sollten möglichst auf Hardware ausgeführt werden, die sich in unterschiedlichen geografischen Regionen befindet. Dies verringert die Auswirkungen von Notfällen oder Fehlern an einem bestimmten Standort, an dem Domänencontroller gehostet werden.
- Versehen Sie all Ihre Domänen mit physischen Domänencontrollern. Dies verringert die Auswirkungen einer Fehlfunktion einer Virtualisierungsplattform (von der auch die von der Plattform abhängigen Hostsysteme betroffen wären).
Ob man sich jetzt daran hält oder nicht. Bzw. das "Risiko" eingeht oder kontrollieren kann ist jeden seine eigene Entscheidung.
Danke an SomebodyToLove und allen anderen danke für die Steinigung!