mcdaniels

Die Datensicherung ist es nicht. Ist gerade gelaufen und fertig geworden. Eintrag betr. Datensicherung ist im Eventlog vorhanden. Replikation funktioniert.

Hi, die MaxOfflineTimeInDays wurde auf beiden DCs nach oben geschraubt und steht noch auf diesem Wert. EDIT: Wert steht auf: 999 Backup hatte ich bislang noch nicht deaktiviert. Muss ich testen. DFS Dienst wurde immer auf beiden Servern neu gestartet. Werd ich mal nur auf einem Server testen.

Servus Nils, es handelt sich beim DC1 um einen physischen Rechner (Datensicherung Arcserve UDP) und beim DC2 um eine VM (Datensicherung Veeam). Danke! LG

Hallo, ich habe 2x Server 2012 DC (aktueller Patchstand), die offenbar ein Problem bei der DFS-Replikation haben. Ich kann allerdings nicht nachvollziehen, warum das so ist. Aufgefallen ist mir das zuletzt, als ich eine GPO erstelle, die dann auf einem Client (gpupdate) eine Fehlermeldung ausgeworfen hat. Ich habe die GPO dann wieder gelöscht und versucht den Fehler zu finden. Interessanterweise steht überhaupt nichts in den Eventlogs. Nur, dass die DFS-Replikation am Abend aufgrund einer Datensicherung gestoppt wurde / danach wieder ordnungsgemäß hochgefahren ist. Warnmeldung ist die Folgende: Der DFS-Replikationsdienst beendet die Kommunikation mit Partner SRV-DC2 für Replikationsgruppe Domain System Volume aufgrund eines Fehlers. Der Dienst wird regelmäßig versuchen, die Verbindung wiederherzustellen. Weitere Informationen: Fehler: 9036 (Zum Sichern oder Wiederherstellen angehalten) Verbindungs-ID: 2F1E8FC8-0634-4C46-A909-52A4ABEB0B94 Replikationsgruppen-ID: 13783446-D95B-4EB5-A4B2-4119C1F97545 Schließlich habe ich per DFS-Management-Konsole diverse Tests durchgeführt, die allesamt erfolgreich waren. Dennoch: legte ich auf DC1 eine Datei in den Sysvol/Domain/policies-Ordner wurde diese nicht in das Sysvol des DC2 repliziert (auch nicht umgekehrt). Irgendwann ist mir dann eingefallen, dass ich den Dienst DFS-Replikation auf beiden Servern noch neu starten könnte. Und - siehe da - die Replikation funktionierte plötzlich wieder in alle Richtungen: DC1 file erstellt -> repliziert auf DC2 -> gelöscht auf DC2 -> wird gelöscht auf DC1 DC2 file erstellt -> repliziert auf DC1 -> gelöscht auf DC1 -> wird gelöscht auf DC2 Das funktioniert dann offenbar bis zum nächsten Tag. Ggf. ist der Auslöser ja die Sicherung, die am Abend stattfindet (bei der die Replikation angehalten wird.) Was ich noch dazu sagen muss ist, dass die DFS Replikation vor einigen Monaten erst wiederhergestellt wurde, da sie fast 1 Jahr (ist niemandem aufgefallen) nicht mehr synchronisiert hat. Hatte deshalb hier mal diesen Beitrag geschrieben (Stichwort MaxOfflineTimeInDays ): Jegliche Tipps gerne gelesen

@Norbertfe @Nobbyaushb: Ja, genau! RDX waren das. Danke :)

Meiner Meinung nach MUSS ein Offlinebackup unbedingt sein. Ich würde auf keinen Fall nur auf Disks sichern, die permanent online sind! Ich kenne einen Fall, da wird z.B. auf Cartridges "=Wechselfestplatten" gesichert (4 Platten, jede Woche eine - in Rotation). Die einzelnen "Cartridges" - die im Endeffekt 2,5" Sata-Platten sind, sind ordentlich teuer. Mir fällt dummerweise der Name nicht ein. Die Datenmenge ist hierbei natürlich der Knackpunkt. Am Schönsten finde ich noch immer Disk2Disk2Tape. Da aber der Datendurchsatz zum Band leidet, wenn man viele kleine Einzeldateien sichert, sollte zuvor beim Disk2DiskBackup ein "Image mittels Backupsoftware" erstellt werden, sodass in weiterer Folge nur eine große Datei auf das Band geschrieben wird. Das Bandlaufwerk muss weniger oft stoppen, anfahren = es lebt länger.

