Qual è il modo più efficace per comprimere e archiviare un backup di SQL Server? [chiuso]

9

Ho fatto alcuni test su diversi metodi per comprimere e archiviare i backup di SQL Server (utilizzando SQL Server 2008 R2 Enterprise Edition) e mi chiedo quale sia l'algoritmo di compressione più efficace per l'archiviazione a lungo termine di quei backup, al di fuori di SQL algoritmi di compressione interna.

Non sono preoccupato per l'archiviazione fisica o le unità a nastro o altro, sto solo cercando di trasformare i nostri 3 TB di dati e file di registro nel più piccolo file singolo che posso.

Quindi, per esempio, sarebbe un .zip o .7z? Oppure ci sono troppe variabili nel mio database per essere in grado di stimare con precisione quale sarà la più efficace e dovrò solo fare dei test? O la compressione interna di SQL Server è la migliore che otterrò?

sql-server-2008-r2 compression backup

— Sean Long
fonte

La memoria fisica è il fattore trainante per questo, perché il nostro spazio sul disco rigido sta per esaurirsi. Tuttavia, volevo evitare la discussione sul tipo di RAID che sto usando o la risposta è "Ottieni solo più piatti", dal momento che sono cose su cui sto già lavorando, ma sono soluzioni a lungo termine.

— Sean Long,

Sembra qualcosa che potresti testare, poiché dipenderà in gran parte dalla natura dei tuoi dati. Eseguire il backup di un database con compressione, quindi provare a comprimere ulteriormente il file di backup utilizzando altri strumenti di compressione. Personalmente non riesco a immaginare che avrai abbastanza spazio extra per rendere la pena complicare il processo e non dimenticare che più compressione = più CPU che a volte = più tempo. Quindi, se ci vuole un minuto in più per risparmiare altri 100 MB di spazio su disco, ne varrà la pena quando tenterai di ripristinare?

— Aaron Bertrand

13

Ho fatto alcuni test su diversi metodi per comprimere e archiviare i backup di MS SQL (utilizzando MS SQL 2008 R2 Enterprise Edition) e mi chiedo quale sia l'algoritmo di compressione più efficace per l'archiviazione a lungo termine di quei backup, al di fuori di SQL algoritmi di compressione interna.

Poiché si utilizza SQL 2008 R2 Enterprise Edition, è possibile / è necessario sfruttare

Compressione dei dati - Compressione di righe e pagine. a livello di dati
Compressione del backup durante l'esecuzione del backup per ridurre al minimo l'impronta del disco dei backup.
```
USE master;
GO
EXEC sp_configure 'backup compression default', '1';
RECONFIGURE WITH OVERRIDE;
```

La compressione del backup utilizza i cicli della CPU per comprimere i dati prima che escano dal server ed è per questo che nella stragrande maggioranza degli scenari, i backup compressi sono più veloci dei backup non compressi.

Si noti che quando si utilizzano gli strumenti Open source è necessario decomprimere il file di backup del database prima di poter avviare autonomamente il processo di ripristino.

ad es .: quando si riceve un backup del database SQL di 50 GB, che è compresso a 5 GB. Per ripristinare questo database, è necessario molto più spazio su disco:

5 GB per il file zip
50 GB per il file di backup
50 GB per il database ripristinato. (supponiamo che non ci sia spazio vuoto nel database)

In totale sono necessari 105 GB di spazio su disco.

È ancora possibile utilizzare gli strumenti di compressione open source come gzip , 7Zip , bzip2 o QuickLZ dopo la compressione del backup per trarne vantaggio.

Inoltre, dai un'occhiata a MSSQL Compressed Backup su codeplex.

Buoni riferimenti per le statistiche di confronto

— Kin Shah
fonte

3

Se hai compresso i tuoi backup tramite compressione SQL, non sarai in grado di ottenere molta compressione se provi a comprimere / 7zip / rar il file di backup.

— user1207758

8

In termini di compressione del backup, ho fatto (un paio di anni fa) un confronto tra le opzioni di compressione del backup fornite da SQL Gate di Red Gate , LiteSpeed di Quests per SQL Server e SQLSafe di Idera , confrontando i tre prodotti. Le differenze in un backup tipico alla massima compressione erano circa uno spread del 5% tra i tre per il tempo impiegato e uno spread un po 'più ampio per le dimensioni del backup, con Red Gate che usciva in cima (compressione del 90% contro 80 e 85% per Idera & Quest, in questo ordine).

— Thomas Rushton
fonte