Freigeben über

Sichern und Wiederherstellen von SQL Server-Datenbanken

Gilt für:SQL Server

In diesem Artikel werden die Vorteile des Sicherns von SQL Server-Datenbanken beschrieben, grundlegende Begriffe für Sicherung und Wiederherstellung beschrieben. Außerdem werden Sicherungs- und Wiederherstellungsstrategien für SQL Server und Sicherheitsaspekte für DIE SQL Server-Sicherung und -Wiederherstellung eingeführt.

In diesem Artikel werden SQL Server-Sicherungen vorgestellt. Die spezifischen Schritte zum Sichern von SQL Server-Datenbanken finden Sie unter Erstellen von Sicherungen.

Die Komponente SQL Server-Sicherung und -Wiederherstellung bietet eine grundlegende Absicherung zum Schutz kritischer Daten, die in Ihren SQL Server-Datenbanken gespeichert sind. Um die Gefahr eines schwerwiegenden Datenverlusts zu minimieren, müssen Sie Ihre Datenbanken regelmäßig sichern, um die Änderungen an Ihren Daten aufzubewahren. Eine gut geplante Sicherungs- und Wiederherstellungsstrategie hilft, Datenbanken vor Datenverlusten zu schützen, die durch eine Vielzahl von Fehlern verursacht werden können. Testen Sie Ihre Strategie, indem Sie einen Sicherungssatz und anschließend Ihre Datenbank wiederherstellen, um sich auf die effektive Reaktion auf einen Notfall vorzubereiten.

Neben dem lokalen Speicher für das Speichern der Sicherung unterstützt SQL Server auch das Sichern und Wiederherstellen aus Azure Blob Storage. Weitere Informationen finden Sie unter SQL Server-Sicherung und -Wiederherstellung mit Microsoft Azure Blob Storage. Für Datenbankdateien, die mit Microsoft Azure Blob Storage gespeichert wurden, bietet SQL Server 2016 (13.x) die Option, Azure-Momentaufnahmen für nahezu sofortige Sicherungen und schnellere Wiederherstellungen zu nutzen. Weitere Informationen finden Sie unter Dateimomentaufnahmesicherungen für Datenbankdateien in Azure. Azure bietet auch eine Sicherungslösung der Unternehmensklasse für SQL Server-Instanzen auf Azure-VMs. Es handelt sich um eine vollständig verwaltete Sicherungslösung, die Always On-Verfügbarkeitsgruppen, Langzeitaufbewahrung Zeitpunktwiederherstellung sowie zentrale Verwaltung und Überwachung unterstützt. Weitere Informationen finden Sie unter "Informationen zur SQL Server-Sicherung auf virtuellen Azure-Computern".

Warum Sichern (back up)?

  • Sie können sich vor schwerwiegendem Datenverlust schützen, indem Sie die SQL Server-Datenbanken sichern, Testwiederherstellungsprozeduren für die Sicherungen ausführen und Kopien der Sicherungen an einem sicheren Ort außerhalb Ihrer Geschäftsräume aufbewahren. Das Sichern ist die einzige Möglichkeit, Ihre Daten zu schützen.

    Mithilfe gültiger Datenbanksicherungen können Sie die Daten nach vielen Fehlern wiederherstellen, z. B.:

    • Medienfehler
    • Benutzerfehler (z. B. versehentliches Löschen einer Tabelle)
    • Hardwarefehler (z. B. ein beschädigter Datenträger oder der endgültige Verlust eines Servers)
    • Naturkatastrophen, Mit der SQL Server-Sicherung für Azure Blob Storage können Sie eine externe Sicherung in einer anderen Region als an Ihrem lokalen Standort erstellen. Diese wird dann verwendet, wenn der lokale Standort durch eine Naturkatastrophe in Mitleidenschaft gezogen wird.

  • Darüber hinaus sind Sicherungen einer Datenbank hilfreich für Routineverwaltungsaufgaben, wie z. B. Kopieren einer Datenbank zwischen Servern, Einrichten von Always On-Verfügbarkeitsgruppen oder Datenbankspiegelung und Archivierung.

Glossarbegriffe für die Sicherung

Sichern [Verb]
Der Vorgang zum Erstellen einer Sicherung [Substantiv] durch Kopieren von Datensätzen aus einer SQL Server-Datenbank oder Protokolldatensätzen aus dem Transaktionsprotokoll.