Hallo, danke für die bisherigen Rückmeldungen! @Marco31 die Backupgeräte nur zwecks Backup hochzufahren war auch schon einer unserer Gedanken. Ich dachte hier z.B. an eine QNAP, die nur fürs Backup hochfährt, sichert und dann wieder runterfährt. @zahni: Wieso durcheinander? Alles läuft auf dem Backupserver zusammen (phys Server mit Arcserve UDP in ein Image, um möglichst konstanten Datenstream zum Band zu haben, VM mit Veeam) -> das geht dann auf Band + liegt auf dem Backupserver. zusätzlich NAS (robocopy der Arbeitsdaten) um zb. kurzfristig Dateien wiederherstellen zu können. (wenn der User etwas löscht). Hat sich über Jahre so bewährt. Aber, du hast schon recht. Prävention ist auch ein großer Teil. Ausführbare Dateien kommen bei mir nicht durch, weder per Mail, noch als Download. (Ausnahme Server - WSUS). Allerdings nur, wenn auf der Firewall auch eine HTTPS Deep Inspection stattfindet, sonst haut das (logischerweise) nicht hin. Verbindungen zu known bad hosts werden so gut wie möglich geblockt (Fortigate). Hiermit sollte das nachladen von Schadcode erschwert werden, falls im Netz mal etwas "losgeht". Auf den PCs ist ein Virenschutz installiert, der allerdings immer mindestens 2 Tage zu spät checkt, wenn es sich um eine verseuchte DOC Datei handelt (hab ich getestet). Der Punkt sind nichtmal ausführbare Dateien. Im Grunde kommen ja z.B. Docs durch, die dann ein Makro mit an Bord haben. Ich hab das zwar per GPO soweit runtergeschraubt, dass Makros manuell aktiviert werden müssen (ganz abdrehen spielt es nicht), das Problem bleibt aber der User. USB abdrehen ist nicht möglich, da es hier immer wieder Datenaustausch gibt (nach vorhergehendem Scan), vielleicht könnte man das über eine Cloud abwickeln, allerdings ist das ja auch nicht viel sicherer... Eigentlich müsste man den Datenaustausch generell abdrehen Die Sache ist, dass es nie eine 100%ige Sicherheit geben kann, dennoch will ich so gut wie möglich vorbereitet sein. Was mir noch immer nicht ganz klar ist, gehen diese Cryptodinger grundsätzlich nur mit den Rechten los, die der User hat, oder schafft das Ding es mittlerweile, im Hintergrund zu schlummern und Anmeldedaten im LAN zu sammeln? Wenn man den Artikel auf Heise liest, könnte man bald denken, dass es besser ist, Rauchzeichen zu geben. :-P Kann man irgendwo nachlesen, was hier wirklich geschieht? (Dann könnte man nämlich noch bessere Vorkehrungen treffen). Als Zusatzinfo: Ich muss mit minimalsten Mitteln auskommen. Viel mehr als oben Erwähntes ist nicht drinnen.

@lamu wie groß sind "einige GB"

Hallo, wie groß ist die PST-Datei bzw. hast du denn schonmal eine Reparatur der PST Datei versucht? LG

Hi, vorweg danke für die Antworten. @djmaker: NAS / Backupserver ist in der Domäne. Ich denke mir aber gerade, wenn der User zb. den Cryptolocker ausführt, dann läuft der ja unter dem Usercontext. Da aber die User keinen Zugriff auf den Backupserver haben, kommt die "Verschlüsselung" gar nicht so weit. Oder sehe ich das falsch? @jreckziegel: Es ist ARCSERVE UDP Console + ARCSERVE UDP 6.5 im Einsatz, abgesehen davon ARCSERVE-BACKUP 17.5 STD (Standalone) --> Arcserve UDP am zu sichernden Server, ARCSERVE UDP Console / Arcserve Backup am Backupserver.

