SQL Server 2014 :Cryptage natif des sauvegardes

Une nouvelle fonctionnalité de SQL Server 2014 dont beaucoup d'entre vous n'avaient pas entendu parler jusqu'à ce qu'elle soit annoncée cette semaine au PASS Summit est le chiffrement de sauvegarde natif dans les éditions Standard, Business Intelligence et Enterprise (désolé, Web et Express ne sont pas pris en charge). C'est quelque chose que les fournisseurs tiers proposent depuis longtemps, et il fait enfin son chemin dans le produit, prenant en charge quatre algorithmes de chiffrement :AES 128, AES 192, AES 256 et Triple DES (3DES).

Si vous utilisez actuellement Transparent Data Encryption uniquement dans le but d'avoir des données chiffrées dans vos fichiers de sauvegarde, cela pourrait être un moyen de migrer à partir de cette technique et d'avoir des sauvegardes chiffrées sans le coup que TDE place sur votre système en direct. Si vous utilisez actuellement un outil tiers pour les sauvegardes chiffrées, vous devez le comparer à la fonctionnalité et aux performances des sauvegardes chiffrées natives.

PS Vous pouvez télécharger CTP2 dès maintenant.

Je ne voulais pas me lancer dans la comparaison avec des produits tiers - je suis sûr qu'ils font tous du bon travail et qu'ils ont probablement des fonctionnalités supplémentaires auxquelles je n'ai même pas pensé. Je voulais juste tester quel type de succès les différents algorithmes prendraient sur des sauvegardes complètes, depuis et vers les disques durs traditionnels (RAID 1) et les disques SSD, et avec et sans compression native.

J'ai donc téléchargé le fichier de données AdventureWorks2012, j'en ai fait deux copies, je les ai nommées awSSD.mdf et awHDD.mdf , et placé un sur le disque RAID 1 (D:\) et un sur le disque SSD (E:\). Ensuite, j'ai joint les deux avec FOR ATTACH_REBUILD_LOG , réglez-les sur FULL récupération, modifié les paramètres de croissance automatique par défaut et défini l'emplacement par défaut des fichiers journaux entre les deux (car c'est le seul moyen que je connaisse pour spécifier l'emplacement du fichier journal reconstruit) :

USE [master];GO EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultLog', REG_SZ, N'D:\CTP2_Data';GO CREATE DATABASE awHDD ON (filename='D:\CTP2_Data\awHDD.mdf') POUR ATTACH_REBUILD_LOG ; ALTER DATABASE awHDD SET RECOVERY FULL;ALTER DATABASE awHDD MODIFY FILE (NAME =N'AdventureWorks2012_Data', FILEGROWTH =512000KB);ALTER DATABASE awHDD MODIFY FILE (NAME =N'AdventureWorks2012_Log', FILEGROWTH =512000KB);GO EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE' , N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultLog', REG_SZ, N'E:\CTP2_Data';GO CREATE DATABASE awSSD ON (filename='E:\CTP2_Data\awSSD.mdf') FOR ATTACH_REBUILD_LOG; ALTER DATABASE awSSD SET RECOVERY FULL;ALTER DATABASE awSSD MODIFY FILE (NAME =N'AdventureWorks2012_Data', FILEGROWTH =512000KB);ALTER DATABASE awSSD MODIFY FILE (NAME =N'AdventureWorks2012_Log', FILEGROWTH =512000KB);

Ensuite, je les ai agrandis en utilisant ce script de Jonathan Kehayias (afin que la base de données et le journal soient suffisamment volumineux pour être significatifs). Cela a pris environ 4 minutes par base de données sur HDD et SSD.

À ce stade, EXEC sp_helpfile; a donné ce qui suit pour chaque base de données :

nom fileid nom_fichier taille ----------------------- ------ -------- ------ ----AdventureWorks2012_Data 1 .mdf 1553408 KoAdventureWorks2012_Log 2 .ldf 5605504 Ko

Maintenant, quelques petites choses à propos de cette fonctionnalité avant de pouvoir réellement commencer à effectuer des sauvegardes cryptées. Vous devez disposer d'un certificat (ou d'une clé asymétrique) pour utiliser le chiffrement, ce qui nécessitera à son tour une clé principale. J'ai choisi un certificat et je l'ai créé comme suit :

