Das kleinstmögliche Backup… mit SQL Server

Täglich versenden wir unsere SQL Server-Backups über das WAN. Wir müssen die Größe dieser Backups minimieren, damit es nicht ewig dauert.

Es macht uns nichts aus, wenn unser Sicherungsvorgang etwas länger dauert. Derzeit müssen wir 30 Gigs komprimiertes Backup über das WAN verschieben, was über 10 Stunden dauert.

Es gibt zwei Möglichkeiten, um kleinere tägliche Backups zu erhalten.

1. Protokollversand, was bedeuten würde, dass wir den DR-Prozess umstrukturieren müssten.
2. Informationen aus der Datenbank entfernen und auf der anderen Seite neu erstellen (nicht gruppierte Indizes löschen, gruppierte Indizes zu 100% packen - auf der anderen Seite neu erstellen)

Beides würde von unserer Seite einiges an Arbeit erfordern. Wir verwenden SQL Server 2008 Pro, alle Sicherungen werden komprimiert.

Gibt es kommerzielle Produkte, die eine ähnliche Sicherungsgröße wie Option (2) bieten?

Gibt es ein umfassendes Skript, mit dem wir (2) erreichen können? (Umgang mit indizierten Sichten, gefilterten Indizes, Fremdschlüsseln usw.)

Erster Gedanke basierend auf Kommentaren ...

Verwenden Sie differenzielle Sicherungen alle 6 Stunden, um die Größe / Zeit der Sicherung + FTP zu verringern. Reduzieren Sie dann Ihre vollständige Sicherung + FTP nur auf Wochenenden. Dies vermeidet die Komplexität des Protokollversands, die einfach zu bewerkstelligen ist, und erhöht die Komplexität von DR nur geringfügig

Ich habe das Gefühl, dass differenzielle Backups übersehen werden ... Ich habe vorgeschlagen, sie vorher zu verwenden:

• Sichern einer kleinen Datenbank in SQL Server 2008 R2 Express Edition
  Verwenden Sie zur Behebung dieses Problems DIFF-Sicherungen

  Aus Sicht der Wiederherstellung möchte ich alles so einfach wie möglich halten und gleichzeitig die Menge verlorener Daten im Falle eines Ausfalls minimieren

• Vor- und Nachteile von SQL Server-Sicherungsstrategien und die entsprechenden Verwendungsszenarien
• Migrieren einer großen Datenbank
  Verwenden von DIFF-Sicherungen, um die Migration von Sicherungs- und Wiederherstellungsservern zu beschleunigen

Edit: Nach jcolebrands Kommentar werde ich versuchen, mehr zu erklären

Eine differenzielle Sicherung nimmt nur Seiten auf, die sich geändert haben. Außerhalb einer Indexpflege (die einen Großteil der Datenbank betreffen kann) ändern sich nur wenige Prozent der Seiten im Laufe eines Tages. Daher ist eine differenzielle Sicherung viel kleiner als eine vollständige Sicherung vor einer Komprimierung.

Wenn Sie eine vollständige Sicherung haben, z. B. wöchentlich, können Sie dann tägliche Differentiale durchführen und diese außerhalb des Standorts versenden. Für eine tägliche vollständige Sicherung mit Differentialen sind weiterhin beide Dateien außerhalb des Standorts erforderlich.

Dies sollte das Problem des schnellen Abrufs von Daten von A nach B, C und D lösen.

Sie müssen wahrscheinlich sowohl das vollständige als auch das neueste Differential wiederherstellen, um die neuesten Daten zu erhalten, aber Sie können dies möglicherweise mit NORECOVERY und einer STANDBY-Datei umgehen (ich habe es seit Jahren nicht mehr mit einer Diff-Wiederherstellung versucht, seit ich das letzte Mal in einem reinen DBA war Job).

Ein zusätzlicher Bonus ist, dass Diff-Backups nicht mit laufenden Log-Backups zusammenhängen, sodass Sie jede Anforderung an Hochverfügbarkeit / DR von der Anforderung "Daten an die Code-Affen senden" trennen können.