Datenverlust: Wenn 1 Tag "weg" ist, wäre das noch zu verschmerzen. Wiederherstellungsdauer: 1/2 - 1 Tag wäre "möglich". Betreffend Änderungen: Budgetschonende / Ich weiß, dass dieser Ansatz in Sachen Backup wenig sinnvoll ist, dennoch ist es leider so.

Hallo, ich bin gerade dabei mir eine "bessere" Backupstrategie zu überlegen. Zur Zeit sichere ich ca 5TB an Daten, die auf 3 Server (physisch) und 8 Server (virtuell) verteilt sind. Schema aktuell Physische Server sichern per Arcserve UDP auf den Backupserver (Backupstore) -> Erstellen dort quasi ein Image, das man auch mounten kann, sofern ARCSERVE UDP läuft. Virtuelle Server (ESXI) sichern per Veeam auf den Backupserver Vom Backupserver werden GFS Bandsicherungen (Mo-Do inkr, Freitag Vollsicherung) gezogen. (=die Images, die die Datensicherung erstellt) Damit noch nicht genug: Tägliche Sicherung der Arbeitsdaten per Robocopy auf ein NAS. (nur geänderte Daten). Die Sicherung ist ja recht nett, nur bin ich (abgesehen vom NAS) bei allen Wiederherstellungsszenarien von Zusatzsoftware abhängig, die mir dann die gesicherten Daten "zur Verfügung" stellt UND - das ist viel schlimmer -, es gibt nur die Bandsicherung als Offlinesicherung. Worst case: Ein Cryptolocker fährt mir ins System und macht alle Daten (auch das Backup) unbrauchbar. (nur eine Annahme, die in dieser Form - aller Wahrscheinlichkeit nach - nicht eintritt). Somit wäre also der Backupserver down + die gesamte Backupplattform. D.h. man müsste den Server neu hochziehen (oder ein Recovery von einem Backup durchführen, das nicht "verseucht" ist), danach - sofern der Bandkatalog der Bänder nicht vorhanden ist - die Bänder inventarisieren / einlesen, Das Backup retour spielen (dann hätte man die Arcserve UDP Images), Das zurückgespielte UDP-Backup per Arcserve UDP öffnen, die Dateien "recovern". Sehr viele Einzelschritte, die Zeit in Anspruch nehmen. Gibt es hier eine Strategie, die es mir erlaubt, schneller an die Daten zu kommen, diese aber so zu sichern, dass sie nicht permanent online sind?

Danke an alle!

wollt ich auch gerade fragen...

ich, aufgrund meiner Interpretation der Aussage im ersten Post (vom Lieferanten), da ich nicht am Radar hatte, das 1 Corepack 4 Cores sind... ;)

Die Rechnerei ist mir schon klar. ;) Es geht aber im Endeffekt um die Cores., Ausgehend von der Minimumlizenzierung als Basis. @Norbertfe: Danke für deine Geduld :) @NilsK: :)

1 x VCPU mit einem Core = Eine Core zu lizenzieren 1 x VCPU 8 Cores = 8 Cores zu lizenzieren auf physisch übertragen: ich hab einen Sockel mit einer CPU und 1 Kern. ich hab einen Sockel mit einer CPU und 8 Kernen.

entweder das, oder ich hab ein Verständnisproblem. 1 Core Lizenz = für einen CPU-Kern, oder ist das anders gemeint? Für mich ist ein Kern etwas Anderes wie eine CPU. wenn ich nun: 2 CPUs habe mit je 4 Kernen, dann muss ich insgesamt 8 Kerne lizenzieren und nicht nur 2 CPUs. Wenn ich die Aussage von oben hernehme, würde ich dann aber nur 2 Core Lizenzen brauchen für die 2 CPUs. MS sagt dazu: Virtualisierung im Rahmen des Core-Lizenzmodells Im Rahmen des Core-Lizenzmodells müssen alle virtuellen Cores in jeder virtuellen Maschine (VM) lizenziert werden, in jedem Fall jedoch mindestens vier Cores-Lizenzen pro virtueller Maschine (VM).