USE master;GOCREATE MASTER KEY ENCRYPTION BY PASSWORD ='p@ssw0rd';GOOPEN MASTER KEY DECRYPTION BY PASSWORD ='p@ssw0rd';GOCREATE CERTIFICATE TestCert WITH SUBJECT ='EncryptionTesting';GO

Vous recevez également un avertissement si vous tentez de créer une sauvegarde chiffrée à l'aide d'un certificat qui n'a pas lui-même été sauvegardé :

Dans mon cas, je pourrais simplement sauvegarder le certificat et la clé principale, comme ceci :

BACKUP CERTIFICATE TestCert TO FILE ='C:\temp\TestCert.cert' WITH PRIVATE KEY ( FILE ='C:\temp\TestCert.key', ENCRYPTION BY PASSWORD ='p@ssw0rd' ); BACKUP MASTER KEY TO FILE ='C:\temp\MasterKey.key' CHIFFREMENT PAR MOT DE PASSE ='p@ssw0rd';

Strictement parlant, la sauvegarde de la clé principale n'est pas nécessaire pour effectuer une sauvegarde cryptée (ou même pour éviter l'avertissement), mais vous devez quand même la sauvegarder. Et vous voudrez probablement utiliser un mot de passe plus fort que p@ssw0rd , stockez-la ailleurs que sur le lecteur C:sur la même machine, etc. Enfin, sachez que si vous cryptez vos sauvegardes et que vous ne prenez pas toutes les précautions nécessaires, elles risquent d'être inutiles en cas de sinistre . Ce n'est pas une fonctionnalité que vous devriez simplement activer sans une bonne quantité de diligence et de tests.

Avec tout cela à l'écart, je pourrais continuer les tests. Ce système n'a qu'un seul disque basé sur un plateau et un seul SSD, donc je n'ai pas pu tester SSD -> SSD ou HDD différent -> HDD différent; uniquement la sauvegarde de l'un à l'autre ou sur le même lecteur. La syntaxe de base pour la sauvegarde avec chiffrement est :

BACKUP DATABASE ... AVEC CHIFFREMENT (ALGORITHM =, SERVER CERTIFICATE =);

Et les quatre valeurs possibles pour <algorithm> sont AES_128 , AES_192 , AES_256 et TRIPLE_DES_3KEY .

Donc, ensuite, j'ai généré le script pour exécuter les sauvegardes afin de comparer les performances et la taille de diverses combinaisons - les quatre algorithmes de cryptage différents (et sans cryptage), avec et sans compression, d'où proviennent les données (HDD ou SSD) et où les données sont sauvegardées sur (HDD ou SSD). Cela représente 40 sauvegardes différentes, et le script que j'ai utilisé pour le générer ressemble à ceci :

DECLARER @sql NVARCHAR(MAX) =N'';; AVEC s(s) AS (SELECT 1 UNION ALL SELECT 2),m AS (SELECT m FROM (VALUES('AES_128'),('AES_192'),('AES_256'),('TRIPLE_DES_3KEY'),(NULL )) AS m(m)),c AS (SELECT c FROM (VALUES('NO_COMPRESSION'),('COMPRESSION')) AS c(c)),d AS (SELECT d,t FROM (VALUES('D' ,'HDD'),('E','SSD')) AS d(d,t))SELECT @sql +=N'BACKUP DATABASE aw' + CASE s WHEN 1 THEN 'HDD' ELSE 'SSD' END + ' TO DISK =''' + d + ':\backup\' + n + '.bak'' WITH INIT, ' + c + ',' + COALESCE(' CHIFFREMENT (ALGORITHME =' + m + ', CERTIFICAT SERVEUR =TestCert),', '') + ' NOM =''' + n + ''';' FROM ( SELECT *, n ='test' + CONVERT(VARCHAR(8000), RIGHT('0' + RTRIM(r),2)) + '-' + COALESCE(m,'NO_ENCRYPTION') + '-' + CASE WHEN r <11 THEN 'HDD' ELSE 'SSD' END + '-to-' + t + '-' + c FROM ( SELECT *, r =ROW_NUMBER() OVER (PARTITION BY d.d ORDER BY s.s,m.m,c.c ) DEPUIS s CROSS JOIN m CROSS JOIN c CROSS JOIN d ) AS x) AS y ORDER BY r; --EXEC sp_executesql @sql;--GO 10 SELECT CONVERT(XML, @sql);

