Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Große Datenbanken belegen viel Speicherplatz und ihre Sicherung ist zeitaufwendig, was hohe Speicherkosten und eine langsame Leistung zur Folge hat. Die SQL‑Server‑Sicherungskomprimierung löst diese Probleme. Sie verkleinert Sicherungsdateien durchschnittlich um 50 % bis 80 %, spart Speicherplatz und beschleunigt die Sicherungsvorgänge erheblich.
Wenn Sie die SQL‑Server‑Sicherungen beschleunigen möchten, ist die Komprimierung ein entscheidender Vorteil – auch wenn sie etwas mehr CPU‑Leistung beansprucht. In diesem Artikel zeigen wir Ihnen vier Möglichkeiten, die Sicherungskomprimierung in SQL Server zu aktivieren: von einfachen Schritten in SSMS bis hin zu erweiterten Werkzeugen wie dem ZSTD‑Algorithmus.
Die SQL‑Server‑Sicherungskomprimierung ist eine Funktion zur Verkleinerung von Sicherungsdateien. Wenn Sie diese Funktion aktivieren, komprimiert die Datenbank‑Engine die Daten, bevor sie auf den Datenträger geschrieben werden. Dadurch fällt die Sicherungsdatei deutlich kleiner aus als die ursprüngliche Datenbank.
Wichtig ist die Abgrenzung zu anderen Komprimierungsarten: Die „Datenkomprimierung“ (Zeilen‑ und Seitenkomprimierung) findet innerhalb der Datenbanktabellen statt. Die Sicherungskomprimierung wird ausschließlich während des Sicherungsvorgangs ausgeführt. Für komprimierte Sicherungen benötigen Sie keine bereits komprimierten Tabellen.
Technisch hängt das Komprimierungsverhältnis von dem Datentyp ab: Text‑ und numerische Daten lassen sich gut komprimieren, verschlüsselte Daten oder bereits komprimierte Dateien (z. B. PDFs, ZIP‑Dateien) hingegen kaum. Ältere SQL‑Server‑Versionen nutzten einen proprietären Standardalgorithmus; SQL Server 2025 führte den Zstandard‑Algorithmus (ZSTD) für eine verbesserte Komprimierungseffizienz ein.
Die Nutzung der Komprimierung bietet Datenbankadministratoren wesentliche Vorteile. Sie behebt die häufigsten Probleme bei der Verwaltung großer Datenmengen: Geschwindigkeit, Speicherbedarf und Kosten.
Geringerer Speicherbedarf
Die Komprimierung verkleinert die Sicherungsdateien drastisch bei einem typischen Komprimierungsverhältnis von 50‑80 %. Sie zeigt die beste Wirkung bei Datenbanken mit Text‑ oder sich wiederholenden Werten; bei verschlüsselten Daten oder Binärdateien (z. B. Bildern) ist der Speichergewinn gering.
Schnellere Sicherungsvorgänge
Obwohl die Komprimierung die CPU‑Auslastung erhöht, beseitigt sie Flaschenhälse bei der Datenträger‑E/A, indem weniger Daten auf den Datenträger geschrieben werden. Dadurch werden komprimierte SQL‑Server‑Sicherungen schneller abgeschlossen und lassen sich auch in enge Wartungsfenster einpassen.
Schnellere Übertragung an externe Standorte
Kleinere komprimierte Sicherungen lassen sich schneller an externe Standorte oder Notfallwiederherstellungs‑Standorte übertragen. Dadurch sinkt der Bandbreitenbedarf, externe Kopien bleiben aktuell und die Wiederherstellungsbereitschaft (RPO) verbessert sich.
Niedrigere Sicherungskosten (Cloud)
Komprimierte Sicherungen senken Cloud‑Speicherkosten (z. B. Azure, AWS), da weniger Gigabyte belegt werden. Zudem fallen geringere Ausgangsgebühren an, wenn Sicherungen aus der Cloud für lokale Wiederherstellungen heruntergeladen werden.
Die SQL‑Server‑Sicherungskomprimierung lässt sich auf mehrere flexible Arten aktivieren: über die grafische Oberfläche, T‑SQL‑Skripte oder als serverweite Standardeinstellung. Zuerst die am häufigsten genutzte Methode für eine schnelle, unkomplizierte Umsetzung.
Für viele DBAs ist SQL Server Management Studio (SSMS) die einfachste Möglichkeit, komprimierte Sicherungen zu erstellen. Diese Vorgehensweise eignet sich für manuelle Sicherungsaufgaben oder die Anpassung der Komprimierungseinstellungen für eine einzelne Sicherung.
Schritt‑für‑Schritt‑Anleitung:
Viele DBAs bevorzugen T‑SQL‑Skripte für Sicherungen, da sie sich gut automatisieren und zeitplanen lassen. Um die Sicherungskomprimierung zu aktivieren, fügen Sie einfach das Schlüsselwort COMPRESSION zum üblichen Sicherungsbefehl hinzu.
Die Abfragen für komprimierte SQL‑Server‑Sicherungen sind intuitiv. Im Folgenden finden Sie die kompakten Skripte für die drei gängigsten Sicherungsarten:
Erstellt eine vollständige komprimierte Kopie der Datenbank:
-- Vollständige Sicherung mit Komprimierung (Integritätsprüfung + Fortschrittsanzeige)
BACKUP DATABASE [IhrDatenbankName]
TO DISK = 'C:\Backups\IhrDatenbank_Voll.bak'
WITH COMPRESSION, CHECKSUM, STATS = 10;
Komprimiert nur die Daten, die seit der letzten vollständigen Sicherung geändert wurden:
-- Differenzielle Sicherung mit Komprimierung
BACKUP DATABASE [IhrDatenbankName]
TO DISK = 'C:\Backups\IhrDatenbank_Diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM;
Komprimiert Transaktionsprotokolle – besonders wichtig für stark genutzte Datenbanken mit großen Protokolldateien:
-- Transaktionsprotokollsicherung mit Komprimierung
BACKUP LOG [IhrDatenbankName]
TO DISK = 'C:\Backups\IhrDatenbank_Log.trn'
WITH COMPRESSION;
CHECKSUM ist im Beispiel als bewährte Vorgehensweise enthalten: Es erkennt Beschädigungen der Sicherungsdatei während der Erstellung. Mit T‑SQL steuern Sie Speicherpfad und Konfiguration komprimierter SQL‑Server‑Sicherungen und erhalten volle Flexibilität für automatisierte Arbeitsabläufe.
Die manuelle Aktivierung der Komprimierung für jede einzelne Sicherung ist aufwendig und birgt das Risiko von Versehen. Legen Sie stattdessen die Standardeinstellung für die SQL‑Server‑Sicherungskomprimierung auf Instanzebene fest. Nach der Konfiguration werden alle neuen Sicherungen automatisch komprimiert, ohne dass jeder Auftrag manuell angepasst werden muss.
Festlegen der Standardeinstellung in SSMS
Festlegen der Standardeinstellung per T‑SQL
Nutzen Sie den Befehl sp_configure für eine schnelle Einrichtung, ideal für die Verwaltung vieler Server:
-- Aktivieren der Sicherungskomprimierung als instanzweiten Standard
EXEC sys.sp_configure N'backup compression default', N'1';
RECONFIGURE WITH OVERRIDE;
Nachdem dieser Standard festgelegt wurde, nutzen Sicherungsbefehle ohne explizite Komprimierungsangabe automatisch die Komprimierung. Für einzelne unkomprimierte Sicherungen fügen Sie das Schlüsselwort NO_COMPRESSION zum T‑SQL‑Skript hinzu. Dies ist eine gängige bewährte Vorgehensweise für moderne SQL‑Server‑Umgebungen und sorgt für automatische Speichereinsparungen bei allen Sicherungen.
SQL Server 2025 führte Zstandard (ZSTD) als neuen erweiterten Komprimierungsalgorithmus für Sicherungen ein und löst damit das ältere interne Komprimierungsverfahren früherer Versionen ab. ZSTD erreicht bessere Komprimierungsverhältnisse bei geringerer CPU‑Belastung und arbeitet damit effizienter als herkömmliche Komprimierung.
Besonders für sehr große Datenbanken geeignet: ZSTD verkleinert Sicherungsdateien wirkungsvoll und beschleunigt gleichzeitig den Sicherungsvorgang.
Die ZSTD‑Komprimierung steht ausschließlich über T‑SQL zur Verfügung (es gibt noch kein entsprechendes Kontrollkästchen in SSMS). Fügen Sie einfach den Parameter ALGORITHM = ZSTD zum komprimierten Sicherungsbefehl hinzu:
-- SQL Server 2025‑Sicherung mit ZSTD‑Komprimierungsalgorithmus
BACKUP DATABASE [IhrDatenbankName]
TO DISK = 'C:\Backups\IhrDatenbank_ZSTD.bak'
WITH COMPRESSION (ALGORITHM = ZSTD), CHECKSUM;
Wenn Sie SQL Server 2025 einsetzen, ist ZSTD die optimale Wahl für komprimierte SQL‑Server‑Sicherungen. Es stellt ein ausgewogenes Verhältnis zwischen hoher Sicherungsgeschwindigkeit und maximaler Dateikomprimierung her.
Obwohl SQL Server über eine native Sicherungskomprimierung verfügt, benötigen viele Unternehmen mehr als nur eine einfache Dateiverkleinerung. Moderne Umgebungen erfordern oft eine zentrale Sicherungsverwaltung für Datenbanken, virtuelle Maschinen, Dateisysteme und heterogene Speicher sowie eine bessere Steuerung von Netzwerkauslastung und Sicherungsfenstern.
i2Backup ist eine Sicherungsplattform für den Schutz unterschiedlicher Arbeitslasten – nicht nur für SQL Server. Sie ergänzt SQL‑Sicherungen um eine hocheffiziente Komprimierung, intelligente Übertragungsoptimierung und flexible Zeitplanung. Gleichzeitig unterstützt sie System‑, Datei‑ und speicherbasierte Sicherungen innerhalb einer einheitlichen Lösung.
Für private Projekte oder kleine Server reicht oft die native Komprimierung von SQL Server aus. Für großangelegte, compliance‑gerechte oder geschäftskritische Umgebungen liefert i2Backup eine vollständigere und zuverlässigere Lösung: Es vereint Komprimierung, intelligente Bandbreitensteuerung und unternehmensgerechte Sicherungsverwaltung auf einer Plattform.
Befolgen Sie diese zentralen Best Practices, damit Ihre Komprimierung effizient, zuverlässig und frei von vermeidbaren Fehlern arbeitet. Dies ist wichtig, um die Integrität der Sicherungen zu wahren und gleichzeitig die Vorteile komprimierter Dateien voll auszunutzen.
Fügen Sie jeder komprimierten Sicherung (in SSMS oder per T‑SQL) die Klausel WITH CHECKSUM hinzu. Dadurch wird die Datenintegrität während des Sicherungsvorgangs überprüft. Es erkennt Beschädigungen der Quelldaten oder der Sicherungsdatei, die die Komprimierung ggf. verdecken würde – damit Ihre komprimierte Sicherung auch wiederherstellbar ist.
Nutzen Sie bei großen Datenbanken neben der Komprimierung auch das Sicherungs‑Striping: Teilen Sie die komprimierte Sicherung auf mehrere Datenträgerdateien bzw. Volumes auf. Dadurch verringern sich E/A‑Konflikte auf einem einzelnen Laufwerk, komprimierte Sicherungs‑ und Wiederherstellungsvorgänge werden schneller und große komprimierte Dateien lassen sich leichter verwalten und übertragen.
Komprimieren Sie niemals bereits komprimierte Daten. Das verschwendet CPU‑Ressourcen und führt oft zu größeren Dateien (oder nur geringen Einsparungen). Verzichten Sie auf die Komprimierung bei Sicherungen mit bereits komprimierten Inhalten (z. B. ZIP‑Dateien, PDFs, verschlüsselte Dateien, komprimierte Medien). Vermeiden Sie zudem eine betriebssystemseitige Komprimierung von bereits komprimierten SQL‑Server‑Sicherungsdateien.
Optimieren Sie die Komprimierungseffizienz, indem Sie im T‑SQL‑Sicherungsbefehl MAXTRANSFERSIZE = 131072 (128 KB) festlegen. Diese 128‑KB‑Blockgröße passt zur Komprimierungs‑Engine von SQL Server, senkt den Mehraufwand und verbessert sowohl das Komprimierungsverhältnis als auch die Sicherungsgeschwindigkeit für die meisten Datenbank‑Arbeitslasten.
Prüfen Sie eine komprimierte Sicherung unmittelbar nach ihrer Erstellung. Gehen Sie niemals davon aus, dass die Sicherung fehlerfrei abgeschlossen wurde. Nutzen Sie das Werkzeug „Sicherungsintegrität überprüfen“ in SSMS oder den T‑SQL‑Befehl RESTORE VERIFYONLY, um sicherzustellen, dass die komprimierte Datei intakt, lesbar und wiederherstellbar ist. Dadurch vermeiden Sie Überraschungen mit beschädigten Sicherungen in kritischen Wiederherstellungsszenarien.
F1: Beeinflusst die SQL‑Server‑Sicherungskomprimierung die Wiederherstellungsdauer?
Sie beschleunigt die Wiederherstellung in der Regel. Obwohl die CPU die Daten dekomprimieren muss, werden deutlich weniger Daten vom Datenträger gelesen – und die Datenträgergeschwindigkeit ist fast immer der Flaschenhals. Aus diesem Grund lassen sich komprimierte Sicherungen in den meisten Umgebungen schneller wiederherstellen als unkomprimierte.
F2: SQL Server Standard‑ gegenüber Enterprise‑Edition bezüglich der Sicherungskomprimierung?
Bei älteren SQL‑Server‑Versionen war die Sicherungskomprimierung nur auf die Enterprise‑Edition beschränkt. Seit Version 2016 unterstützen sowohl die Standard‑ als auch die Enterprise‑Edition die Erstellung komprimierter Sicherungen. Die Express‑Edition kann komprimierte Sicherungen wiederherstellen, aber nicht erstellen.
F3: Lassen sich differenzielle Sicherungen und Protokollsicherungen komprimieren?
Ja. Die SQL‑Server‑Sicherungskomprimierung funktioniert für alle Sicherungsarten: vollständige, differenzielle und Transaktionsprotokollsicherungen. Die Komprimierung von Protokollsicherungen ist besonders wertvoll für stark genutzte Datenbanken mit großen Protokolldatenmengen.
F4: Ist die Erstellung einer komprimierten SQL‑Server‑Sicherung langsamer?
Nein, sie ist meist schneller. Obwohl die Komprimierung die CPU‑Auslastung erhöht, sinkt die zu schreibende Datenmenge auf den Datenträger drastisch. Auf den meisten Servern ist die Datenträger‑E/A der Hauptflaschenhals. Weniger zu schreibende Daten führen also zu kürzeren Sicherungszeiten.
F5: Welches Komprimierungsverhältnis kann ich erwarten?
Ein typisches Verhältnis liegt bei 50‑80 %. Das bedeutet, Sicherungsdateien sind 2‑ bis 5‑mal kleiner als die Ausgangsdaten. Der größte Effekt ergibt sich bei Text‑ und numerischen Daten. Bei verschlüsselten Daten oder Dateien wie Bildern oder PDFs ist der Komprimierungseffekt gering bis nicht vorhanden.
Die SQL‑Server‑Sicherungskomprimierung ist ein unverzichtbares Werkzeug für jeden DBA. Sie löst die Probleme langsamer Sicherungen und hoher Speicherkosten. Durch die Verkleinerung der Dateien sparen Sie Speicherplatz und erledigen Ihre Wartungsaufgaben deutlich schneller.
Wir haben vier Möglichkeiten vorgestellt, die SQL‑Server‑Sicherungskomprimierung zu aktivieren: SSMS für manuelle Aufgaben, T‑SQL für automatisierte Skripte, die instanzweite Standardeinstellung oder den erweiterten ZSTD‑Algorithmus für maximale Leistung.
Für noch bessere Ergebnisse können Sie professionelle Werkzeuge wie i2Backup einsetzen. Solche Lösungen machen Ihre Strategie für die Sicherungskomprimierung zuverlässiger und einfacher zu verwalten. Legen Sie noch heute die Komprimierung als Servereinstellung fest, um Zeit und Kosten zu sparen.
