8
MS SQL Backup mit Wartungsplan auf Netzlaufwerk
Moin,
bin mir nicht sicher, ob das die richtige Abteilung ist. Falls nicht, bitte verschieben.
Wir haben einen MS SQL 2012 Standard-Server, Betriebssystem ist Windows Server 2016. Ich möchte unsere Datenbanken per Wartungsplan auf ein Netzlaufwerk sichern. Die Freigabe ist auch mit einem Laufwerksbuchstaben im Windows Explorer zu sehen. Da MS SQL das aber einen Scheiss interessiert, bin ich dieser Anleitung gefolgt:
https://www.mssqltips.com/sqlservertip/3499/make-network-path-visible-fo ...
Ein Träumchen, läuft wie geschmiert. Zumindest solange, bis ich den Server neu starte, dann findet SQL nämlich den Netzlaufwerkpfad nicht mehr und Essig ist's mit der Sicherung. Ebenso, wenn der SQL-Dienst neu gestartet wird.
Dazu habe ich relativ wenig Informationen ergoogeln können, u.a. das hier:
https://www.andysblog.de/ms-sql-server-datensicherung-auf-netzlaufwerk
Prima, der gute Andy legt aber scheinbar wenig Wert auf akkurates Arbeiten (s. a. Kommentare in dem Artikel). So ist das hier doppelt gemoppelt:
Funktioniert bei mir nur so:
Ich flipper das also über das Management Studio in eine Abfrage und führe diese aus. Läuft. Ich bin mir allerdings nicht sicher, ob ich diesen Schnipsel ebenfalls in eine Abfrage kloppen muss, ich hab's getan...
Super, jetzt kann ich zumindest nach Neustart des SQL-Dienstes immer noch den Wartungsplan ausführen (lassen). Reboote ich aber den Server, ist es wieder vorbei mit der Herrlichkeit:
Ideen, irgendjemand? Ich kann das natürlich lokal sichern und dann automatisiert wegkopieren, finde ich aber unschön.
Gruß
bin mir nicht sicher, ob das die richtige Abteilung ist. Falls nicht, bitte verschieben.
Wir haben einen MS SQL 2012 Standard-Server, Betriebssystem ist Windows Server 2016. Ich möchte unsere Datenbanken per Wartungsplan auf ein Netzlaufwerk sichern. Die Freigabe ist auch mit einem Laufwerksbuchstaben im Windows Explorer zu sehen. Da MS SQL das aber einen Scheiss interessiert, bin ich dieser Anleitung gefolgt:
https://www.mssqltips.com/sqlservertip/3499/make-network-path-visible-fo ...
Ein Träumchen, läuft wie geschmiert. Zumindest solange, bis ich den Server neu starte, dann findet SQL nämlich den Netzlaufwerkpfad nicht mehr und Essig ist's mit der Sicherung. Ebenso, wenn der SQL-Dienst neu gestartet wird.
Dazu habe ich relativ wenig Informationen ergoogeln können, u.a. das hier:
https://www.andysblog.de/ms-sql-server-datensicherung-auf-netzlaufwerk
Prima, der gute Andy legt aber scheinbar wenig Wert auf akkurates Arbeiten (s. a. Kommentare in dem Artikel). So ist das hier doppelt gemoppelt:
EXEC xp_cmdshell 'EXEC XP_CMDSHELL 'net use m: \\<HOST>\<SHARE> <PASSWORD> /User:<HOSTNAME><USERNAME>' Funktioniert bei mir nur so:
EXEC XP_CMDSHELL 'net use m: \\<HOST>\<SHARE> <PASSWORD> /User:<HOSTNAME><USERNAME>' Ich flipper das also über das Management Studio in eine Abfrage und führe diese aus. Läuft. Ich bin mir allerdings nicht sicher, ob ich diesen Schnipsel ebenfalls in eine Abfrage kloppen muss, ich hab's getan...
sp_procoption @ProcName = 'map_drive_startup'
, @OptionName = 'startup'
, @OptionValue = 'on' Super, jetzt kann ich zumindest nach Neustart des SQL-Dienstes immer noch den Wartungsplan ausführen (lassen). Reboote ich aber den Server, ist es wieder vorbei mit der Herrlichkeit:
Fehler beim Ausführen der Abfrage 'BACKUP DATABASE [DATENBANK_Live] TO DISK = ...': 'Das Sicherungsmedium '\\\\SICHERUNGSGERAET\\BACKUP-FREIGABE\\DATENBANK_Live\\DATENBANK_Live_backup_2020_01_23_090002_7917337.bak' kann nicht geöffnet werden. Betriebssystemfehler 5(Zugriff verweigert).
BACKUP DATABASE wird fehlerbedingt beendet.'. Mögliche Ursachen sind folgende: Probleme bei der Abfrage, nicht richtig festgelegte ResultSet-Eigenschaft, nicht richtig festgelegte Parameter oder nicht richtig hergestellte Verbindung. Ideen, irgendjemand? Ich kann das natürlich lokal sichern und dann automatisiert wegkopieren, finde ich aber unschön.
Gruß
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 538473
Url: https://administrator.de/contentid/538473
Printed on: April 18, 2024 at 13:04 o'clock
8 Comments
Latest comment
Hi
selten so einen blödsinn gelesen wie in der MSSQLTIPS Anleitung. Ein Script um ein Netzlaufwerk zu mappen. wtf.
Angeben kannst du einfach den UNC Pfad direkt. Es funktioniert lediglich nicht mit der grafischen UI.
Das relevante ist, das der Benutzer, unter dem der SQL Agent ausgeführt wird, auch Zugriff auf den Pfad hat. In aller Regel muss also das Computerkonto berechtigt werden.
selten so einen blödsinn gelesen wie in der MSSQLTIPS Anleitung. Ein Script um ein Netzlaufwerk zu mappen. wtf.
Angeben kannst du einfach den UNC Pfad direkt. Es funktioniert lediglich nicht mit der grafischen UI.
Das relevante ist, das der Benutzer, unter dem der SQL Agent ausgeführt wird, auch Zugriff auf den Pfad hat. In aller Regel muss also das Computerkonto berechtigt werden.
1
Ne, das is an sich schon so korrekt. Ich versuche das allerdings auch über die GUI und dann geht es definitiv nicht, bevor ich der Anleitung nicht gefolgt bin, kriege ich keinen Zugriff auf das Netzlaufwerk (im SQL). Du schreibst, es funktioniert graphisch nicht, welchen anderen Weg meinst Du?
Zugriff für den SQL Agent-User ist gegeben.
Zugriff für den SQL Agent-User ist gegeben.
Angeben kannst du einfach den UNC Pfad direkt. Es funktioniert lediglich nicht mit der grafischen UI.
Doch...auch das geht in der GUI. Läuft bei uns problemlos seit Jahren. Oder meinst du das Eintragen in die Zeile Sicherungsziel? Hier trägst Du den UNC-Pfad einfach händisch ein und fertig.
Hallo,
der SQL Server Service muss auf den UNC-Pfad zugreifen können - das würde ich erst einmal etablieren.
Ändere die Anmeldung des Dienstes auf ein Benutzerkonto, dass auf das Netzlaufwerk zugreifen kann. Nach der Änderung sind die Services (Server,Agent, Browser) einmal neuzustarten.
Empfohlen ist jeweils ein eigener Domänenbenutzer sowohl für Agent als auch Service.
Wenn das erst einmal läuft und dein Herz an einem Netzlaufwerk hängt, dann binde es sein.
Gruß
Grinskeks
der SQL Server Service muss auf den UNC-Pfad zugreifen können - das würde ich erst einmal etablieren.
Ändere die Anmeldung des Dienstes auf ein Benutzerkonto, dass auf das Netzlaufwerk zugreifen kann. Nach der Änderung sind die Services (Server,Agent, Browser) einmal neuzustarten.
Empfohlen ist jeweils ein eigener Domänenbenutzer sowohl für Agent als auch Service.
Wenn das erst einmal läuft und dein Herz an einem Netzlaufwerk hängt, dann binde es sein.
Gruß
Grinskeks
Mit "UI" meinte ich das Order-Auswähl-Ding wenn man auf den "..." Button hinten klickt.
Das liegt daran, das dieses fenster im entsprechenden Userkontext läuft(bzw die Laufwerke damit sieht), der schlicht keine Netzwerkpfade eingebunden hat.
Deshalb ja auch dieser blödsinnige Workaround mit dem net use im Script.
Aber man kann den UNC Pfad einfach selbst angeben wie z.B bei diesem Bildchen (aus dem Netz)
Ich würde allerdings auch dazu raten den SQL Service mit einem Managed Service Account zu betreiben. Dann ist das ein "normaler" User im AD, du kommst auf die Netzwerkressourcen ohne hickhack und das PW wird auch regelmäßig geändert.
Das liegt daran, das dieses fenster im entsprechenden Userkontext läuft(bzw die Laufwerke damit sieht), der schlicht keine Netzwerkpfade eingebunden hat.
Deshalb ja auch dieser blödsinnige Workaround mit dem net use im Script.
Aber man kann den UNC Pfad einfach selbst angeben wie z.B bei diesem Bildchen (aus dem Netz)
Ich würde allerdings auch dazu raten den SQL Service mit einem Managed Service Account zu betreiben. Dann ist das ein "normaler" User im AD, du kommst auf die Netzwerkressourcen ohne hickhack und das PW wird auch regelmäßig geändert.
Moin,
Euch vielen Dank! Ich hatte in der Tat nur den Benutzerkontext für den SQL Agent auf ein entsprechendes Konto umgestellt. Das habe ich für den SQL Server auch nachgeholt, jetzt rennt es ohne weitere Anpassungen.
Das mit dem Managed Service Account sehe ich mir mal genauer an.
Schönes Wochenende allen!
Euch vielen Dank! Ich hatte in der Tat nur den Benutzerkontext für den SQL Agent auf ein entsprechendes Konto umgestellt. Das habe ich für den SQL Server auch nachgeholt, jetzt rennt es ohne weitere Anpassungen.
Das mit dem Managed Service Account sehe ich mir mal genauer an.
Schönes Wochenende allen!
Dann lass ich dir als Tipp noch http://cjwdev.com/Software/MSAGUI/Info.html da. Lebensretter bei MSAs 
Perfekt, vielen Dank!