Sicherung [Substantiv]
Eine Kopie von Daten, die Sie zum Wiederherstellen und Wiederherstellen der Daten nach einem Fehler verwenden können. Sicherungen einer Datenbank können auch verwendet werden, um eine Kopie der Datenbank an einem neuen Speicherort wiederherzustellen.

Sicherungsgerät
Ein Datenträger oder Bandgerät, auf den bzw. das SQL Server-Sicherungen geschrieben werden und von dem sie wiederhergestellt werden können. SQL Server-Sicherungen können auch in einen Azure Blob Storage geschrieben werden. Das URL-Format wird verwendet, um das Ziel und den Namen der Sicherungsdatei anzugeben. Weitere Informationen finden Sie unter SQL Server-Sicherung und -Wiederherstellung mit Microsoft Azure Blob Storage.

Sicherungsmedien
Bänder oder Datenträgerdateien, auf die Sicherungen geschrieben wurden

Datensicherung
Eine Sicherung von Daten einer vollständigen Datenbank (Datenbanksicherung), einer partiellen Datenbank (partielle Sicherung) oder einem Satz von Datendateien oder Dateigruppen (Dateisicherung).

Datenbanksicherung
Eine Sicherung einer Datenbank. Vollständige Datenbanksicherungen stellen die gesamte Datenbank zum Zeitpunkt dar, an dem die Sicherung abgeschlossen wurde. Differenzielle Datenbanksicherungen enthalten nur Änderungen, die seit der letzten vollständigen Datenbanksicherung an der Datenbank vorgenommen wurden.

Differenzielle Sicherung
Eine Datensicherung, die auf der letzten vollständigen Sicherung einer vollständigen oder partiellen Datenbank oder einem Satz von Datendateien oder Dateigruppen (differenzielle Basis) basiert und nur die Daten enthält, die sich gegenüber der Basis geändert haben.

Vollständige Sicherung
Eine Datensicherung, die alle Daten in einer bestimmten Datenbank oder einem Satz von Dateigruppen oder Dateien enthält. Außerdem muss die Sicherung genügend Protokolle enthalten, um die Wiederherstellung dieser Daten zu ermöglichen.

Protokollsicherung
Eine Sicherung von Transaktionsprotokollen, die alle Protokolldatensätze enthält, die nicht in einer vorherigen Protokollsicherung gesichert wurden (vollständiges Wiederherstellungsmodell).

recover
Wiederherstellen eines stabilen und konsistenten Datenbankzustands.

recovery
Eine Phase beim Starten der Datenbank oder einer Wiederherstellung, in der ein transaktionskonsistenter Zustand der Datenbank hergestellt wird.

Wiederherstellungsmodell
Eine Datenbankeigenschaft, die die Pflege der Transaktionsprotokolle auf einer Datenbank steuert. Es gibt drei Wiederherstellungsmodelle: einfache, vollständige und massenprotokolliert. Das Wiederherstellungsmodell einer Datenbank bestimmt die Sicherungs- und Wiederherstellungsanforderungen.

restore
Ein mehrstufiger Prozess, der alle Daten- und Protokollseiten aus einer angegebenen SQL Server-Sicherung in eine angegebene Datenbank kopiert und dann alle Transaktionen weiterleitt, die in der Sicherung protokolliert werden, indem protokollierte Änderungen angewendet werden, um die Daten rechtzeitig nach vorne zu bringen.

Sicherungs- und Wiederherstellungsstrategien

Das Sichern und Wiederherstellen von Daten muss jedoch auf die entsprechende Umgebung und auf die verfügbaren Ressourcen abgestimmt werden. Daher erfordert eine zuverlässige Verwendung der Sicherung und Wiederherstellung für die Wiederherstellung eine Sicherungs- und Wiederherstellungsstrategie. Eine gut durchdachte Sicherungs- und Wiederherstellungsstrategie gleicht die Geschäftsanforderungen für maximale Datenverfügbarkeit und minimale Datenverluste ab und berücksichtigt dabei die Kosten für die Wartung und Speicherung von Sicherungen.

