Remote SQL Server Backups erklärt

Remote SQL Backups sind kompliziert. Wir werden erklären, warum und zeigen alle verfügbaren Optionen, um die Backups trotzdem zu machen.

Remote SQL Server ist ein Server, auf dem Sie wie in einer Shared Hosting-Umgebung nur eingeschränkten Zugriff auf das Dateisystem des Servers haben.
Local SQL Server ist ein Server, auf dem Sie vollen Zugriff auf das Dateisystem haben, wie ein lokaler Server, auf den Sie physisch zugreifen können, oder ein dedizierter / virtueller Server, über den Sie die volle Kontrolle haben.

Was ist das Problem mit SQL Server-Remotesicherungen?

Das Hauptproblem mit Remote-SQL-Servern ist, dass Sie SQL-Skripte ausführen können, einschließlich BACKUP-Datenbank-Befehl, aber den Zugriff auf die resultierende *.bak-Datei ist problematisch. Der *.die BAK-Datei befindet sich irgendwo auf dem lokalen Laufwerk dieses SQL Servers. Wenn Sie keinen Zugriff auf diesen Speicherort haben, können Sie die Sicherungsdatei nicht zur weiteren Verarbeitung wie Komprimierung, Verschlüsselung, Speicherung usw. kopieren. (weitere Details dazu, was SQL Backup Automation bedeutet) Dann sind Ihre Optionen auf das Erstellen einer Skriptdatei beschränkt.

BAK (*.bak) Datei vs Skript (*.sql) Datei für SQL Server-Sicherungen

BAK-Dateien sind die Sicherungen, die mit dem Standardbefehl BACKUP DATABASE von Microsoft (oder über SSMS oder SQLBackupAndFTP) erstellt wurden. Sie bekommen normalerweise *.bak-Erweiterung. Wenn Sie eine Option zum Erstellen haben *.bak-Dateien – Bevorzugen Sie es immer den Alternativen, da Sie damit nicht nur vollständige, sondern auch differenzielle Backups und Transaktionsprotokollsicherungen speichern können. Und das Format ist die häufigste und nicht proprietär für jede 3rd-Party. Sie können wiederherstellen von (*.bak) Datei mit Standard-RESTORE-Datenbank-Befehl und viele 3rd-Party-Tools.

Skript (*.sql) Datei ist im Grunde eine Reihe von SQL-Befehlen, die die Datenbankobjekte neu erstellen und die Daten in die Tabellen einfügen. Der Vorteil der Verwendung einer Skriptdatei besteht darin, dass Sie in den meisten Hosting-Umgebungen Skriptdateien hochladen und über ein Hosting-Verwaltungssteuerungsfeld ausführen können. Anschließend können Sie eine Datenbank wiederherstellen, ohne dass der Hoster etwas installieren oder konfigurieren muss.

Jedoch Skript (*.sql) Methode hat die folgenden Einschränkungen:

  1. Das Generieren eines Skripts dauert viel länger als das Erstellen eines Standard-BAK-SQL Server-Backups
  2. Ein solches Skript benötigt mehr Speicherplatz, da es sich um eine textuelle (nicht binäre) Darstellung Ihrer Datenbank handelt, obwohl es viel komprimierbarer ist als ein binäres Backup.
  3. Das Wiederherstellen einer Datenbank aus einem Skript dauert länger als bei einer regulären Sicherung
  4. Im Gegensatz zu Standardsicherungen enthalten Skripte keine Transaktionsloginformationen, sodass Sie keine Point-in-Time-Wiederherstellung anwenden können
  5. Beim Scripting werden Abhängigkeiten nicht immer berücksichtigt, sodass bei der Datenbankerstellung Probleme auftreten können

Lokale SQL Server-Sicherungen

Lokale SQL Das Server-Backup ist gut dokumentiert und wir werden hier nicht auf die Details eingehen. Grundsätzlich führen Sie BACKUP-Datenbank-Befehl, verwenden SQL Server Management Studio oder 3rd-Party-Tools. Dadurch entsteht ein *.bak-Datei auf dem lokalen Dateisystem des Servers. Dann komprimieren Sie die Datei normalerweise, verschlüsseln sie, laden sie auf ein Netzlaufwerk, FTP oder eine Cloud hoch usw. Sie können Ihre benutzerdefinierten Skripte erstellen, um dies zu tun, oder alles in einem Produkt wie SQLBackupAndFTP abrufen.

SQL Server-Remotesicherungen auf einem *.bak-Datei auf Netzwerkfreigabe

Wenn sich Ihr Remote-SQL-Server im selben Netzwerk wie Sie und beide SQL Server befindet und Sie Zugriff auf dieselbe Netzwerkfreigabe haben (z. B. \\ servername \ path), können Sie auf dem SQL Server ein Backup an diesem Speicherort mit dem folgenden Befehl erstellen:

DATENBANK dbname AUF FESTPLATTE SICHERN = N’\\servername\Pfad\dbname.BAK‘