Ça a l'air vraiment compliqué, mais en fait ça ne fait que générer 40 BACKUP DATABASE cordes. Je sélectionne au format XML afin que, lorsque vous cliquez sur les résultats dans la grille, vous puissiez afficher l'intégralité de la sortie - au lieu de ce que PRINT ou la sélection de la sortie sur grille/texte vous limitera à. La sortie dans ce cas est ci-dessous (cliquez pour afficher/masquer) :

BACKUP DATABASE awHDD TO DISK ='D:\backup\test01-NO_ENCRYPTION-HDD-to-HDD-COMPRESSION.bak' WITH INIT, COMPRESSION, NAME ='test01-NO_ENCRYPTION-HDD-to-HDD-COMPRESSION'; BASE DE DONNÉES DE SAUVEGARDE awHDD SUR DISQUE ='E:\backup\test01-NO_ENCRYPTION-HDD-to-SSD-COMPRESSION.bak' AVEC INIT, COMPRESSION, NOM ='test01-NO_ENCRYPTION-HDD-to-SSD-COMPRESSION';BASE DE DONNÉES DE SAUVEGARDE awHDD TO DISK ='E:\backup\test02-NO_ENCRYPTION-HDD-to-SSD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, NAME ='test02-NO_ENCRYPTION-HDD-to-SSD-NO_COMPRESSION';BACKUP DATABASE awHDD TO DISK ='D:\backup\test02-NO_ENCRYPTION-HDD-to-HDD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, NAME ='test02-NO_ENCRYPTION-HDD-to-HDD-NO_COMPRESSION';BACKUP DATABASE awHDD TO DISK ='D :\backup\test03-AES_128-HDD-to-HDD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =AES_128, SERVER CERTIFICATE =TestCert), NAME ='test03-AES_128-HDD-to-HDD-COMPRESSION' ; SAUVEGARDE DE LA BASE DE DONNÉES awHDD SUR DISQUE ='E:\backup\test03-AES_128-HDD-to-SSD-COMPRESSIO N.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =AES_128, SERVER CERTIFICATE =TestCert), NAME ='test03-AES_128-HDD-to-SSD-COMPRESSION';BACKUP DATABASE awHDD TO DISK ='E:\backup\test04 -AES_128-HDD-to-SSD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_128, SERVER CERTIFICATE =TestCert), NAME ='test04-AES_128-HDD-to-SSD-NO_COMPRESSION';BACKUP DATABASE awHDD TO DISK ='D:\backup\test04-AES_128-HDD-to-HDD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_128, SERVER CERTIFICATE =TestCert), NAME ='test04-AES_128-HDD-to- HDD-NO_COMPRESSION';BACKUP DATABASE awHDD TO DISK ='D:\backup\test05-AES_192-HDD-to-HDD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =AES_192, CERTIFICAT SERVEUR =TestCert), NOM ='test05-AES_192-HDD-to-HDD-COMPRESSION';BACKUP DATABASE awHDD TO DISK ='E:\backup\test05-AES_192-HDD-to-SSD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =AES_192 , CERTIFICAT SERVEUR =TestCert) , NAME ='test05-AES_192-HDD-to-SSD-COMPRESSION';BACKUP DATABASE awHDD TO DISK ='E:\backup\test06-AES_192-HDD-to-SSD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION ( ALGORITHME =AES_192, CERTIFICAT SERVEUR =TestCert), NOM ='test06-AES_192-HDD-to-SSD-NO_COMPRESSION';BACKUP DATABASE awHDD TO DISK ='D:\backup\test06-AES_192-HDD-to-HDD-NO_COMPRESSION. bak' AVEC INIT, NO_COMPRESSION, CHIFFREMENT (ALGORITHM =AES_192, SERVER CERTIFICATE =TestCert), NAME ='test06-AES_192-HDD-to-HDD-NO_COMPRESSION';BACKUP DATABASE awHDD TO DISK ='D:\backup\test07-AES_256 -HDD-to-HDD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test07-AES_256-HDD-to-HDD-COMPRESSION';BACKUP DATABASE awHDD TO DISK ='E:\backup\test07-AES_256-HDD-to-SSD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test07-AES_256-HDD-to-SSD- COMPRESSION ; SAUVEGARDE DE LA BASE DE DONNÉES awHDD SUR DISQUE ='E:\backup\te st08-AES_256-HDD-to-SSD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test08-AES_256-HDD-to-SSD-NO_COMPRESSION';BACKUP DATABASE awHDD TO DISK ='D:\backup\test08-AES_256-HDD-to-HDD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test08-AES_256-HDD-to -HDD-NO_COMPRESSION';BACKUP DATABASE awHDD TO DISK ='D:\backup\test09-TRIPLE_DES_3KEY-HDD-to-HDD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =TRIPLE_DES_3KEY, CERTIFICAT SERVEUR =TestCert), NOM ='test09-TRIPLE_DES_3KEY-HDD-to-HDD-COMPRESSION';BACKUP DATABASE awHDD TO DISK ='E:\backup\test09-TRIPLE_DES_3KEY-HDD-to-SSD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =TRIPLE_DES_3KEY, SERVER CERTIFICATE =TestCert), NAME ='test09-TRIPLE_DES_3KEY-HDD-to-SSD-COMPRESSION';BACKUP DATABASE awHDD TO DISK ='E:\backup\test10-TRIPLE_DES_3KEY-HDD-to-SSD-NO_COMPRESSION .bak' AVEC INIT, NO_COMPRESSION, CHIFFREMENT (ALGORITHM =TRIPLE_DES_3KEY, SERVER CERTIFICATE =TestCert), NAME ='test10-TRIPLE_DES_3KEY-HDD-to-SSD-NO_COMPRESSION';BACKUP DATABASE awHDD TO DISK ='D:\backup\test10- TRIPLE_DES_3KEY-HDD-to-HDD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =TRIPLE_DES_3KEY, SERVER CERTIFICATE =TestCert), NAME ='test10-TRIPLE_DES_3KEY-HDD-to-HDD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D:\backup\test11-NO_ENCRYPTION-SSD-to-HDD-COMPRESSION.bak' WITH INIT, COMPRESSION, NAME ='test11-NO_ENCRYPTION-SSD-to-HDD-COMPRESSION';BACKUP DATABASE awSSD TO DISK ='E :\backup\test11-NO_ENCRYPTION-SSD-to-SSD-COMPRESSION.bak' WITH INIT, COMPRESSION, NAME ='test11-NO_ENCRYPTION-SSD-to-SSD-COMPRESSION';BACKUP DATABASE awSSD TO DISK ='E:\backup \test12-NO_ENCRYPTION-SSD-to-SSD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, NAME ='test12-NO_ENCRYPTION-SSD-to-SSD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D:\backup\test12- NO_ENCRYPTION-S SD-to-HDD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, NAME ='test12-NO_ENCRYPTION-SSD-to-HDD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D:\backup\test13-AES_128-SSD-to -HDD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =AES_128, SERVER CERTIFICATE =TestCert), NAME ='test13-AES_128-SSD-to-HDD-COMPRESSION';BACKUP DATABASE awSSD TO DISK ='E:\ backup\test13-AES_128-SSD-to-SSD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =AES_128, SERVER CERTIFICATE =TestCert), NAME ='test13-AES_128-SSD-to-SSD-COMPRESSION';BACKUP BASE DE DONNÉES awSSD TO DISK ='E:\backup\test14-AES_128-SSD-to-SSD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_128, SERVER CERTIFICATE =TestCert), NAME ='test14-AES_128-SSD -to-SSD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D:\backup\test14-AES_128-SSD-to-HDD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_128, SERVER CERTIFICATE =TestCert) , NOM ='test14-AES_128-SSD-to-H DD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D:\backup\test15-AES_192-SSD-to-HDD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =AES_192, CERTIFICAT SERVEUR =TestCert), NOM ='test15-AES_192-SSD-to-HDD-COMPRESSION';BACKUP DATABASE awSSD TO DISK ='E:\backup\test15-AES_192-SSD-to-SSD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =AES_192 , SERVER CERTIFICATE =TestCert), NAME ='test15-AES_192-SSD-to-SSD-COMPRESSION';BACKUP DATABASE awSSD TO DISK ='E:\backup\test16-AES_192-SSD-to-SSD-NO_COMPRESSION.bak' AVEC INIT, AUCUNE_COMPRESSION, CHIFFREMENT (ALGORITHME =AES_192, CERTIFICAT SERVEUR =TestCert), NOM ='test16-AES_192-SSD-to-SSD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D:\backup\test16-AES_192-SSD- to-HDD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_192, SERVER CERTIFICATE =TestCert), NAME ='test16-AES_192-SSD-to-HDD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D :\backup\test17-AES_256-SSD-to-HDD-COMPRE SSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test17-AES_256-SSD-to-HDD-COMPRESSION';BACKUP DATABASE awSSD TO DISK ='E:\backup\test17 -AES_256-SSD-to-SSD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test17-AES_256-SSD-to-SSD-COMPRESSION';BACKUP DATABASE awSSD TO DISK ='E:\backup\test18-AES_256-SSD-to-SSD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test18-AES_256-SSD-to- SSD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D:\backup\test18-AES_256-SSD-to-HDD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test18-AES_256-SSD-to-HDD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D:\backup\test19-TRIPLE_DES_3KEY-SSD-to-HDD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHME =TRIPLE_DES_3KEY , SERVEUR CER TIFICATE =TestCert), NAME ='test19-TRIPLE_DES_3KEY-SSD-to-HDD-COMPRESSION';BACKUP DATABASE awSSD TO DISK ='E:\backup\test19-TRIPLE_DES_3KEY-SSD-to-SSD-COMPRESSION.bak' AVEC INIT, COMPRESSION, CHIFFREMENT (ALGORITHM =TRIPLE_DES_3KEY, SERVER CERTIFICATE =TestCert), NAME ='test19-TRIPLE_DES_3KEY-SSD-to-SSD-COMPRESSION';BACKUP DATABASE awSSD TO DISK ='E:\backup\test20-TRIPLE_DES_3KEY-SSD-to- SSD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =TRIPLE_DES_3KEY, SERVER CERTIFICATE =TestCert), NAME ='test20-TRIPLE_DES_3KEY-SSD-to-SSD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D:\backup \test20-TRIPLE_DES_3KEY-SSD-to-HDD-NO_COMPRESSION.bak' WITH INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =TRIPLE_DES_3KEY, SERVER CERTIFICATE =TestCert), NAME ='test20-TRIPLE_DES_3KEY-SSD-to-HDD-NO_COMPRESSION'; 

 Je n'avais pas besoin de faire quoi que ce soit de spécial pour les chronométrer, car je pouvais extraire toutes les statistiques pertinentes de la base de données msdb une fois qu'elles étaient terminées (le seul inconvénient est que la durée n'est mesurée qu'à la granularité des secondes, sauf si je voulais pour analyser la sortie manuellement). J'ai donc décommenté le EXEC sp_executesql et GO lignes (je voulais exécuter chaque sauvegarde 10 fois pour obtenir des moyennes, éliminer les anomalies, etc.), appuyez sur F5, et je me suis mis au travail sur l'une de mes sessions pour le PASS Summit.
 

 Quand je suis revenu, j'ai vérifié les tables msdb pour obtenir les tailles/durées de chaque sauvegarde. Cette requête est assez simple :
 
