[gelöst] Vorgehensweise bei Wiederherstellung SQL-Backup

[ThomasFerstl]

Heyho,

ich habe mich die letzte Zeit einmal mit der Wiederherstellung der SQL-Sicherung einer NAV-Datenbank beschäftigt. Im Testszenario ist der produktive SQL-Server (2008R2) vollständig ausgefallen und die SQL-Backups sollen nun auf einer völlig neuen Maschine wieder eingespielt werden.

Die Datensicherung wurde wiederhergestellt und die SQL-Anmeldungen wurden anschließend auf dem neuen System eingerichtet. Allerdings klappt der Zugriff über den NAV-Client ausschließlich für Anmeldungen mit der Serverrolle "Sysadmin". Normale "Public"-User werden abgewiesen, da "Benutzername oder Kennwort ungültig" sind.
Das SQL-Server Management Studio verrät bei einem Blick in die Eigenschaften der Anmeldungen dann auch, daß bei Benutzerzuordnung keine der Anmeldungen den Haken bei der NAV-Datenbank gesetzt hat. Ich kann das aber leider nicht per Hand setzen. Synchronisieren aus Navision klappt ebensowenig, wie das Datenbanklogin im Client per F4 zu löschen und neu anzulegen.

Was hab ich wo falsch gemacht?

Zuletzt geändert von ThomasFerstl am 14. November 2017 11:25, insgesamt 2-mal geändert.

Dein Ziel ist die Synchronisierung der Logins aus NAV heraus.
Benutzt ihr keine WIndows Logins?

Bist Du sicher, dass der SQL Server im Mixed Mode ist, damit er auch DB logins akzeptiert? Von Haus aus macht er Standardmäßig nur Windows-Logins.

Bist Du sicher, dass der SQL Server im Mixed Mode ist, damit er auch DB logins akzeptiert? Von Haus aus macht er Standardmäßig nur Windows-Logins.

Der "MixedMode" ist gesetzt. Wie gesagt, wenn ein Datenbanklogin über "Sysadmin" verfügt, kann ich mich problemlos an der Datenbank anmelden. Trotzdem bringt mir auch eine Synchronisierung in Navision nichts. Normale "Public"-User können sich nicht anmelden.

Hast du die xp_ndo.dll auf dem neuen Server eingespielt?

Gruß, Fiddi

Ich habe Navision auf dem Server über das Setup installiert und ClassicClient und SQL-Option ausgewählt. Die beiden Extended Stored Procedures wurden dann vom Setup auch richtig angelegt.

die xp_ndo.dll braucht NAV doch nur für Windows-logins (??)

habt ihr die master-Db ebenfalls auf dem neuen Server wiederhergestellt??

habt ihr die master-Db ebenfalls auf dem neuen Server wiederhergestellt??

Nein. Läßt sich die Master eines Servers denn so ohne weiteres auf einem anderen SQL-Server wiederherstellen?

wenn du nicht alle sicherheitsprinzipale, linked server, konfigurationseinstellungen etc. per Hand nachpflegen willst, empfiehlt sich auf jeden Fall die master.db wiederherzustellen.
bei einem Desaster Recovery wäre das meiner Meinung nach sogar Pflicht.

Danke für den Tipp. Ich probier das mal aus.

Die "master" Datenbank eines anderen SQL Servers zu verwenden ist keine gute Idee - das setzt voraus, dass die Installation bis ins letzte Detail identisch ist (z.B. was Laufwerkspfade etc. angeht) ... sonst wird's weh tun ...

Logins werden mit diesem Verfahren übertragen: http://support.microsoft.com/kb/918992

(Der Artikel bezieht sich zwar auf SQL 2005, das gilt aber auch noch mit SQL 2012)

PS: Und nicht vergessen, den USers wieder die Rolle sysadmin oder/und db_owner zu ENTZIEHEN!!!

moment hier gehts um Desaster Recovery, da ist es durchaus legitim den Server 1:1 wieder herzustellen

moment hier gehts um Desaster Recovery, da ist es durchaus legitim den Server 1:1 wieder herzustellen