Eine Sicherungs- und Wiederherstellungsstrategie enthält einen Sicherungsteil und einen Wiederherstellungsteil. Der Sicherungsteil der Strategie definiert den Typ und die Häufigkeit von Sicherungen, die Art und Geschwindigkeit der benötigten Hardware, wie Sicherungen getestet werden sollen und wo und wie Sicherungsmedien gespeichert werden sollen (einschließlich Sicherheitsaspekten). Der Wiederherstellungsteil der Strategie definiert, wer für die Durchführung von Wiederherstellungen verantwortlich ist, wie Wiederherstellungsvorgänge durchgeführt werden sollten, um Ihre Ziele für die Datenbankverfügbarkeit zu erfüllen und Datenverluste zu minimieren und wie Wiederherstellungen getestet werden.

Das Entwerfen einer effektiven Sicherungs- und Wiederherstellungsstrategie erfordert sorgfältiges Planen, Implementieren und Testen. Tests sind erforderlich: Sie verfügen nicht über eine Sicherungsstrategie, bis Sie Sicherungen in allen Kombinationen erfolgreich wiederhergestellt haben, die in Ihrer Wiederherstellungsstrategie enthalten sind und die wiederhergestellte Datenbank auf physische Konsistenz getestet haben. Sie müssen eine Vielzahl von Faktoren berücksichtigen: Dazu gehören:

  • Die Ziele Ihrer Organisation in Bezug auf Ihre Produktionsdatenbanken, insbesondere die Anforderungen an die Verfügbarkeit und den Schutz von Daten vor Verlust oder Schaden.

  • Die Merkmale der einzelnen Datenbanken, wie etwa Größe, Verwendungsmuster, Art des Inhalts und Anforderungen hinsichtlich der Daten.

  • Einschränkungen für Ressourcen wie Hardware, Personal, Speicherplatz zum Speichern von Sicherungsmedien, physische Sicherheit der gespeicherten Medien usw.

Empfehlungen zu bewährten Methoden

Die Konten, die Sicherungs- oder Wiederherstellungsvorgänge ausführen, sollten nicht mehr Berechtigungen als erforderlich erhalten. Überprüfen Sie Sicherung und Wiederherstellung auf entsprechende Details zu Berechtigungen. Es empfiehlt sich, Sicherungen zu verschlüsseln und ggf. zu komprimieren.

Um die Sicherheit zu gewährleisten, sollten die Erweiterungen der Sicherungsdateien ordnungsgemäß den Konventionen entsprechen:

  • Datenbanksicherungsdateien sollten die Erweiterung .BAK haben
  • Protokollsicherungsdateien sollten die Erweiterung .TRN haben.

Verwenden von getrennten Speichern

Wichtig

Speichern Sie Ihre Datenbanksicherungen immer an einem anderen physischen Speicherort oder auf einem anderen Gerät als die Datenbankdateien. Funktioniert das physische Laufwerk, auf dem die Datenbanken gespeichert sind, nicht richtig oder stürzt ab, kann eine Wiederherstellung nur ausgeführt werden, wenn auf das separate Laufwerk oder Remotegerät, auf dem die Sicherungen gespeichert wurden, auch zugegriffen werden kann. Denken Sie daran, dass Sie auf einem physischen Datenträger mehrere logische Volumes oder Partitionen erstellen können. Überprüfen Sie das Layout der Datenträgerpartition und der logischen Volumes sorgfältig, bevor Sie einen Speicherort für die Sicherungen auswählen.

Auswählen eines geeigneten Wiederherstellungsmodells

Sicherungs- und Wiederherstellungsvorgänge werden im Kontext eines Wiederherstellungsmodells durchgeführt. Bei einem Wiederherstellungsmodell handelt es sich um eine Datenbankeigenschaft, mit der die Verwaltung des Transaktionsprotokolls gesteuert wird. Daher bestimmt das Wiederherstellungsmodell einer Datenbank, welche Arten von Sicherungen und Wiederherstellungsszenarien für die Datenbank unterstützt werden und wie groß die Transaktionsprotokollsicherungen sein würden. Meistens wird für Datenbanken entweder das einfache Wiederherstellungsmodell oder das vollständige Wiederherstellungsmodell verwendet. Sie können das vollständige Wiederherstellungsmodell erweitern, indem Sie vor Massenvorgängen zum Massenwiederherstellungsmodell wechseln. Eine Einführung in diese Wiederherstellungsmodelle und ihre Auswirkungen auf die Verwaltung von Transaktionsprotokollen finden Sie im Transaktionsprotokoll.