;WITH x AS( SELECT nom, taille_naturelle =taille_sauvegarde/1024/1024.0, taille_compressée =taille_sauvegarde_compressée/1024/1024.0, durée =1.0*DATEDIFF(SECOND, date_début_sauvegarde, date_fin_sauvegarde) FROM msdb.dbo.backupset WHERE nom LIKE 'test %')SELECT nom, [natural_size] =MAX(natural_size), [compressed_size] =MAX(compressed_size), [min_duration] =MIN(durée), [max_duration] =MAX(durée), [avg_duration] =AVG(durée) FROM x GROUP BY nomORDER BY nom ;
 

 Cela me donnerait les données dont j'avais besoin pour créer de jolis graphiques.
 
Impact sur la taille
 

 Selon votre expérience du chiffrement en général, vous serez peut-être surpris ou non que le chiffrement d'une sauvegarde de base de données ait très peu d'impact sur sa taille globale. Comment cela fonctionne est au-delà de la portée de ce poste, pour certains; une explication simple serait que - du moins avec le cryptage AES - la compression n'est pas très efficace sur la plupart des sorties car il s'agit essentiellement de charabia aléatoire. 
 

 Le résultat final est que ce graphique n'est pas très excitant. Les tailles compressées et non compressées des sauvegardes natives par rapport aux quatre méthodes de chiffrement différentes :
 

 