"1:1" bedeutet aber,dass sämtliche Laufwerke & Pfade identisch sind!!! Die "master" db enthält die DB Kataloge, die u.a. auch die Dateipfade enthält - wenn hier ungültige Informationen übertragen werden, dann sind die Benutzerdatenbanken nicht verfügbar.
Wenn man eine "master" DB aus einem Backup restauriert, dann muss/sollte man stets danach alle Benutzerdatenbanken danach ber Restore oder Attach aufbauen.
http://msdn.microsoft.com/de-de/library/ms175535%28v=sql.90%29.aspx
http://msdn.microsoft.com/de-de/library/ms190679%28v=sql.90%29.aspx

Für ein HA Szenario ist sowas doch eher nix!?! HA heißt, dass die Server Downtime minimal sein muss; wenn man dann erst noch mit master etc herumfrickeln muss - und dann dabei was schief geht - wird's eher ziemlich "stressig".

Besser ist IMHO, einen zweiten Standby Server sauber von Grund auf einzurichten. Warum nicht Logshipping oder Mirroring einrichten? Ein Backup-Restore (aka "Cold Standby") dauert am längsten ...
Die Logins können dabei am einfachsten mit der MS Methode übertragen werden, das kann man auch automatisieren/optimieren, so dass die Logins periodisch übertragen werden - inkl. der korrekten SID und der Passwörter (natürlich verschlüsselt).
Dann muss man im "Disaster" nur (?) noch die Standby DB online schalten, die Clients verbinden und weiter gehts ...

Hier ein paar Inspirationen: http://dynamicsuser.net/blogs/stryk/archive/2011/05/13/directions-emea-2011-high-availability-options-with-nav-and-sql-server.aspx

Um einen Server wirklich 1:1 wiederherzustellen, könnte man auch über "Virtualisierung" nachdenken ...

Ich muss da mal nachfragen:

1. Wie sichert man denn einen NAV-Server (SQL kein Native) am besten?
2. Darf man denn eine SQL-Server-Lizenz (und die darunter liegende Windows-Server-Lizenz) für einen Cold-Standby nutzen?
3. Ist es im Desaster-Fall evtl vernünftiger von einer NAV-Sicherung (fbk) zurückzusichern? Wie verhält es sich dann mit den Usern?
4. Ist eine VHD-Image des NAV-Servers eine Alternative? Hyper-V, letzte DB-Sicherung zurückspielen und weiter geht es?

Volker

1. Wie sichert man denn einen NAV-Server (SQL kein Native) am besten?

Mit einem gescheiten Backup- Programm (Arcserve,Backup Excec,..) (Agenten), das nicht nur die SQL-DB sondern das komplette System sichert.

2. Darf man denn eine SQL-Server-Lizenz (und die darunter liegende Windows-Server-Lizenz) für einen Cold-Standby nutzen?

Bin ich im Moment überfragt.

3. Ist es im Desaster-Fall evtl vernünftiger von einer NAV-Sicherung (fbk) zurückzusichern? Wie verhält es sich dann mit den Usern?

Mit Arcserve habe ich eine 50GB- Datenbank innerhalb von ca. 15 Minuten von einem LTO4- Laufwerk betriebsbereit wiederherstellen können (damit dürfte sich die Frage nach der FBK erübrigen). Aufwändiger wird es, wenn du ein regelmäßiges Backup auch des Transaction- Logs durchführst (Funktionalität mit FBK nicht möglich). Damit kannst du eine DB bis zum letzten Backup des Transaction- Logs wiederherstellen (bei Totalverlust des Systems). Ist nur die Datenbank- Datei betroffen, kannst du die DB komplett wiederherstellen. Deshalb sollte man Datenbank- Datei(en) und Transaction-Log nach Möglichkeit auf getrennten physikalischen Platten betreiben.

4. Ist eine VHD-Image des NAV-Servers eine Alternative? Hyper-V, letzte DB-Sicherung zurückspielen und weiter geht es?

Nur dann, wenn du den SQL-Server für die Sicherung heruntergefahren hattest. Denn das sichern der Hyper-V- Datei sorgt nicht für einen konsistenten Zustand der SQL-Server- Dateien. Der SQL-Server mag es allerdings nicht sonderlich gerne herunter gefahren zu werden. Deshalb ist das keine gute Idee.