Die Wahl des für Ihre Datenbank am besten geeigneten Wiederherstellungsmodells hängt von Ihren Geschäftsanforderungen ab. Verwenden Sie das einfache Wiederherstellungsmodell, wenn Sie die Verwaltung des Transaktionsprotokolls vermeiden und den Sicherungs- und Wiederherstellungsprozess so einfach wie möglich gestalten möchten. Verwenden Sie das vollständige Wiederherstellungsmodell, um die Belastung durch Arbeitsverlust auf Kosten des Verwaltungsaufwands zu minimieren. Verwenden Sie das massenprotokollierte Wiederherstellungsmodell, um die Auswirkungen auf die Protokollgröße bei massenprotokollierten Vorgängen zu minimieren und gleichzeitig die Wiederherstellbarkeit dieser Vorgänge zu ermöglichen. Informationen zu den Auswirkungen von Wiederherstellungsmodellen auf Sicherung und Wiederherstellung finden Sie in der Übersicht über die Sicherung.

Entwerfen Ihrer Sicherungsstrategie

Nachdem Sie ein Wiederherstellungsmodell ausgewählt haben, das Ihre Geschäftsanforderungen für eine bestimmte Datenbank erfüllt, müssen Sie eine entsprechende Sicherungsstrategie planen und implementieren. Die optimale Sicherungsstrategie hängt von verschiedenen Faktoren ab, wobei den folgenden eine besondere Bedeutung zukommt:

  • Wie viele Stunden täglich müssen Anwendungen auf die Datenbank zugreifen können?

    Wenn ein vorhersagbarer Zeitraum außerhalb des Spitzenzeitpunkts vorhanden ist, empfehlen wir, vollständige Datenbanksicherungen für diesen Zeitraum zu planen.

  • Wie häufig werden Änderungen und Updates im Allgemeinen vorgenommen?

    Berücksichtigen Sie bei häufigen Änderungen Folgendes:

    • Bei Verwendung des einfachen Wiederherstellungsmodells sollten Sie zwischen vollständigen Datenbanksicherungen differenzielle Sicherungen planen. Bei einer differenziellen Sicherung werden nur die Änderungen seit der letzten vollständigen Datenbanksicherung erfasst.

    • Bei Verwendung des vollständigen Wiederherstellungsmodells sollten Sie häufige Protokollsicherungen planen. Wenn Sie zwischen vollständigen Sicherungen differenzielle Sicherungen planen, kann dies die Wiederherstellungszeit verkürzen, da Sie nach dem Wiederherstellen der Daten nur eine geringe Anzahl von Protokollsicherungen wiederherstellen müssen.

  • Werden Änderungen eher in einem kleinen oder in einem großen Bereich der Datenbank vorgenommen?

    Bei einer großen Datenbank, in der sich die Änderungen auf einen Teil der Dateien oder Dateigruppen konzentrieren, können Teilsicherungen und/oder vollständige Dateisicherungen sinnvoll sein. Weitere Informationen finden Sie unter Partielle Sicherungen (SQL Server) und vollständige Dateisicherungen (SQL Server).

  • Wie viel Speicherplatz nimmt eine vollständige Datenbanksicherung auf dem Datenträger in Anspruch?

  • Wie weit in die Vergangenheit sollen Sicherungen zurückreichen?

    Vergewissern Sie sich, dass Ihr Sicherungszeitplan den Anwendungs- und Geschäftsanforderungen entspricht. Je älter die Sicherungen sind, desto größer ist das Risiko für einen Datenverlust – außer Sie besitzen die Möglichkeit, alle Daten bis zum Zeitpunkt des Fehlers neu zu generieren. Bevor Sie alte Sicherungen aufgrund von Speicherressourceneinschränkungen verwerfen möchten, sollten Sie berücksichtigen, ob die Wiederherstellbarkeit in der Vergangenheit erforderlich ist.

Schätzen der Größe einer vollständigen Datenbanksicherung

Vor dem Implementieren einer Sicherungs- und Wiederherstellungsstrategie sollten Sie schätzen, wie viel Speicherplatz eine vollständige Datenbanksicherung auf dem Datenträger belegen wird. Beim Sicherungsvorgang werden die in der Datenbank enthaltenen Daten in die Sicherungsdatei kopiert. Die Sicherung enthält nur die in der Datenbank vorhandenen Daten, nicht etwa ungenutzten Speicherplatz. Daher ist die Sicherung normalerweise kleiner als die Datenbank selbst. Sie können die Größe einer vollständigen Datenbanksicherung mithilfe der sp_spaceused gespeicherten Systemprozedur schätzen. Weitere Informationen finden Sie unter sp_spaceused (Transact-SQL).