Das ist ein Argument. Die Info mit den zu lizenzierenden CPUs habe ich von einem Lieferanten erhalten, der sich da "angeblich" auskennt. Deshalb ja eigentlich die Verwirrung. D.h. diese Aussage ist schlicht falsch: weil es dann eben nicht die VCpus sind sondern die VCores, um die es geht.

Das ändert gar nix, seh ich auch so. Wenn ich aber 2 vCPUs mit je 4 vCores habe, kann ich nicht sagen, dass ich nur die 2 vCPUs lizenzieren muss, oder? Die Kernfrage war eben: Lizenzierung pro vCore oder eben pro vCPU.

Hi Norbert, ich meinte ja auch die Zuweisung der CPUs in der VM. Ich kann aber einer VM eben vCPUs und vCores zuweisen. (das brauch ich dir aber nicht zu erzählenl ). Also Annahme: Die VM hat 2 CPUs (Sockel) und 4 Cores / CPU. Ich glaub, dass ich dann 2 x 4 Cores = 8 Cores = 8 Corelizenzen brauch. Sofern wir 2 nicht aneinander vorbeireden, meinst du ich müsste dann quasi nur die 2 vCPUs lizenzieren, was einer 4-Core-Lizenz entspricht? Ich find das echt schade, dass es keinen einfachen Weg betreffend Lizenzierung gibt. Da blickt man wirklich nur durch, wenn man nichts Anderes macht, wie MS-Lizenzierung.... :-(

...da bin ich mir sicher ;) Ich hätte jetzt noch diese Aufstellung hier gefunden: Anzahl VM vCores pro VM Summe vCores zu lizenzierende Cores Anzahl benötigter Core-Pakete 1 VM 2 vCores 2 vCores 4 vCores 2 Zwei-Core Pakete bestellen 1 VM 4 vCores 4 vCores 4 vCores 2 Zwei-Core Pakete bestellen 2 VM 2 vCores 4 vCores 8 vCores 4 Zwei-Core Pakete bestellen 2 VM 4 vCores 8 vCores 8 vCores 4 Zwei-Core Pakete bestellen Also doch ausschließlich die vCores und nie die VCpu?

Hallo, habe mir jetzt etliche Beiträge durchgelesen und auch unseren Händler befragt. Schlussendlich habe ich im Endeffekt nun einige verschiedene Aussagen zum Thema "SQL Server Standard 2016 / Corelizenzierung in der VM". Ausgangslage: 1x VM 2vCPUs mit je 4vCores = 8 Cores Aussage 1: Ich muss 8 Cores lizenzieren. D..h. im Endeffekt 1x Minimallizenzierung (4Cores) + zusätzliche 4 Corelizenz. Aussage 2: ich muss nur die vCPUs lizenzieren = 2 vCpus = 4 Corelizenz da die Mindestanzahl bei der Corelizenz ohnehin bei 4 Cores liegt. O-Ton dazu: Bei der Core-basierten Lizenzierung entspricht ein virtueller CPU (vCPU) einer Core-Lizenz. Hoffe, ihr könnt hier für Klarheit sorgen. Danke!

Hallo, vielen Dank für die zahlreichen Antworten und die Diskussion.

Das sehe ich auch bei Linuxclients nicht als so großes Problem. Du hast aber natürlich recht, dass die PCs auf Stand gehalten werden müssen. Die Überlegung war hier eher, dass man auch ältere PC einsetzen kann. Ich kenne noch einen: https://remmina.org/ Versuche mich gerade an einer Druckerumleitung. Das Ganze ist momentan nicht viel mehr wie ein "Projekt in meinem Kopf" bzw. innerhalb einer Testumgebung. Ich muss mir das Ganze noch durchkalkulieren. Massig an IT-Kosten wird man dadurch aber auch nicht sparen können. In Kombination damit, dass es vermutlich die eine oder andere Inkompatibilität gibt / geben wird und die Leute dann auch noch "umlernen" müssen, schaut es nur auf dem Papier (beim schnellen Hinschauen) gut aus. Ich träume ja noch immer von einer Zeit, in der alle Anwendungen (auch die Fachanwendungen) webbasiert sind und man am Desktop (betreffend OS) absolut flexibel ist. (Ab und zu träume ich aber auch von heißen Eislutschern).