Taille, en Mo, des sauvegardes avec et sans chiffrement 
 

 Comme vous pouvez le voir, il n'y a eu presque aucun impact sur la taille de la base de données - environ 0,03 % d'augmentation de la taille pour une sauvegarde non compressée et 0,04 % supplémentaire pour une sauvegarde compressée. 
 
Impact sur les performances
 

 Bien que le chiffrement ait eu un impact négligeable sur la taille, il l'a fait affecter la vitesse de la sauvegarde. Mais dans certains cas, pas comme vous le pensez. Voici la mesure globale des durées d'exécution moyennes pour chaque approche :
 

 
Durée moyenne, en secondes, de diverses sauvegardes 
 

 Je m'attendais vraiment à ce que le cryptage provoque toujours une baisse des performances, et vous devriez tester dans votre environnement pour voir si vos résultats sont différents des miens. Je vais revenir et mettre à jour cela avec un nouveau graphique montrant des cas particuliers qui m'ont surpris, et supprimer certaines valeurs aberrantes pour m'assurer que les résultats sont vraiment représentatifs.
 
Une mise en garde
 

 Une remarque importante :vous ne pouvez pas ajouter de sauvegardes chiffrées. Si vous générez un fichier de sauvegarde crypté en utilisant WITH INIT , puis essayez d'ajouter une autre sauvegarde chiffrée au même fichier, vous recevrez cette erreur :
 Msg 3095, Niveau 16, État 1, Ligne 11