Planen von Sicherungen

Das Ausführen eines Sicherungsvorgangs hat minimale Auswirkungen auf Transaktionen, die ausgeführt werden; Daher können Sie Sicherungsvorgänge während regulärer Vorgänge ausführen. Sie können eine SQL Server-Sicherung mit minimalen Auswirkungen auf die produktive Arbeitslast ausführen.

Informationen zu Parallelitätseinschränkungen während der Sicherung finden Sie in der Übersicht über die Sicherung (SQL Server).

Nachdem Sie entschieden haben, welche Arten von Sicherungen Sie benötigen und wie oft Sie diese jeweils durchführen müssen, empfiehlt es sich, im Rahmen eines Datenbankwartungsplans für die Datenbank die regelmäßige Durchführung dieser Sicherungen zu planen. Informationen zu Wartungsplänen für Datenbank- und Protokollsicherungen und zu deren Erstellung finden Sie unter Use the Maintenance Plan Wizard.

Testen Ihrer Sicherungen

Sie haben erst eine Wiederherstellungsstrategie, wenn Sie Ihre Sicherungen testen. Es ist sehr wichtig, Ihre Sicherungsstrategie für jede Ihrer Datenbanken gründlich zu testen, indem Sie eine Kopie der Datenbank in einem Testsystem wiederherstellen. Sie müssen die Wiederherstellung jedes Sicherungstyps testen, den Sie zu verwenden beabsichtigen. Außerdem wird empfohlen, dass Sie nach der Wiederherstellung der Sicherung Datenbankkonsistenzprüfungen über DBCC CHECKDB der Datenbank durchführen, um zu überprüfen, ob die Sicherungsmedien nicht beschädigt wurden.

Überprüfen der Medienstabilität und -konsistenz

Verwenden Sie die Überprüfungsoptionen, die von den Sicherungshilfsprogrammen bereitgestellt werden (BACKUP T-SQL-Befehl, SQL Server-Wartungspläne, Ihre Sicherungssoftware oder -lösung usw.). Ein Beispiel finden Sie unter RESTORE-Anweisungen – VERIFYONLY.

Verwenden Sie erweiterte Features, BACKUP CHECKSUM um Probleme mit dem Sicherungsmedium selbst zu erkennen. Weitere Informationen finden Sie unter Mögliche Medienfehler während der Sicherung und Wiederherstellung (SQL Server)

Dokumentsicherung/Wiederherstellungsstrategie

Es empfiehlt sich, Sicherungs- und Wiederherstellungsprozeduren zu dokumentieren und eine Kopie der Dokumentation im Ausführungsbuch aufzubewahren. Es wird auch empfohlen, für jede Datenbank ein Betriebshandbuch zu führen. In diesem Betriebshandbuch sollten der Aufbewahrungsort der Sicherungen, ggf. die Namen der Sicherungsmedien sowie Angaben zum Zeitaufwand für die Wiederherstellung der Testsicherungen vermerkt sein.

Sicherheitsrisiko beim Wiederherstellen von Sicherungen aus nicht vertrauenswürdigen Quellen

In diesem Abschnitt wird das Sicherheitsrisiko beschrieben, das mit dem Wiederherstellen von Sicherungen aus nicht vertrauenswürdigen Quellen in einer beliebigen SQL Server-Umgebung verbunden ist, einschließlich lokaler, von Azure SQL verwalteter Instanz, SQL Server auf virtuellen Azure-Computern (VMs) und jeder anderen Umgebung.

Warum ist das wichtig?

Das Wiederherstellen von SQL-Sicherungsdateien (.bak) führt zu einem potenziellen Risiko, wenn die Sicherung von einer nicht vertrauenswürdigen Quelle stammt. Das Sicherheitsrisiko wird weiter verschärft, wenn eine SQL Server-Umgebung mehrere Instanzen aufweist, da sie den Bedrohungsbereich verstärkt. Während Sicherungen, die innerhalb einer vertrauenswürdigen Grenze verbleiben, kein Sicherheitsproblem darstellen, kann das Wiederherstellen einer schädlichen Sicherung die Sicherheit der gesamten Umgebung beeinträchtigen.

