SQL Server 2014:Native backup-kryptering

En ny funktion i SQL Server 2014, som mange af jer ikke havde hørt om, før den blev annonceret i denne uge på PASS Summit, er native backup-kryptering i Standard, Business Intelligence og Enterprise Editions (beklager, Web og Express understøttes ikke). Dette er noget, som tredjepartsleverandører har tilbudt i lang tid, og det kommer endelig ind i produktet og understøtter fire krypteringsalgoritmer:AES 128, AES 192, AES 256 og Triple DES (3DES).

Hvis du i øjeblikket bruger Transparent Data Encryption udelukkende med det formål at have krypterede data i dine backup-filer, kan dette være en måde at migrere fra den teknik og have krypterede backups uden det hit, som TDE placerer på dit live-system. Hvis du i øjeblikket bruger et tredjepartsværktøj til krypterede sikkerhedskopier, bør du sammenligne det med funktionaliteten og ydeevnen af native krypterede sikkerhedskopier.

P.S. Du kan downloade CTP2 lige nu.

Jeg ønskede ikke at komme ind på at sammenligne med 3. parts produkter – jeg er sikker på, at de alle gør et fint stykke arbejde og sandsynligvis har yderligere funktioner, som jeg ikke engang har tænkt over. Jeg ville bare teste, hvilken slags hit de forskellige algoritmer ville tage på fuld sikkerhedskopiering, fra og til både traditionelle spinny-diske (RAID 1) og solid state-drev, og med og uden native komprimering.

Så jeg downloadede AdventureWorks2012-datafilen, lavede to kopier og gav dem navnet awSSD.mdf og awHDD.mdf , og placerede en på RAID 1-drevet (D:\) og en på SSD-drevet (E:\). Så vedhæftede jeg begge med FOR ATTACH_REBUILD_LOG , indstil dem til FULD gendannelse, ændret standardindstillingerne for automatisk vækst og indstillet standardplaceringen for logfiler imellem (da dette er den eneste måde, jeg kender til at angive placeringen af den genopbyggede logfil):

BRUG [master];GO EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultLog', REG_SZ, N'D:\CTP2_Data';GO OPRET DATABASE (filawHDDname='D:\CTP2_Data\awHDD.mdf') FOR ATTACH_REBUILD_LOG; Alter database awhdd satte gendannelse fuld; alter database awhdd Ændre fil (navn =n'AdventureWorks2012_Data ', FileGrowth =512000KB); Alter Database AWHDD Modify File (navn =N'AdventureWorks2012_Log', FileGrowth =512000kb); Go exec xp_insture_regs2012_log ', FileGrowth =512000kb) , N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultLog', REG_SZ, N'E:\CTP2_Data';GO OPRET DATABASE awSSD ON (filnavn='E:\CTP2_Data\awBUSSD.mdf') FOR ATTACH_RET; 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_Data', FILEGROWTH =512000KB);

Dernæst forstørrede jeg dem ved hjælp af dette script fra Jonathan Kehayias (så både databasen og loggen ville være store nok til at være meningsfulde). Dette tog omkring 4 minutter pr. database på både HDD og SSD.

På det tidspunkt, EXEC sp_helpfile; gav følgende for hver database:

navn fil-id filnavn størrelse ----------------------- -------------- ------ ----AdventureWorks2012_Data 1 .mdf 1553408 KBAdventureWorks2012_Log 2 .ldf 5605504 KB

Nu, et par ting om denne funktion, før vi faktisk kan begynde at udføre krypterede sikkerhedskopier. Du skal have et certifikat (eller asymmetrisk nøgle) for at bruge kryptering, og dette vil igen kræve en hovednøgle. Jeg valgte et certifikat og oprettede disse som følger:

BRUG master;GOCREATE MASTER KEY KRYPTERING VED PASSWORD ='p@ssw0rd';GOOPEN MASTER NØGLEBESKRIVELSE MED PASSWORD ='p@ssw0rd';GOCREATE CERTIFICATE TestCert WITH SUBJECT ='EncryptionTesting';