Ich sehe einige Probleme, wenn Sie tägliche vollständige Sicherungen nach Richtlinie oder Prüfung haben, aber die diff-Wiederherstellung kann angewendet werden, bevor ein Protokoll wiederhergestellt wird, um die Wiederherstellungszeit zu verkürzen. Im Gegensatz zu Sicherungen interagieren Diff- und Protokollwiederherstellungen.

Hoffe, ich habe die meisten Grundlagen abgedeckt ...

Es gibt kommerzielle Produkte, mit denen Sie Ihre Backups besser komprimieren können als mit der nativen 2008-Komprimierung. Beispiele sind RedGate Backup , Hyperbac , Idera SQL Backup und Litespeed Backup .

Sie bringen die zusätzlichen Kosten für hohe CPU- und Dateitypen mit sich, die mit Tools außerhalb der von MS gelieferten Tools verarbeitet werden müssen. Dies mit Ausnahme der Hyperbac-Komprimierung (jetzt von Redgate erworben), die die transparente Verarbeitung von Dateien ermöglicht und das Erstellen von zip-kompatiblen Dateien ermöglicht (und auch keine Tools von Drittanbietern benötigt).

Es gibt jedoch kein Tool, das Ihnen eine Datei in der Größe anbietet, die Sie durch manuelle Bereinigung erhalten würden. Lesen Sie den Artikel von Brent Ozar: Um Ihre SQL Server-Sicherungen wirklich zu komprimieren, empfiehlt er Ihnen, die gleichen Schritte auszuführen, die Sie zum Zeitpunkt Nr. 1 ausgeführt haben. 2.

Frage 1: Gibt es ein kommerzielles Sicherungsprodukt, das eine ähnliche Sicherungsgröße bietet wie das Entfernen nicht notwendiger Daten wie Indizes aus der Datenbank?

Nein. Es gibt viele Sicherungskomprimierungsprodukte (Quest LiteSpeed, Red Gate SQL-Sicherung, Idera SQLSafe, Hyperbac usw.), aber alle funktionieren, indem nur die Ausgabe des regulären Sicherungsprozesses von SQL Server komprimiert wird. Einige von ihnen tun dies auf knifflige Weise - HyperBac und LiteSpeeds Engine-Option sind Dateisystemfiltertreiber, was bedeutet, dass sie die Ausgabe auf dem Weg zur Festplatte abfangen - aber das Endergebnis all dieser Produkte ist nur eine komprimierte Sicherungsausgabe.

Frage 2. Gibt es ein umfassendes Skript, um all diese zusätzlichen Daten zu sichern?

Wenn Sie im Laufe der Zeit mehr Verlauf in der Datenbank haben (4, 5, 8, 10 Jahre), möchten Sie nicht alle Indexdaten auslesen und auf der anderen Seite des WAN neu erstellen. Stattdessen möchten Sie nur die geänderten Daten übertragen und hier kommt der Protokollversand ins Spiel.

Das solltest du nicht tun.

Aber wenn Sie dies wirklich tun möchten (und nein, ich werde Ihnen nicht helfen), können Sie dies mit Dateigruppensicherungen tun. Richten Sie Ihre Datenbankdateigruppen wie folgt ein:

• Primäre Dateigruppe (erforderlich, aber leer lassen)
• ClusteredIndex-Dateigruppe (geben Sie Ihre Clustered-Indizes hier ein)
• ExtraneousCrap Filegroup (alles andere hier einfügen)

Beginnen Sie mit komprimierten Dateigruppensicherungen der ersten beiden und kopieren Sie die kleineren auf Ihren DR-Server. Sie können die Sicherungs- und Wiederherstellungsfunktion von SQL Server 2008 für Dateigruppen verwenden, um nur die primären und ClusteredIndex-Dateigruppen wiederherzustellen, und diese stehen dann sofort zur Abfrage zur Verfügung. Sie werden nicht wirklich funktionsfähig sein, bis Sie die ExtraneousCrap-Dateigruppe online haben, aber es gibt auch einen bösen Trick dafür - im MVP Deep Dives-Buch gibt es ein Kapitel zum Bearbeiten der Systemtabellen, um die ExtraneousCrap-Dateigruppe und alles zu erstellen der zugehörigen Indizes verschwinden. Dieser Trick ist gefährlich, völlig ohne Unterstützung und eine verdammt schlechte Idee - aber hey, Sie haben danach gefragt.