Eine schädliche .bak Datei kann:

  • Übernehmen Sie die gesamte SQL Server-Instanz.
  • Eskalieren Sie Berechtigungen, und erhalten Sie nicht autorisierten Zugriff auf den zugrunde liegenden Host oder virtuellen Computer.

Dieser Angriff tritt auf, bevor alle Überprüfung von Skripten oder Sicherheitsprüfungen ausgeführt werden können, was diesen Angriff extrem gefährlich macht. Das Wiederherstellen einer nicht vertrauenswürdigen Sicherung entspricht dem Ausführen nicht vertrauenswürdiger Anwendungen auf einem kritischen Server oder virtuellen Computer und der Einführung beliebiger Codeausführung in Ihre Umgebung.

Bewährte Methoden

Befolgen Sie die folgenden bewährten Methoden zur Sicherung der Sicherheit, um die Bedrohung für Ihre SQL Server-Umgebungen zu verringern:

  • Behandeln Sie das Wiederherstellen von Sicherungen als hochrisikobehafteten Vorgang.
  • Reduzieren Sie den Bereich des Bedrohungsdiensts mithilfe von isolierten Instanzen.
  • Nur vertrauenswürdige Sicherungen zulassen: Sicherungen von unbekannten oder externen Quellen niemals wiederherstellen.
  • Nur Sicherungen zulassen, die innerhalb eines vertrauenswürdigen Bereichs geblieben sind: Stellen Sie sicher, dass Sicherungen aus einem vertrauenswürdigen Bereich stammen.
  • Umgehen Sie keine Sicherheitskontrollen aus Bequemlichkeit.
  • Aktivieren Sie die Überwachung auf Serverebene , um Sicherungs- und Wiederherstellungsereignisse zu erfassen und Überwachungshinterziehung zu verringern.

Überwachen des Fortschritts mit XEvent

Sicherungs- und Wiederherstellungsvorgänge können aufgrund der Größe der Datenbank und der Komplexität der notwendigen Vorgänge viel Zeit in Anspruch nehmen. Wenn Probleme mit beiden Vorgängen auftreten, können Sie das backup_restore_progress_trace erweiterte Ereignis verwenden, um den Status live zu überwachen. Weitere Informationen zu erweiterten Ereignissen finden Sie in der Übersicht über erweiterte Ereignisse.

Warnung

Die Verwendung des backup_restore_progress_trace erweiterten Ereignisses kann zu einem Leistungsproblem führen und einen erheblichen Speicherplatz belegen. Verwenden Sie dieses Ereignis mit Bedacht über kurze Zeiträume, und testen Sie es sorgfältig, bevor Sie es in einer Produktionsumgebung implementieren.

-- Create the backup_restore_progress_trace extended event session
CREATE EVENT SESSION [BackupRestoreTrace] ON SERVER
ADD EVENT sqlserver.backup_restore_progress_trace
ADD TARGET package0.event_file(SET filename=N'BackupRestoreTrace')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=5 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

-- Start the event session
ALTER EVENT SESSION [BackupRestoreTrace]
ON SERVER
STATE = start;
GO

-- Stop the event session
ALTER EVENT SESSION [BackupRestoreTrace]
ON SERVER
STATE = stop;
GO

Beispielausgabe für erweiterte Ereignisse

Screenshot eines Beispiels zur Sicherung der xevent-Ausgabe. Screenshot eines Beispiels für die Sicherung der xevent-Ausgabe, fortgesetzt.

Weitere Informationen zu Sicherungstasks

Arbeiten mit Sicherungsgeräten und Sicherungsmedien

Erstellen von Sicherungen

Hinweis

Bei teil- oder kopiergeschützten Sicherungen müssen Sie die Transact-SQL BACKUP-Anweisung bzw. option PARTIALCOPY_ONLY verwenden.

Verwenden von SSMS

Verwenden von T-SQL

Wiederherstellen von Datensicherungen

Verwenden von SSMS

Verwenden von T-SQL

Wiederherstellen von Transaktionsprotokollen (vollständiges Wiederherstellungsmodell)

Verwenden von SSMS

Verwenden von T-SQL

Verwandte Inhalte

  • Last updated on