Du får også en advarsel, hvis du forsøger at oprette en krypteret sikkerhedskopi ved hjælp af et certifikat, der ikke i sig selv er blevet sikkerhedskopieret:

Advarsel:Certifikatet, der blev brugt til at kryptere databasekrypteringsnøglen, er ikke blevet sikkerhedskopieret. Du bør straks sikkerhedskopiere certifikatet og den private nøgle, der er knyttet til certifikatet. Hvis certifikatet nogensinde bliver utilgængeligt, eller hvis du skal gendanne eller vedhæfte databasen på en anden server, skal du have sikkerhedskopier af både certifikatet og den private nøgle, ellers vil du ikke være i stand til at åbne databasen.

I mit tilfælde kunne jeg bare sikkerhedskopiere certifikatet og hovednøglen, sådan her:

BACKUP CERTIFIKAT TestCert TO FILE ='C:\temp\TestCert.cert' MED PRIVAT NØGLE ( FILE ='C:\temp\TestCert.key', KRYPTERING MED PASSWORD ='p@ssw0rd' ); BACKUP MASTER NØGLE TIL FIL ='C:\temp\MasterKey.key' KRYPTERING MED PASSWORD ='p@ssw0rd';

Strengt taget er det ikke nødvendigt at sikkerhedskopiere hovednøglen for at udføre en krypteret sikkerhedskopiering (eller endda for at undgå advarslen), men du bør sikkerhedskopiere dette alligevel. Og du vil sandsynligvis bruge en stærkere adgangskode end p@ssw0rd , gem det et andet sted end C:-drevet på den samme maskine osv. Endelig skal du være opmærksom på, at hvis du krypterer dine sikkerhedskopier, og du ikke tager alle de rigtige forholdsregler, kan de være ubrugelige i tilfælde af en katastrofe . Dette er ikke en funktion, du bare skal slå til uden en hel del flid og test.

Med alt det af vejen kunne jeg komme videre med at teste. Dette system har kun en enkelt pladebaseret disk og en enkelt SSD, så jeg kunne ikke teste SSD -> anden SSD eller HDD -> anden HDD; kun sikkerhedskopiere fra det ene til det andet eller til det samme drev. Den grundlæggende syntaks for sikkerhedskopiering med kryptering er:

BACKUP DATABASE ... MED KRYPTERING (ALGORITHM =, SERVER CERTIFICATE =);

Og de fire mulige værdier for er AES_128 , AES_192 , AES_256 og TRIPLE_DES_3KEY .

