7
MS SQL Backup durch "normalen" Anwender
Einen schönen guten Morgen,
Thema MS SQL-Backup;
Wie regelt ihr die Situation, wenn ein "normaler" Anwender ein Backup der SQL Instanz durchführen soll/muss ohne diesen Adminrechte o.ä. zu gewähren - Und das am besten per "Knopfdruck"?
Bin für jeden Vorschlag dankbar.
VG
Sebi
Thema MS SQL-Backup;
Wie regelt ihr die Situation, wenn ein "normaler" Anwender ein Backup der SQL Instanz durchführen soll/muss ohne diesen Adminrechte o.ä. zu gewähren - Und das am besten per "Knopfdruck"?
Bin für jeden Vorschlag dankbar.
VG
Sebi
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3780197396
Url: https://administrator.de/contentid/3780197396
Ausgedruckt am: 25.11.2024 um 16:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
ich lasse den "normalen" Anwender kein Backup machen sondern automatisiere das.
Der normale Anwender kann auch mal was vergessen.
ich lasse den "normalen" Anwender kein Backup machen sondern automatisiere das.
Der normale Anwender kann auch mal was vergessen.
2
Ja, bin ich voll bei Dir.
Das Backup soll aber gezielt vor großen Programmänderungen z.B. importen von Kundendatensätzen etc. durchgeführt werden.
Das automatisierte Backup läuft sowieso.
Das Backup soll aber gezielt vor großen Programmänderungen z.B. importen von Kundendatensätzen etc. durchgeführt werden.
Das automatisierte Backup läuft sowieso.
Erstelle ein Skript.
Dann lass dieses Skript von einem Task starten und gib dem Nutzer eine Möglichkeit, diesen Task zu starten.
Ich habe das Prinzip in diesem Artikel genau beschrieben: https://www.experts-exchange.com/articles/33548/How-to-empower-restricte ...
Dann lass dieses Skript von einem Task starten und gib dem Nutzer eine Möglichkeit, diesen Task zu starten.
Ich habe das Prinzip in diesem Artikel genau beschrieben: https://www.experts-exchange.com/articles/33548/How-to-empower-restricte ...
Moin,
können die User diese Befehle absetzen:
Quelle: https://docs.microsoft.com/de-de/sql/t-sql/statements/backup-transact-sq ...
Falls ja, entweder als SQL-File auf dem Desktop legen oder als via SQLCMD.exe und einem Shortcut auf dem Desktop ablegen
können die User diese Befehle absetzen:
DECLARE @dt as INT
SET @dt = CONCAT(CONVERT(NVARCHAR(8), CURRENT_TIMESTAMP, 112), '_', REPLACE(CONVERT(NVARCHAR(8), CURRENT_TIMESTAMP, 108), ':', ''))
BACKUP DATABASE AdventureWorks2012
TO DISK = CONCAT('X:\SQLServerBackups\AdventureWorks_', @dt, '.bak');
GOQuelle: https://docs.microsoft.com/de-de/sql/t-sql/statements/backup-transact-sq ...
Falls ja, entweder als SQL-File auf dem Desktop legen oder als via SQLCMD.exe und einem Shortcut auf dem Desktop ablegen
Welche SQL Version und welche Edition wird denn verwendet? Die DB liegt auf dem Client oder remote auf einem Server?
Es stellt sich die Frage was der User noch alles darf / dürfen soll. Was ist denn wenn der Import durchgeführt wurde aber dem User gefallen die Daten nicht, macht er dann einen Rollback über die Datensicherung? Ich würde eher das Konzept hinterfragen, warum man vor einem Datenimport eine Datensicherung macht. Technisch wird der Datenimport nicht fehlschlagen, warum nicht einfach eine Prozedur die die Daten importiert und eine Prozedur die die zuletzt importierten Daten wieder rückabwickelt?
Es stellt sich die Frage was der User noch alles darf / dürfen soll. Was ist denn wenn der Import durchgeführt wurde aber dem User gefallen die Daten nicht, macht er dann einen Rollback über die Datensicherung? Ich würde eher das Konzept hinterfragen, warum man vor einem Datenimport eine Datensicherung macht. Technisch wird der Datenimport nicht fehlschlagen, warum nicht einfach eine Prozedur die die Daten importiert und eine Prozedur die die zuletzt importierten Daten wieder rückabwickelt?
1
Warum nicht ein normales Backupprogramm z.B. Veeam?
1
Gehe da mit @ukulele-7
Macht so wenig Sinn. Es sei denn, man übergibt die Katastrophe anschließend an dne SQL Admin? Backup hilft. Die Frage ist nur, wieso man den Import so wenig traut. Wenn die Zuordnung stimmt sollte es kaum Probleme geben. UTF-8, ANSI etc. kann man auch im Vorfeld festlegen.
Ansonsten gibt es ein paar Ansätze. Mit Key-File Passwort verschlüsseln und es so als Admin ausführen. Oder ein PowerShell Script schreiben, weleches als Task jede Minute ausgeführt wird. Stimmen die Bedingungen wird Backup ausfgeführt. Trigger kann hier z.B. ein Pfad/ Datei sein, die von einen anderen Miniprogramm angelegt wird.
Bei sowas muss aber dann zwingend eine Art Lock erzeugt werden - Bsp.: runnig.lck. Sonst würde jede Minute das Backup starten wollen, so lange die Datei da liegt. Bei Problemen müsste das ggf. händisch oder automtisch aufgelöst werden. DateDiff mit lck-Daei. Sind 20 min. vergangen unterstellt man Backup ist durch und Altlasten können gelöscht werden. Anosnsten ist man an der Stelle blind.
Um den aktuellen Status zu erfahren müsste man die SQL System Tabellen anzapfen. Läuft was? Wie lange her? etc. Da wäre man wieder bei einer Procedure o.ä.
Gib zig Wege.
Ganze DB zurück setzen ist auch so eine Sache. Paar GB oder TB? Wenn der Import komplett bekannt ist - einschl. Datenbank Trigger etc - reicht es auch nur die Tabelle neu aufzubauen. Darum haben einige auch in ERP Systemen einen Import-Bereich geschaffen. Man kann die Daten sich ansehen und ggf. hier eingreifen.
Was sind Kundendatensätze? Nur die Stammdaten? Meist reicht es sich die Tabellen zu betrachten, die die Daten halten. Das einzige was ggf. passiert ist, dass die ID und Nummern hochgesetzt werdne und ihr nach dem Löschen und Re-Import Löcher im Nummernkreis habt. Sowas lässt sich aber meist auch einfach richten. Dazu ist es nur zwingend, dass ihr da Konzept der Nummernkreise oder Auto-Increment Werte verstanden habt.
Macht so wenig Sinn. Es sei denn, man übergibt die Katastrophe anschließend an dne SQL Admin? Backup hilft. Die Frage ist nur, wieso man den Import so wenig traut. Wenn die Zuordnung stimmt sollte es kaum Probleme geben. UTF-8, ANSI etc. kann man auch im Vorfeld festlegen.
Ansonsten gibt es ein paar Ansätze. Mit Key-File Passwort verschlüsseln und es so als Admin ausführen. Oder ein PowerShell Script schreiben, weleches als Task jede Minute ausgeführt wird. Stimmen die Bedingungen wird Backup ausfgeführt. Trigger kann hier z.B. ein Pfad/ Datei sein, die von einen anderen Miniprogramm angelegt wird.
Bei sowas muss aber dann zwingend eine Art Lock erzeugt werden - Bsp.: runnig.lck. Sonst würde jede Minute das Backup starten wollen, so lange die Datei da liegt. Bei Problemen müsste das ggf. händisch oder automtisch aufgelöst werden. DateDiff mit lck-Daei. Sind 20 min. vergangen unterstellt man Backup ist durch und Altlasten können gelöscht werden. Anosnsten ist man an der Stelle blind.
Um den aktuellen Status zu erfahren müsste man die SQL System Tabellen anzapfen. Läuft was? Wie lange her? etc. Da wäre man wieder bei einer Procedure o.ä.
Gib zig Wege.
Ganze DB zurück setzen ist auch so eine Sache. Paar GB oder TB? Wenn der Import komplett bekannt ist - einschl. Datenbank Trigger etc - reicht es auch nur die Tabelle neu aufzubauen. Darum haben einige auch in ERP Systemen einen Import-Bereich geschaffen. Man kann die Daten sich ansehen und ggf. hier eingreifen.
Was sind Kundendatensätze? Nur die Stammdaten? Meist reicht es sich die Tabellen zu betrachten, die die Daten halten. Das einzige was ggf. passiert ist, dass die ID und Nummern hochgesetzt werdne und ihr nach dem Löschen und Re-Import Löcher im Nummernkreis habt. Sowas lässt sich aber meist auch einfach richten. Dazu ist es nur zwingend, dass ihr da Konzept der Nummernkreise oder Auto-Increment Werte verstanden habt.