Ich empfehle, auf etwas wie Protokollversand umzusteigen. Wenn Sie die Wahl haben, innerhalb eines kürzeren Zeitfensters 30 Gigs über 24 Stunden oder am Ende des Tages zu senden, ist die Netzwerkgeschwindigkeit für Sie von geringerer Bedeutung.

Ihre Entwickler im langsamen Netzwerk können auch Dateien bequemer Größe über FTP oder einen anderen von Ihnen verwendeten Prozess herunterladen. Sie könnten auch Jobs einrichten, die den ganzen Tag heruntergeladen werden.

Zusätzlich zur SQL Server-Komprimierung können Sie ein Drittanbieter-Tool implementieren, das eine höhere Komprimierung aufweist, wie z. B. litespeed oder redgate sqlbackup.

Auf der Netzwerkseite können Sie außerdem Netzwerkgeräte installieren, mit denen Sie den Durchsatz zum DR-Standort optimieren können. In der Vergangenheit habe ich Riverbed Appliance erfolgreich eingesetzt, um eine 90-GB-Sicherung von FL nach VA in weniger als 3 Stunden zu erhalten.

Eine andere Möglichkeit wäre, bestimmte Dateigruppen mit Ausnahme der Indizes usw. zu sichern. Sie sind jedoch weiterhin mit Clustered-Indizes konfrontiert. Abhängig von Ihrer Datenbankstruktur können Sie mehr Kosten / Aufwand erzielen, als von diesem Ansatz zu profitieren.

Vielen Dank

Wenn Sie das Geld dafür haben und Ihre Architektur es zulässt, schauen Sie sich etwas wie Riverbed-Technologien an (http://www.riverbed.com/us/). Eine Appliance wie diese in Verbindung mit einem Replikations- oder Protokollversandszenario ist möglicherweise die beste Wahl.

Wenn nicht, dann ein paar Fragen. Wenn Sie nur alle paar Monate eine Aktualisierung durchführen müssen, warum dann die Sorge um die Bandbreite? Das einzige Mal, dass Sie sich Gedanken über die Übertragung machen müssen, ist, dass Sie das vollständige Backup dort abrufen, um eine lokale Wiederherstellung durchzuführen, oder irre ich mich, wenn Sie dies einrichten?

Eine andere Möglichkeit besteht darin, sich nicht darum zu sorgen, dass alle Daten auf sie zugreifen, sondern eine Citrix-Umgebung einzurichten und sie von einem entfernten Standort aus in Ihre Umgebung zu integrieren. Mit Citrix haben Sie minimale Bandbreitenanforderungen zwischen Client / Host und Sie haben die Möglichkeit, das zu tun, was Sie lokal benötigen, und müssen diese Änderungen nicht an anderer Stelle replizieren. Nur meine 0,02 $

Ich würde SQL-Transaktionsreplikation verwenden. Das erstmalige Laden würde einige Zeit in Anspruch nehmen, aber sobald Sie den Betrieb aufgenommen haben, können Sie nur die gewünschten Informationen senden. Wenn Sie beispielsweise nur 3 oder 4 Tabellen haben, die aktualisiert werden, können Sie nur diese 3 oder 4 Tabellen senden.

Sie können auch auswählen, worüber Sie versenden möchten. FKs, gruppierte / nicht gruppierte Indizes, Tabellenpartitionsschemata, gespeicherte Prozesse und TONS mehr.

http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/

Wenn dies keine Option ist, können Sie REDGATE SQL BACKUP verwenden - http://www.red-gate.com/products/dba/sql-backup/ . Ich habe das schon früher benutzt und Komprimierungsgrade von bis zu 90% erreicht. Viel kleiner als SQL.