Så dernæst genererede jeg scriptet til at køre sikkerhedskopierne for at sammenligne ydeevnen og størrelsen af forskellige kombinationer – de fire forskellige krypteringsalgoritmer (og ingen kryptering), med og uden komprimering, hvor dataene kommer fra (HDD eller SSD) og hvor dataene sikkerhedskopieres til (HDD eller SSD). Det er 40 forskellige sikkerhedskopier, og scriptet, jeg brugte til at generere det, ser sådan ud: DECLARE @sql NVARCHAR(MAX) =N'';;WITH 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'),('KOMPRESSION')) 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' ANDERS 'SSD' END + ' TO DISK =''' + d + ':\backup\' + n + '.bak'' MED INIT, ' + c + ',' + COALESCE(' ENCRYPTION (ALGORITHM =' + m + ', SERVERCERTIFIKAT =TestCert),', '') + ' NAME =''' + n + ''';' FROM ( SELECT *, n ='test' + CONVERT(VARCHAR(8000), RIGHT('0' + RTRIM(r),2)) + '-' + COALESCE(m,'NO_ENCRYPTION') + '-' + TILFÆLDE NÅR r <11 SÅ 'HDD' ELLER 'SSD' END + '-to-' + t + '-' + c FRA (VÆLG *, r =ROW_NUMBER() OVER (OPDELING EFTER d.d ORDER BY s.s,m.m,c.c ) FRA s CROSS JOIN m CROSS JOIN c CROSS JOIN d ) AS x) AS y BESTILLING AF r; --EXEC sp_executesql @sql;--GO 10 VÆLG KONVERTER(XML, @sql); Ser virkelig kompliceret ud, men egentlig genererer det bare 40 BACKUP DATABASE strenge. Jeg vælger som XML, så du, når du klikker på resultaterne i gitteret, kan se hele outputtet – i stedet for hvad PRINT eller valg af output til gitter/tekst vil begrænse dig til. Outputtet er i dette tilfælde nedenfor (klik for at vise/skjule): BACKUP DATABASE awHDD TIL DISK ='D:\backup\test01-NO_ENCRYPTION-HDD-to-HDD-COMPRESSION.bak' MED INIT, KOMPRESSION, NAME ='test01-NO_ENCRYPTION-HDD-to-HDD-COMPRESSION'; BACKUP DATABASE awHDD TO DISK ='E:\backup\test01-NO_ENCRYPTION-HDD-to-SSD-COMPRESSION.bak' WITH INIT, COMPRESSION, NAME ='test01-NO_ENCRYPTION-HDD-to-SSD-COMPRESSION';BACKUP DATABASE TO DISK ='E:\backup\test02-NO_ENCRYPTION-HDD-to-SSD-NO_COMPRESSION.bak' MED 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' MED INIT, NO_COMPRESSION, NAME ='test02-NO_ENCRYPTION-HDD-to-HDD-NO_COMPRESSION';BACKUP DATABASE awHDD:TIL DISK \backup\test03-AES_128-HDD-to-HDD-COMPRESSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITME =AES_128, SERVERCERTIFIKAT =TestCert), NAVN ='test03-AES_128-HDD-til-HDD-KOMPRESSION'-; BACKUP DATABASE awHDD TIL DISK ='E:\backup\test03-AES_128-HDD-to-SSD-COMPRESSIO N.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =AES_128, SERVER CERTIFICATE =TestCert), NAME ='test03-AES_128-HDD-to-SSD-KOMPRESSION';BACKUP DATABASE awHDD TO DISK\Test04 -AES_128-HDD-to-SSD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_128, SERVER CERTIFICATE =TestCert), NAME ='test04-AES_128-HDD-to-SSD-NO_COMPRESSION TO-SSD-NO_COMPRESSH DISK ='D:\backup\test04-AES_128-HDD-to-HDD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_128, SERVER CERTIFICATE =TestCert), NAME ='test04-HDD_to-128 HDD-NO_COMPRESSION';BACKUP DATABASE awHDD TIL DISK ='D:\backup\test05-AES_192-HDD-to-HDD-COMPRESSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =AES_192, =SERVERCERTIFIKAT), 'test05-AES_192-HDD-to-HDD-COMPRESSION';BACKUP DATABASE awHDD TO DISK ='E:\backup\test05-AES_192-HDD-to-SSD-COMPRESSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =AES_192 , SERVERCERTIFIKAT =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' MED INIT, NO_COMPRESSION, ENCRY ALGORITHM =AES_192, SERVER CERTIFICATE =TestCert), NAME ='test06-AES_192-HDD-to-SSD-NO_COMPRESSION';BACKUP DATABASE awHDD TO DISK ='D:\backup\test06-AES_192-HDD-NO_COMPRESSION.NO_COMPRESSION. bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_192, SERVER CERTIFICATE =TestCert), NAME ='test06-AES_192-HDD-to-HDD-NO_COMPRESSION';BACKUP DATABASE awHDD TO DISK\_D:\backup -HDD-to-HDD-COMPRESSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test07-AES_256-HDD-to-HDD-COMPRESSION';BACKUP DATABASE DISKAW 'E:\backup\test07-AES_256-HDD-to-SSD-COMPRESSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =AES_256, SERVERCERTIFIKAT =TestCert), NAVN ='test07-AES_256-HDD-to-SS KOMPRESSION';BACKUP DATABASE awHDD TIL DISK ='E:\backup\te st08-AES_256-HDD-to-SSD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test08-AES_256-HDD-to-SSDATA DATA-BAWPRESSION'BawPRESSION; TIL DISK ='D:\backup\test08-AES_256-HDD-to-HDD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test08-AESDD_25 -HDD-NO_COMPRESSION';BACKUP DATABASE awHDD TIL DISK ='D:\backup\test09-TRIPLE_DES_3KEY-HDD-to-HDD-COMPRESSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =TRIPLE_DESSERVERCERT,CERTIFICAT, CERTIFICAT =TRIPLE_DESSER_3KERT), ='test09-TRIPLE_DES_3KEY-HDD-to-HDD-COMPRESSION';BACKUP DATABASE awHDD TO DISK ='E:\backup\test09-TRIPLE_DES_3KEY-HDD-to-SSD-COMPRESSION.bak' MED INIT, KOMPRESSION =ENCRITH 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-DDD-NO- .bak' MED INIT, NO_COMPRESSION, KRYPTION (ALGORITHM =TRIPLE_DES_3KEY, SERVER CERTIFICATE =TestCert), NAME ='test10-TRIPLE_DES_3KEY-HDD-to-SSD-NO_COMPRESSION'; 'BACKUP DATABASE DATABASE-up' TRIPLE_DES_3KEY-HDD-to-HDD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =TRIPLE_DES_3KEY, SERVER CERTIFICATE =TestCert), NAVN ='test10-TRIPLE_DES_3KEY-HDDSSION DBBATA-NO_3KEY-HDDSSION' ='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' MED INIT, NO_COMPRESSION, NAME ='test12-NO_ENCRYPTION-SSD-to-SSD-NO_COMPRESSION';BACKUP DATABASE awSSD TIL DISK ='D:\backup\backup NO_ENCRYPTION-S SD-to-HDD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, NAME ='test12-NO_ENCRYPTION-SSD-to-HDD-NO_COMPRESSION';BACKUP DATABASE awSSD TIL DISK ='D:\backup\test13-AES_128-SSD-to -HDD-COMPRESSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =AES_128, SERVER CERTIFICATE =TestCert), NAME ='test13-AES_128-SSD-to-HDD-COMPRESSION';BACKUP DATABASE ='awSSD:\DISK backup\test13-AES_128-SSD-to-SSD-COMPRESSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =AES_128, SERVER CERTIFICATE =TestCert), NAVN ='test13-AES_128-SSD-til-SSD-KOMPRESSIONEN'; DATABASE awSSD TIL DISK ='E:\backup\test14-AES_128-SSD-to-SSD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_128, SERVER CERTIFICATE =TestCert), NAME ='_1128 -to-SSD-NO_COMPRESSION';BACKUP DATABASE awSSD TIL DISK ='D:\backup\test14-AES_128-SSD-to-HDD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AESVERCERTIFICAT) , NAVN ='test14-AES_128-SSD-to-H DD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D:\backup\test15-AES_192-SSD-to-HDD-COMPRESSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =AES_192, =SERVERCERTIFIKAT), 'test15-AES_192-SSD-to-HDD-COMPRESSION';BACKUP DATABASE awSSD TO DISK ='E:\backup\test15-AES_192-SSD-to-SSD-COMPRESSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =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' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_192, SERVER CERTIFICATE =TestCert), NAME ='test16-AES_192-SSD-to-SSD-NO_COMPRESSION'; to-HDD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_192, SERVER CERTIFICATE =TestCert), NAME ='test16-AES_192-SSD-to-HDD-NO_COMPRESSION'; 'BACKUP DATA:TOBASE' \backup\test17-AES_256-SSD-to-HDD-COMPRE SSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test17-AES_256-SSD-to-HDD-KOMPRESSION';BACKUP DATABASE awSSD TO DISK ='E:\backup -AES_256-SSD-to-SSD-COMPRESSION.bak' MED INIT, KOMPRESSION, KRYPTERING (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAVN ='test17-AES_256-SSD-to-SSD-KOMPRESSION FOR AT BACKUP DATA'; DISK ='E:\backup\test18-AES_256-SSD-to-SSD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_256, SERVER CERTIFICATE =TestCert), NAME ='test18-ASSD_to256 SSD-NO_COMPRESSION';BACKUP DATABASE awSSD TIL DISK ='D:\backup\test18-AES_256-SSD-to-HDD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =AES_256), ATE SERVER CERTIFIC 'test18-AES_256-SSD-to-HDD-NO_COMPRESSION';BACKUP DATABASE awSSD TO DISK ='D:\backup\test19-TRIPLE_DES_3KEY-SSD-to-HDD-COMPRESSION.bak' MED INIT, KOMPRESSION, ENCRYPTION_3 , SERVER 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 INIT,' MED KOMPRESSION, KRYPTERING (ALGORITHM =TRIPLE_DES_3KEY, SERVER CERTIFICATE =TestCert), NAME ='test19-TRIPLE_DES_3KEY-SSD-to-SSD-KOMPRESSION';BACKUP DATABASE awSSD TIL DISK ='E:\ SSD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =TRIPLE_DES_3KEY, SERVER CERTIFICATE =TestCert), NAME ='test20-TRIPLE_DES_3KEY-SSD-to-SSD-NO_COMPRESSION DATABACKDATABACKD'; \test20-TRIPLE_DES_3KEY-SSD-to-HDD-NO_COMPRESSION.bak' MED INIT, NO_COMPRESSION, ENCRYPTION (ALGORITHM =TRIPLE_DES_3KEY, SERVER CERTIFICATE =TestCert), NAME ='test20-TRIPLE-PRESSION_COMPRESSION-NO_TEST20-TRIPLE_DES-NO; før> Jeg behøvede ikke at gøre noget særligt for at time disse, fordi jeg kunne trække alle relevante statistikker fra msdb-databasen, efter de var færdige (den eneste ulempe er, at varigheden kun måles til sekunders granularitet, medmindre jeg ville for at parse outputtet manuelt). Så jeg dekommenterede EXEC sp_executesql og GO linjer (jeg ønskede at køre hver backup 10 gange for at få gennemsnit, udelukke uregelmæssigheder osv.), trykke på F5 og gå i gang med en af mine sessioner til PASS Summit. Da jeg kom tilbage, tjekkede jeg msdb-tabellerne for at få størrelserne/varighederne for hver sikkerhedskopi. Denne forespørgsel er ret enkel: ;WITH x AS( SELECT name, natural_size =backup_size/1024/1024.0, compressed_size =compressed_backup_size/1024/1024.0, duration =1.0*DATEDIFF(SECOND, backup_start_date, backup_start_date, backup_finish_dato) WROM LIKE m.backup_dato. %')VÆLG navn, [naturlig_størrelse] =MAX(naturlig_størrelse), [komprimeret_størrelse] =MAX(komprimeret_størrelse), [min_varighed] =MIN(varighed), [maks_varighed] =MAX(varighed), [gennemsnit_varighed] =AVG(varighed) FRA x GRUPPER EFTER navnORDER BY name; Dette ville give mig de data, jeg havde brug for til at lave nogle smukke diagrammer. Indvirkning på størrelse Afhængigt af din erfaring med kryptering generelt, kan det måske ikke overraske dig, at kryptering af en databasesikkerhedskopi har meget lille indflydelse på dens samlede størrelse. Hvordan dette virker er uden for rammerne af dette indlæg, helt sikkert; en simpel forklaring ville være, at - i hvert fald med AES-kryptering - er komprimering ikke særlig effektiv på det meste af outputtet, fordi det grundlæggende er tilfældigt volapyk. Slutresultatet er, at dette diagram ikke er særlig spændende. De komprimerede og ikke-komprimerede størrelser af native backups mod de fire forskellige krypteringsmetoder: Størrelse, i MB, af sikkerhedskopier med og uden kryptering Som du kan se, var der næsten ingen indvirkning på størrelsen af databasen - omkring 0,03 % øget størrelse for en ikke-komprimeret sikkerhedskopi og yderligere 0,04 % for en komprimeret sikkerhedskopi. Påvirkning på ydeevne Selvom kryptering havde en ubetydelig indvirkning på størrelsen, gjorde det det påvirke hastigheden af sikkerhedskopieringen. Men i nogle tilfælde ikke på den måde, du tror. Her er det overordnede mål for gennemsnitlige køretider for hver tilgang: Gennemsnitlig varighed, i sekunder, af forskellige sikkerhedskopier Jeg forventede virkelig, at krypteringen altid ville forårsage et præstationshit, og du bør teste i dit miljø for at se, om dine resultater er anderledes end mine. Jeg vil vende tilbage og opdatere dette med et nyt diagram, der viser særlige tilfælde, der var overraskende for mig, og fjerne nogle afvigende værdier for at sikre, at resultaterne virkelig er repræsentative. En advarsel En vigtig note:du kan ikke tilføje krypterede sikkerhedskopier. Hvis du genererer en krypteret sikkerhedskopifil ved hjælp af WITH INIT , og prøv derefter at tilføje en anden krypteret sikkerhedskopi til den samme fil, vil du modtage denne fejlmeddelelse: Msg 3095, Level 16, State 1, Line 11 Sikkerhedskopieringen kan ikke udføres, fordi 'ENCRYPTION' blev anmodet om, efter at mediet blev formateret med en inkompatibel struktur. For at føje til dette mediesæt, skal du enten udelade 'ENCRYPTION' eller oprette et nyt mediesæt ved at bruge WITH FORMAT i din BACKUP-sætning. Hvis du bruger WITH FORMAT på et eksisterende mediesæt, vil alle dets backupsæt blive overskrevet. Besked 3013, niveau 16, tilstand 1, linje 11 BACKUP DATABASE afsluttes unormalt. Du kan til forveksling tilføje et ikke -krypteret backup, når den oprindelige fil blev krypteret. Dette er ikke hensigten, og det er en fejl, jeg har rapporteret på Connect (#805220, men den er i øjeblikket markeret som privat); forhåbentlig vil de løse dette før RTM. I mellemtiden skal du være forsigtig her, fordi intet er blevet ændret i RESTORE HEADERONLY output for at angive, om nogen af de vedlagte sikkerhedskopier var krypteret. For at opdage dette skal du tjekke BackupSetGUID værdi i det output ved Position =1 , og find den tilsvarende backup_set_uuid værdi i msdb.dbo.backupset . Denne tabel har nye kolonner til at understøtte kryptering, hvor du kan få disse oplysninger:key_algorithm , encryptor_thumbprint , og encryptor_type . Dette er problematisk i tilfælde, hvor du ikke har backupsættet data – måske er det blevet ryddet ud under vedligeholdelsesopgaver, eller måske kan du ikke få adgang til det, fordi du virkelig er ved at komme dig efter en katastrofe eller kun har .bak-filen (eller kun har .bak-filen af andre årsager). I dette tilfælde håber jeg, at der er en anden måde at se ud fra backup-filen, at den er blevet krypteret (og hvordan), men i skrivende stund kender jeg ikke til en måde. Jeg indgav et forslag (#805292, også privat) om, at outputtet af RESTORE HEADERONLY udvides med krypteringsoplysninger på samme måde, som det blev udvidet med kompressionsoplysninger, da denne funktion blev tilføjet i SQL Server 2008. Når de løser disse problemer (og jeg er overbevist om, at de vil), fjerner jeg al denne støj, men det er vigtigt at være opmærksom på dette i mellemtiden, hvis du skal udføre nogen test med nuværende CTP'er. Næste... Hvad denne type sikkerhedskopiering betyder for gendannelse, vil jeg cirkle tilbage til i et andet indlæg, når jeg tester gendannelseshastigheder og afslører eventuelle problemområder der. Jeg vil også gense disse tests for at undersøge krypterede log backups.