Was ist der effektivste Weg, um eine SQL Server-Sicherung zu komprimieren und zu speichern? [geschlossen]

9

Ich habe verschiedene Methoden zum Komprimieren und Speichern von SQL Server-Sicherungen (mit SQL Server 2008 R2 Enterprise Edition) getestet und frage mich, was der effektivste Komprimierungsalgorithmus für die Langzeitspeicherung dieser Sicherungen außerhalb von SQL ist interne Komprimierungsalgorithmen.

Ich mache mir keine Sorgen um den physischen Speicher, die Bandlaufwerke oder irgendetwas anderes, sondern versuche nur, unsere 3 TB Daten- und Protokolldateien in die kleinste einzelne Datei umzuwandeln, die ich kann.

Wäre zum Beispiel eine .zip oder .7z? Oder gibt es zu viele Variablen in meiner Datenbank, um genau abschätzen zu können, welche am effektivsten sind, und ich muss nur einige Tests durchführen? Oder ist die interne Komprimierung von SQL Server die beste, die ich bekommen werde?

sql-server-2008-r2 compression backup

— Sean Long
quelle

Der physische Speicher ist der treibende Faktor dafür, da unser Festplattenspeicher knapp wird. Ich wollte mich jedoch von der Diskussion über die Art des von mir verwendeten RAID oder die Antwort "Holen Sie sich einfach mehr Platten" abwenden, da dies Dinge sind, an denen ich bereits arbeite, die aber langfristige Lösungen sind.

— Sean Long

Dies scheint etwas zu sein, das Sie testen könnten, da es weitgehend von der Art Ihrer Daten abhängt . Sichern Sie eine Datenbank mit Komprimierung und versuchen Sie dann, die Sicherungsdatei mit anderen Komprimierungswerkzeugen weiter zu komprimieren. Persönlich kann ich mir nicht vorstellen, dass Sie genug zusätzlichen Speicherplatz benötigen, um den Prozess zu komplizieren, und vergessen Sie nicht, dass mehr Komprimierung = mehr CPU, manchmal = mehr Zeit. Wenn es also eine zusätzliche Minute dauert, um zusätzliche 100 MB Speicherplatz zu sparen, lohnt sich das dann, wenn Sie nach Wiederherstellung suchen?

— Aaron Bertrand

13

Ich habe verschiedene Methoden zum Komprimieren und Speichern von MS SQL-Sicherungen (mit MS SQL 2008 R2 Enterprise Edition) getestet und frage mich, was der effektivste Komprimierungsalgorithmus für die Langzeitspeicherung dieser Sicherungen außerhalb von SQL ist interne Komprimierungsalgorithmen.

Da Sie SQL 2008 R2 Enterprise Edition verwenden, können / müssen Sie diese nutzen

Datenkomprimierung - Zeilen- und Seitenkomprimierung. auf Datenebene
Sicherungskomprimierung beim Erstellen einer Sicherung, um den Speicherbedarf der Sicherungen zu minimieren.
```
USE master;
GO
EXEC sp_configure 'backup compression default', '1';
RECONFIGURE WITH OVERRIDE;
```

Bei der Sicherungskomprimierung werden CPU-Zyklen verwendet, um die Daten zu komprimieren, bevor sie den Server verlassen. Aus diesem Grund sind komprimierte Sicherungen in den allermeisten Szenarien schneller als nicht komprimierte Sicherungen.

Beachten Sie, dass Sie bei Verwendung von Open Source-Tools die Datenbanksicherungsdatei dekomprimieren müssen, bevor Sie den Wiederherstellungsprozess selbst starten können.

Beispiel: Wenn Sie eine SQL-Datenbanksicherung von 50 GB erhalten, die auf 5 GB komprimiert ist. Um diese Datenbank wiederherzustellen, benötigen Sie viel mehr Speicherplatz:

5 GB für die Zip-Datei
50 GB für die Sicherungsdatei
50 GB für die wiederhergestellte Datenbank. (Angenommen, es ist kein leerer Speicherplatz in der Datenbank)

Insgesamt werden 105 GB Festplattenspeicher benötigt.

Sie können nach der Sicherungskomprimierung weiterhin OpenSource- Komprimierungstools wie gzip , 7Zip , bzip2 oder QuickLZ verwenden, um davon zu profitieren.

Schauen Sie sich auch MSSQL Compressed Backup auf Codeplex an.

Gute Referenzen für Vergleichsstatistiken

— Kin Shah
quelle

3

Wenn Sie Ihre Sicherungen über SQL-Komprimierung komprimiert haben, können Sie nicht viel Komprimierung erzielen, wenn Sie versuchen, die Sicherungsdatei zu komprimieren / 7zip / rar.

— user1207758

8

In Bezug auf die Backup-Komprimierung habe ich (vor einigen Jahren) die Backup-Komprimierungsoptionen von Red Gates SQL Backup , Quests LiteSpeed für SQL Server und Ideras SQLSafe verglichen und die drei Produkte verglichen . Die Unterschiede bei einem typischen Backup bei maximaler Komprimierung betrugen etwa 5% zwischen den drei für die benötigte Zeit und einen etwas größeren Spread für die Backup-Größe, wobei Red Gate die Nase vorn hatte (90% Komprimierung gegenüber 80 und 85% bei Idera und Quest in dieser Reihenfolge).

— Thomas Rushton
quelle