La sauvegarde ne peut pas être effectuée car 'ENCRYPTION' a été demandé après que le support a été formaté avec une structure incompatible. Pour ajouter à ce jeu de supports, omettez 'ENCRYPTION' ou créez un nouveau jeu de supports en utilisant WITH FORMAT dans votre instruction BACKUP. Si vous utilisez WITH FORMAT sur un jeu de supports existant, tous ses jeux de sauvegarde seront écrasés.
Msg 3013, Niveau 16, État 1, Ligne 11
BACKUP DATABASE se termine anormalement. 

 Vous pouvez, de façon déroutante, ajouter un non -sauvegarde cryptée lorsque le fichier initial a été crypté. Ce n'est pas l'intention, et c'est un bogue que j'ai signalé sur Connect (#805220, mais il est actuellement marqué comme privé); j'espère qu'ils régleront ce problème avant RTM.
 

 En attendant, il faut faire attention ici car rien n'a été changé concernant le RESTORE HEADERONLY sortie pour indiquer si l'une des sauvegardes jointes a été chiffrée. Pour le découvrir, vous devrez vérifier le BackupSetGUID valeur dans cette sortie à Position = 1 , et trouvez le backup_set_uuid correspondant valeur dans msdb.dbo.backupset . Cette table comporte de nouvelles colonnes pour prendre en charge le chiffrement, où vous pouvez obtenir ces informations :key_algorithm , encryptor_thumbprint , et encryptor_type . Ceci est problématique dans les cas où vous n'avez pas le backupset données - peut-être qu'elles ont été effacées lors de tâches de maintenance, ou peut-être que vous ne pouvez pas y accéder parce que vous vous remettez vraiment d'un sinistre ou que vous n'avez que le fichier .bak (ou que vous n'avez que le fichier .bak pour d'autres raisons). Dans ce cas, j'espère qu'il existe un autre moyen de savoir à partir du fichier de sauvegarde qu'il a été crypté (et comment), mais au moment de la rédaction, je ne connais pas de moyen. J'ai déposé une suggestion (#805292, également privée) que la sortie de RESTORE HEADERONLY être augmenté avec des informations de chiffrement de la même manière qu'il a été augmenté avec des informations de compression lorsque cette fonctionnalité a été ajoutée dans SQL Server 2008.
 

 Lorsqu'ils résoudront ces problèmes (et je suis convaincu qu'ils le feront), je supprimerai tout ce bruit, mais il est important d'en être conscient entre-temps, si vous envisagez d'effectuer des tests avec les CTP actuels.
 
Suivant…
 

 Ce que ce type de sauvegarde signifie pour la restauration, je reviendrai dans un autre article, lorsque je testerai les vitesses de restauration et révélerai les zones problématiques. Je souhaite également revoir ces tests pour étudier les sauvegardes de journaux chiffrées.