Jump to content

gerd33

Members
  • Gesamte Inhalte

    247
  • Registriert seit

  • Letzter Besuch

Profile Fields

  • Member Title
    Newbie

Letzte Besucher des Profils

Der "Letzte Profil-Besucher"-Block ist deaktiviert und wird anderen Benutzern nicht angezeit.

Fortschritt von gerd33

Rising Star

Rising Star (10/14)

  • Erste Antwort
  • Engagiert
  • Erster eigener Beitrag
  • Eine Woche dabei
  • Einen Monat dabei

Neueste Abzeichen

16

Reputation in der Community

5

Beste Lösungen

  1. Hallo zusammen, eine kleine Frage an die Experten hier im Forum: Auf meinem Primär-Server habe ich fünf Datenbanken. Diese werden als Merge Replikation auf mein Notebook übertragen. Wenn ich jetzt ein Back-up der Datenbanken des Notebooks nach dem Replikationsvorgang anfertige: Ist dieses Back-up mit den Datenbanken des Primärservers in jeder Hinsicht identisch, d.h. könnte ich diese Datenbanken als Sicherung verwenden? Freue mich über jeden Hinweis, Gerd
  2. Heureka. Mein Denkfehler war, dass ich nicht berücksichtigt habe, dass differenzielle Sicherungen sich immer auf die explizit letzte Vollsicherung beziehen. Da meine Vollsicherung sowohl lokal auf RDX Medium als auch 3x wöchentlich in der Cloud erfolgt habe ich *** an meinem Test System teilweise die differenzielle Sicherungen mit der letzten Vollsicherung, aber auch teilweise mit der vorletzten Vollsicherung versucht zurück zu sichern, was in diesem Fall natürlich nicht funktionieren konnte. Das war wohl die Lösung. Anstatt die Vollsicherung in der Cloud über einen eigenen Wartungsplan zusätzlich zur täglichen RDX-Vollsicherung erneut zu erstellen werde ich jetzt die Vollsicherung nur einmal täglich erstellen lassen, aber über einen Kopierautomatismus dreimal wöchentlich in die Cloud hochladen lassen.
  3. Habe heute Kontakt mit einem IT Dienstleister aufgenommen, der die Erstkonfiguration professionell vornehmen wird und auch hinterher Support leisten kann. Lt. dessen eigener Website "Microsoft SQL-Server ist unser Business, Datenbanken sind unsere Expertise:" Kann mir relevanten Datenverlust nicht leisten. Lass ich doch lieber die Profis vor Ort ran.
  4. Hallo zusammen, bezüglich der differenziellen Datensicherung habe ich mich jetzt einmal im Rahmen einiger YouTube Videos von noeffects halbwegs fit gemacht und das ganze lokal an meinem Testsystem durchexerziert. Die Tatsache, dass sowohl die Vollsicherung als auch die differenzielle Sicherung in ein und derselben Datei zusammengefasst werden, lässt mich etwas ratlos zurück. Auf der einen Seite habe ich eine große Datei (knapp 30 GB Vollsicherung), die über ein Festplattenverzeichnis in die Cloud übertragen wird. Auf der anderen Seite kommt bei der stündlichen differenziellen Sicherung jeweils eine Datei von einigen MB hinzu. Nun ist meine ganz banale Befürchtung, dass der Prozess einer Datei Vergrößerung in der Cloud nicht funktionieren könnte: gerade wegen der eingeschränkten Upload-Speed. Die Cloud wird ja wie ein normales Festplattenlaufwerk angesprochen, aber die Übertragung vom HD-Ordner in die Cloud ist ja DSL-bedingt limitiert. Heisst dann doch eigentlich, dass auf meinem lokalen und der Cloud zugeordneten HD-Laufwerk die differenzielle Sicherung mit der Vollsicherung zusammengefasst wird und die „neue“ Vollsicherung dann in die Cloud hochgeladen wird, was mehrere Stunden dauert. Oder sehe ich da etwas falsch??
  5. Hallo zusammen, kleine Frage zur Datensicherung mittels Wartungsplänen. In meinem SQL Server 2022 Standard habe ich für die Datenbanken zwei Wartungspläne: im 1. Wartungsplan werden die vollständigen Datenbanken dreimal wöchentlich jeweils nachts gesichert. Zusätzlich läuft über einen 2. Wartungsplan eine Differenzielle Sicherung während der Arbeitszeiten von 7:00 Uhr bis 19:00 Uhr im stündlichen Abstand. Die Sicherungen werden ordentlich auf der HD beziehungsweise in der Cloud abgelegt. Beim zurückspielen der Datenbanken kommt es gelegentlich zu Problemen, die ich nicht nachvollziehen kann. Datenbanken, die 1Tage nach der vollständigen Sicherungen zurückgespielt werden sollen (zum Beispiel Datenbank vom 29.08. plus differenzielle Sicherung vom 30.08., werden zusammengesetzt (alle beide in „Sicherungsmedien auswählen“ eingefügt) und zurückgesichert. Versuche ich aber, die vollständige Sicherung vom 29.08. mit einer differenziellen Sicherung vom 31.08. zurückzuspielen, geht das nicht. Meine Vermutung ist, dass sich eine differenzielle Sicherung nur auf die jeweilige letzte vollständige Sicherung bezieht, und irgendwo ein „Ablaufdatum„ hat. Die große Frage die sich stellt, ist dann: Woher weiß der SQL Server wann ich zuletzt eine vollständige Sicherung angefertigt habe, auf die die differenzielle Sicherungen dann aufbauen? Wie lange darf die vollständige Sicherung vor der differenziellen Sicherung zurückliegen, damit die Datenbanken noch zusammengesetzt werden können? Scheint mir alles ziemlich verwuselt zu sein. Dr. Google konnte mir auch nicht weiter helfen. Bin für jede Info dankbar Gerd
  6. Inm Installationshandbuch für meine Software wird das gefordert, ist allerdinsg das Handbuch für den 2019 SQL-Server. Für den 22er Server gibts noch kein Handbuch. Software läuft aber auch ohne die Funktion. Denke mal, dass die dann gar nicht benötigt. wird. Vielen DAnk!
  7. Hallo zusammen, wo versteckt sich dir Funktion "client connectivity sdk" in SQL Server 2022 Standard? Muss ich lt. Installationsmanual meiner Software aktivieren, finde sie aber nicht. DAnke für ,jeden Hinweis, Gerd
  8. Habe soeben die "MetaBase.xml" ,wie von NorbertFe verlinkt, modifiziert. SMTP über IIS6 lüppt jetzt. Muss nur noch die Relay-Berechtigungen eintragen, damit niemand mit Fake-Absendern Mist baut. Allerdings habe ich eine Fehlermeldung von mmc.exe immer wenn eine mail versendet wird, stört aber nicht weiter. Name der fehlerhaften Anwendung: mmc.exe, Version: 10.0.20348.1906, Zeitstempel: 0xd54ba8ed Name des fehlerhaften Moduls: MFC42u.dll, Version: 6.6.8063.0, Zeitstempel: 0x0dfc7484 Ausnahmecode: 0xc0000005 Fehleroffset: 0x0000000000012c3a ID des fehlerhaften Prozesses: 0x838 Startzeit der fehlerhaften Anwendung: 0x01d9d210156d74e6 Pfad der fehlerhaften Anwendung: C:\Windows\system32\mmc.exe Pfad des fehlerhaften Moduls: C:\Windows\system32\MFC42u.dll Berichtskennung: 339c02f7-eede-442b-8894-c04a407a8597 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
  9. SNMP, IPMI, RMM sind für meinen einzelnen Server zu aufwändig. Werde mir mal die 3 von Dukel genannten Teile ansehn.
  10. "nimm einen anderen smtp service. Der von MS ist seit Jahren deprecated." Habe mal den SMTP2Go ausprobiert. Leider muss ich da beim Versenden Username / Password eingeben. Beim Intel Raid-Manager kann man ja nur die Host-Adresse eingeben, jedoch keine Zugangsdaten des SMTP Servers. Anonyme SMTP Dienste gibt es ja schon seit Jahren nicht mehr. Gibts da noch Alternativen?
  11. Danke für die Super Info. Bei meinem alten 2012 R2 läufts ja noch perfekt. Hätte MS ja auch mal bei neueren Versionen aus dem IIS-6 Manager rausnehmen können bzw. das Feature gar nicht erst im Server Manager anbieten sollen. Beste Grüße von Gerd
  12. Hallo zusammen, bei meinem neue Win Server 2022 Standard muss ich den SMTP Server aktivieren, damit mein Raid-Controller Fehlermeldung an meien mail übermittlen kann. Habe den SMTP Server aktiviert und im IIS-6-Manager konfiguriert, D.h. Mailkonto, Zugangsdaten eingetragen. Mit SMTP Tool bekomme ich kurzzeitig bei der Verbindung mit "localhost" eine Anzeige "220 ionos.de Microsoft ESMTP MAIL Service, Version: 10.0.20348.1 ready at Wed, 16 Aug 2023 16:10:58 +0200", d.h. Verbindung uzum Provider steht. Lasse ich mir die Eigenschaften des Servers anzeigen, ploppt die Fehlermeldung (s. Screenshot) auf. Versuche ich eine Verbindung mit dem Raid-Manager zu localhost herzustellen, um eine mail zu versenden, das gleiche Problem und der SMTP-Server bleibt stehen. Hat jemand eine Idee, was da los sein kann? Habe schon die IIS Rolle deinstalliert und neu installiert, ebenso das Feature "SMTP-Server". Hat nicht geholfen. Danke für jede Info, Gerd
  13. Der Hinweis mit dem Consulting ins Haus holen ist gar nicht übel. Muss mal etwas rumggogeln, ob ich im Kölner Raum jemanden finde, der Ahnung von der Materie hat. Leider sind etliche Systemhäuser auch nur im Verkaufen gut; gerade vom SQL Server sage viele, dass sie sich damit nicht auskennen. Würde auch gerne einen guter IT-Dienstleister als festen Ansprechpartner mit dabei haben, nur für den Fall, dass ich mal, irgendwann die Praxis abgebe. Mediziner haben nicht alle eine gleich gute IT-Affinität. Vielleicht finde ich da ja jemanden. Die Frage " warum das nur in die Cloud und nicht Lokal? " : Kann ich theoretisch auch mitmachen, nur sind dann die RDX-Medien schneller voll. Die Ionos-Cloud (Hidrive) hat 2TB; das sollte allemal ausreichen, zumal da auch die Gruppenlaufwerke der Praxis mit drauf gesichert sind. Und der Download der differenziellen backups aus der Cloud geht sehr schnell, da nur wenige MB groß.
  14. Über die Größe der differentiellen Backups mache ich mit keine Sorgen, zumal nach dem wöchentlichen Full Backup die differenziellen Backups der Vorwoche gelöscht werden können. Die volle Backup-Sicherung in der Cloud kann nur am Wochenende erfolgen, da die Internetanbindung in der Praxis hier nur 50er Leitung ist. Schneller geht nicht, Glasfaser nicht in Aussicht. Die größte Einzel-DB hat ca. 30 GB, die gesamten differenziellen DBs, die stündlich in der Cloud landen haben nur ca. 20 MB., d.h. nach 1 Woche sind hier nur ca. 2 GB an differenziellen Backups in der Cloud + die 30 GB der letzten Vollsicherung. 30GB täglich in die Cloud hochzuladen, würde mein Netz massivst ausbremsen. Zumal im Tagesverlauf auch die Nebenpraxis über VPN auf die DB zugreift. Die ganzen SIcherungsroutinen habe ich mit dem Wartungsplan-Assistent erstellt; nachdem keine Fehlermeldung mehr kommen, gehe ich davon aus, dass ich das alles richtig gemacht habe. RTO und RPO hab ich bislang nix von gehört; Bei der Installation meiner Datenbanken auf dem SQL Server habe ich mich an die Manuals meines Software-Lieferanten gehalten. Auf meinem aktuellen System (Win Server 2012, SQL Server 2014) läuft der Kram seit 2015 stabil (allerdings nur mit nächtlicher Sicherung auf RDX-Mediium), nur dass jetzt einfach mal eine neue Hardware mit neuer Software fällig ist. Der Umzug auf den neuen Server ist ohnehin schwierig genug: Es sind auf dem "alten SQL-Server noch 2 Datenbank-Instanzen anderer Hersteller vorhanden (Anbindung medizintechnischer Geräte), diese DBs werden aber von den jeweiligen Vertragshändlern umgezogen. Dadurch wird sich der Migrationsprozess ohnehin über mehrere Wohen erstrecken. Ist aber unproblematisch, da so lange beide Server online bleiben und nur die Ausgabe-Dokumente der Medizintechnischen Geräte (PDFs) statt in den Importpfad des "alten" Servers in den Importpfad des "neuen" Servers geschrieben werden, wo sich in diesem freigegebenen Verzeichnis die Software die Dateien holt und in eine SQL-Datenbank importiert.
  15. Endlich hat es geklappt. Mein Fehler war wohl, dass die Vollsicherung von einem anderen Rechner (SQLServer 2014) übernommen wurde und die differenzielle Sicherung auf dem neuen Rechner mit SQLServer 2022 erstellt wurde. Die Vollsicherung hatte alsm Eigentümer "NT-Authority, die differenzielle Sicherung hingegen "sa". Könnte evtl. die Ursache gewesen sein. Nachdem ich die Datenbank vom alten Server auf den neuen Server portiert hatte (unproblematisch) habe ich dort erneut eine Vollsicherung gemacht, mehrere Datensätze geändert und dann eine sequenzielle Sicherung durchlaufen lassen. Das Zusammenführen der beiden Sicherungen im Management Studio klappte dann problemlos. Verwundert hat mich nur, dass sowohl die Voll- als auch die differenzielle Sicherung im Rücksicherungs-Fenster im Management-Studio jeweils die Reihenfolge "1" hatten. Hat aber die Rücksicherung nicht beeinträchtigt. Ob es Sinn macht, eine zusätzliche Transaktionsprotokoll-Sicherung turnusmäßig durchlaufen zu lassen, weiss ich nicht, der Sinn erschließt sich mir nicht. Im Produktivbetrieb werde ich eine wöchentliche Vollsicherung in der Cloud, eine stündliche sequenzielle Sicherung, nur tagsüber, ebenfalls in der Cloud und eine nächtliche Vollsicherung auf einem täglich gewechselten RDX-Medium in die Wartungspläne implementieren. Danach dürfte das System dann wohl Safe sein. Danke für eure Unterstützung, Gerd
×
×
  • Neu erstellen...