News zu Servicewelten
Durch den Ausfall einer Platte mit Datenbankdateien oder durch das unbeabsichtigte Löschen/Überschreiben von Daten bzw. Tabellen kann es schnell zu Datenverlust kommen. Regelmäßige Datenbank Backups gehören daher zu den wichtigsten Maßnahmen um zu verhindern, dass unternehmenskritische Informationen verloren gehen. Backups großer Datenbanken können jedoch das vorgesehene Zeitfenster oder den zur Verfügung stehenden Speicherplatz schnell sprengen. Eine Komprimierung der Backups ist daher empfehlenswert, wenn du diese mit möglichst geringem Zeitaufwand durchführen möchtest und/oder der zur Verfügung stehende Speicherplatz begrenzt ist.
Im Folgenden haben wir ein paar Tipps für dich, was du bei der Backupkomprimierung des Microsoft SQL Servers beachten solltest und mit welcher Abfrage du das Einsparpotential ermitteln kannst.
Der Microsoft SQL Server bietet bereits seit der Version 2008 die Möglichkeit einer Backupkomprimierung an. Während anfangs die Enterprise Edition benötigt wurde, ist diese Funktion seit der Version 2008 R2 auch in der Standard Edition enthalten.
Alternativ kann für große Tabellen oder Indizes auch die Tabellenkomprimierung verwendet werden, um den Speicherbedarf der Datenbank und schlussendlich der Backups zu senken. Bis zum SQL Server 2016 RTM war hierfür die Enterprise Edition obligatorisch. Seit dem SQL Server 2016 SP1 wird die Tabellenkomprimierung auch in der Standard Edition unterstützt.
Um die Backupkomprimierung in der Instanz standardmäßig zu verwenden, muss lediglich der Haken bei „Compress Backup“ unter „Database Settings“ in den Eigenschaften der Instanz gesetzt werden.
Als weitere Möglichkeit kann die Sicherung auch für jedes Backup einzeln konfiguriert werden. Dafür wird einfach die gewünschte Option im Dropdown „Set backup compression“ im Assistenten „Back Up Database“ unter „Backup Options“ ausgewählt.
SELECT bset.database_name
, CASE bset.type
WHEN 'D' THEN 'Database'
WHEN 'L' THEN 'Log'
WHEN 'I' THEN 'Differential'
END AS backup_type
, CONVERT(DATETIME2(0), bset.backup_start_date)
AS backup_start_date
, CONVERT(DATETIME2(0), bset.backup_finish_date)
AS backup_finish_date
, DATEDIFF (s, bset.backup_start_date, bset.backup_finish_date)
AS 'Time To Backup (sec)'
, ROUND(CONVERT(FLOAT, bset.compressed_backup_size/1024/1024), 2)
AS 'Compr. Size (MB)'
, ROUND(CONVERT(FLOAT, bset.backup_size/1024/1024), 2)
AS 'Uncompr. Size (MB)'
, FORMAT(CONVERT (FLOAT, bset.compressed_backup_size) /
CONVERT (FLOAT, bset.backup_size), 'P')
AS 'Compr. Ratio'
FROM msdb.dbo.backupset AS bset
WHERE database_name = 'AdventureWorks2019'
ORDER BY
bset.database_name,
bset.backup_finish_date; 
Falls eine zu sichernde Datenbank allerdings mittels Transparent Data Encryption (TDE) verschlüsselt wurde, wird der Speicherplatz, durch die Backupkomprimierung, bis einschließlich SQL-Server 2014, nicht gesenkt.
Erst ab SQL Server 2016 wird die Komprimierung der Backups von TDE-verschlüsselten Datenbanken unterstützt. Dabei ist zu beachten, dass, bis einschließlich SQL Server 2019 CU4, der Parameter MAXTRANSFERSIZE auf einen Wert größer 65536 gesetzt werden muss. Dieser kann wie über T‑SQL wie folgt gesetzt werden:
BACKUP DATABASE [AdventureWorks2012]
TO DISK = N'\\BackupSrv\MSSQL\AW_compressed.bak'
WITH
COMPRESSION,
MAXTRANSFERSIZE = 65537 Eine Komprimierung der Backups ist in vielen Fällen lohnenswert, besonders wenn der zur Verfügung stehende Speicherplatz begrenzt ist. Unabhängig davon sollten Backupgröße und ‑dauer regelmäßig mittels Monitoring überprüft werden. So lassen sich etwaige Probleme – wie z.B. das Volllaufen der Platte oder des Shares – vermeiden.
Du hast Fragen zum Thema Backupkomprimierung oder dem Durchführen von Backups allgemein? Melde dich einfach bei uns. Gern schauen wir gemeinsam mit dir über deine Datenbankinfrastruktur, um Optimierungsmöglichkeiten zu eruieren.
Share this article