Gruß, Fiddi

3. Ist es im Desaster-Fall evtl vernünftiger von einer NAV-Sicherung (fbk) zurückzusichern? Wie verhält es sich dann mit den Usern?

Mit Arcserve habe ich eine 50GB- Datenbank innerhalb von ca. 15 Minuten von einem LTO4- Laufwerk betriebsbereit wiederherstellen können (damit dürfte sich die Frage nach der FBK erübrigen). Aufwändiger wird es, wenn du ein regelmäßiges Backup auch des Transaction- Logs durchführst (Funktionalität mit FBK nicht möglich). Damit kannst du eine DB bis zum letzten Backup des Transaction- Logs wiederherstellen (bei Totalverlust des Systems). Ist nur die Datenbank- Datei betroffen, kannst du die DB komplett wiederherstellen. Deshalb sollte man Datenbank- Datei(en) und Transaction-Log nach Möglichkeit auf getrennten physikalischen Platten betreiben.

Hi Fiddi,

das stimmt aber doch nur, wenn Du auf die gleiche Maschine zurücksicherst, sonst hast Du wie Stryk ja oben schreibt das Problem mit der master-DB. Und genau für den Fall einer Rücksicherung auf eine andere Maschine stellt sich die Frage, ob bei einer Rücksicherung aus einer fbk nicht die User richtig auf der neuen Maschine angelegt werden. Somit würde das Problem des OP gar nicht auftreten.

Mein Gedankengang wäre dann, dass man in größeren Abständen fbk's anlegt uns somit die User alle (zu 99%) auf der neuen Maschine richtig in der NAV-DB hätte und dann die aktuellste SQL-DB drüber rücksichert.

Volker

das stimmt aber doch nur, wenn Du auf die gleiche Maschine zurücksicherst, sonst hast Du wie Stryk ja oben schreibt das Problem mit der master-DB. Und genau für den Fall einer Rücksicherung auf eine andere Maschine stellt sich die Frage, ob bei einer Rücksicherung aus einer fbk nicht die User richtig auf der neuen Maschine angelegt werden. Somit würde das Problem des OP gar nicht auftreten.

deshalb ist der Benutzer 'sa' bei mir auch immer ein NAV- Benutzer (falls er fehlt, kann man Ihn per SQL- Skript mit SUPER- Rechten in der SQL- Admin- Konsole nachtragen)
Sicherst du in der gleichen Domäne zurück, kannst du, nachdem du dich per DB- Anmeldung Zugang zur DB verschafft hast, die Benutzer synchronisieren (Windows Benutzer). Hast du eine neue Domäne, musst du die Windowsbenutzer eh neu einrichten. Die Datenbank- Benutzer müssen in diesem Fall allerdings neu angelegt werden, da sie ja auch dem SQL-Server neu sind, das wäre allerdings auch bei der FBK so, denn auch die legt keine SQL- Benutzer an . Das Anlegen der Benutzer dürfte aber im Zweifel sehr schnell per SQL-Skript möglich sein.


Gruß, Fiddi

Das Anlegen der Benutzer dürfte aber im Zweifel sehr schnell per SQL-Skript möglich sein.

Und genau dabei kann das angesprochene MS Script helfen! Das erzeugt eben die nötigen CREATE LOGIN Statements (inklusive SID und verschlüsselten Passwörtern bei DB Logins); und das Ganze kann man natürlich recht einfach "pimpen", indem man z.B. vor dem CREATE ein DELETE macht, oder ggf. lieber ein ALTER, oder ob man zum CREATE LOGIN auch och ein CREATE USER erzeugt etc.!

Wie war das denn jetzt noch mit der Lizensierung für Standby- Server?

Keine zusätzliche SQL-Lizenz, wenn Standby- Server
Wohl aber Windows- Lizenzen für Witness- und Standby- Server

Gruß, Fiddi

Hi Fiddi,

wenn ich das richtig verstehe, dann geht cold Standby für den Windowsserver wenn eine Software Assurrance(SA) vorhanden ist. http://www.microsoft.com/Licensing/software-assurance/cold-backup.aspx

Volker