Und von Ihrem eigenen Computer aus können Sie auf denselben Speicherort zugreifen.bak-Datei und tun, was Sie damit wollen.

Sie können Ihre eigenen Skripte schreiben, um es zu automatisieren oder sichern Sie Ihr Netzwerk SQL Server mit SQLBackupAndFTP.

Der Vorteil von Backups im UNC-Pfad besteht darin, dass Sie die Sicherung im selben Pfad erhalten *.bak-Format. Der Nachteil hängt im Wesentlichen mit der Notwendigkeit zusammen, Zugriffsrechte korrekt zu konfigurieren. Besuchen Sie den Link oben für Details zu Berechtigungen.

SQL Server-Remotesicherungen in einem Skript (*.sql) Datei

Ein generiertes SQL Server-Skript (*.sql) Backup-Datei enthält die Informationen, die notwendig sind, um die Datenbank auf einem Remote-Computer neu zu erstellen. Das Skript enthält Befehle zum erneuten Erstellen des Datenbankschemas (Tabellen, Ansichten, gespeicherte Prozeduren, Trigger, Volltextkataloge, Rollen, Regeln usw.) und der Daten. Sie haben mehrere Möglichkeiten, ein Skript zu generieren (*.sql) Backup-Datei

Scripting-Datenbank mit SqlBackupAndFtp

Dies ist bei weitem die einfachste Methode zum Sichern Ihrer Remote-Datenbanken. Wählen Sie einfach „Remote SQL Server“ als Servertyp Legen Sie die Anmeldeinformationen fest:

Konfigurieren Sie dann Komprimierung, Verschlüsselung, wohin Backups gesendet werden sollen und wohin E-Mail-Benachrichtigungen gesendet werden sollen. Weitere Informationen finden Sie unter Sichern einer entfernten SQL Server-Datenbank mit SQLBackupAndFTP

Skriptdatenbank mit SQL Server Management Studio (SSMS)

Beachten Sie, dass dies als Ad-hoc-„Sicherung“ funktioniert, Sie jedoch keine SSMS-Skripterstellung planen können. So generieren Sie ein Datenbankskript mit SSMS:

  1. Öffnen Sie Ihr SSMS
  2. Verbinden Sie sich mit Ihrem entfernten SQL Server
  3. Klicken Sie mit der rechten Maustaste auf die Datenbank, die Sie sichern möchten, und wählen Sie Aufgaben -> Skripte generieren. Dies öffnet einen Assistenten
  4. Klicken Sie auf Weiter auf dem Einführungsbildschirm
  5. Lassen Sie die Standardeinstellung „Gesamte Datenbank und Datenbankobjekte skripten“ ausgewählt und klicken Sie auf Weiter
  6. Klicken Sie auf die Schaltfläche Erweitert und ändern Sie „Datentypen in Skript“ von „Nur Schema“ in „Schema und Daten“. Klicken Sie auf OK
  7. Wählen Sie die Option „In einem neuen Abfragefenster speichern“ und klicken Sie auf Weiter, Weiter und Fertig stellen

Kopieren Sie das Skript in Ihre lokale Datei und speichern oder führen Sie es bei Bedarf aus.

Andere Optionen für die Remote-SQL Server-Sicherung

Wenn die Verwendung von Word „Backup“ in Bezug auf Scripting eine ziemliche Strecke war, sind die in diesem Abschnitt diskutierten Optionen noch weiter von dem entfernt, was als „Datenbanksicherung“ angesehen wird. Trotzdem können Sie eine Kopie Ihrer Daten erhalten, deshalb werden wir auch diese Optionen überprüfen

Verschieben von Daten mit dem SQL Server-Import- und Exportassistenten in SSMS

Sie können den SQL Server-Import- und Exportassistenten verwenden, um die Daten vom Remote-SQL-Server auf einen lokalen SQL-Server zu kopieren. Beachten Sie, dass NICHT alle Datenbankobjekte kopiert werden, sondern nur die Daten. Wir können uns nicht vorstellen, es als Hauptsicherungsmethode zu verwenden. Wie auch immer, hier die Anleitung:

  1. Öffnen Sie Ihr SSMS
  2. Stellen Sie eine Verbindung zu Ihrem lokalen SQL Server her
  3. Klicken Sie mit der rechten Maustaste auf die Datenbank, in der die Sicherungen wiederhergestellt werden sollen, und wählen Sie Aufgaben -> Daten importieren. Dies öffnet einen Assistenten
  4. Wählen Sie „SQL Server Native Client“ als Datenquelle und Ihren Remote SQL Server als Servernamen.
  5. Wählen Sie die Datenbank aus, aus der die Daten kopiert werden sollen. Nächsten.
  6. Wählen Sie „SQL Server Native Client“ als Datenquelle und Ihren lokalen SQL Server als Servernamen.
  7. Wählen Sie die Datenbank aus, in die die Daten kopiert werden sollen. Nächsten.
  8. Wählen Sie die zu kopierenden Tabellen aus. Weiter, Weiter, Fertig

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.