Hoe maak je een back-up van een versleutelde database met Percona Server voor MySQL 8.0

Productieonderbrekingen zullen vrijwel zeker op een bepaald moment plaatsvinden. We weten het, dus we plannen back-ups, creëren standby-databases voor herstel en zetten afzonderlijke instanties om in clusters.

Toen we de noodzaak van een goed herstelscenario erkennen, moeten we de mogelijke rampentijdlijn en faalscenario's analyseren en stappen implementeren om uw database op de hoogte te brengen. Geplande uitvoering van een storing kan helpen bij het voorbereiden, diagnosticeren en herstellen van de volgende. Om de impact van uitvaltijd te beperken, hebben organisaties een geschikt herstelplan nodig, dat alle factoren omvat die nodig zijn om service tot leven te brengen.

Back-upbeheer is niet zo mild als het plannen van een back-uptaak. Er zijn veel factoren waarmee u rekening moet houden, zoals retentie, opslag, verificatie, en of de back-ups die u maakt fysiek of logisch zijn en wat gemakkelijk over het hoofd wordt gezien als beveiliging.

Veel organisaties verschillen in hun benadering van back-ups en proberen een combinatie van back-ups van serverimages (snapshots), logische en fysieke back-ups op meerdere locaties te bewaren. Het is bedoeld om lokale of regionale rampen te voorkomen die onze databases en back-ups die in hetzelfde datacenter zijn opgeslagen, zouden wissen.

We willen het veilig maken. Gegevens en back-ups moeten worden versleuteld. Maar er zijn veel implicaties wanneer beide opties aanwezig zijn. In dit artikel zullen we de back-upprocedures bekijken wanneer we te maken hebben met versleutelde databases.

Encryption-at-rest voor Percona Server voor MySQL 8.0

Vanaf MySQL 5.7.11, begon de communityversie van MySQL met ondersteuning voor InnoDB-tabelruimteversleuteling. Het wordt Transparent Tablespace Encryption genoemd of wordt Encryption-at-Rest genoemd.

Het belangrijkste verschil met de enterprise-versie is de manier waarop de sleutels worden opgeslagen - sleutels bevinden zich niet in een veilige kluis, wat vereist is voor naleving van de regelgeving. Hetzelfde geldt voor Percona Server, vanaf versie 5.7.11, is het mogelijk om InnoDB-tabelruimte te versleutelen. In de Percona Server 8.0 is de ondersteuning voor het versleutelen van binaire logs sterk uitgebreid. Versie 8.0 toegevoegd 

(Percona 8.0 releasedocument):

• Tijdelijke bestandscodering
• InnoDB versleuteling van tabelruimte ongedaan maken
• InnoDB System Tablespace Encryption (InnoDB System Tablespace Encryption)
• default_table_encryption  =OFF/ON (Algemene Tablespace Encryption)
• table_encryption_privilege_check =OFF/ON (De versleutelingsinstellingen controleren)
• InnoDB log-versleuteling opnieuw (alleen voor hoofdsleutelversleuteling) (Logboekversleuteling opnieuw uitvoeren)
• InnoDB-samenvoegbestandsversleuteling (verificatie van de versleutelingsinstelling)
• Percona Parallel doublewrite bufferversleuteling (InnoDB Tablespace Encryption)

Voor diegenen die geïnteresseerd zijn in migratie van de MySQL Enterprise-versie naar Percona:het is ook mogelijk om te integreren met de Hashicorp Vault-server via een keyring_vault-plug-in, die overeenkomt met de functies die beschikbaar zijn in de MySQL Enterprise-editie van Oracle.

Versleuteling van gegevens in rust vereist een plug-in voor sleutelhangers. Er zijn hier twee opties:

• keyring_file - een plat bestand met een coderingssleutel
• Keyring Vault-plug-in  - een service

Tablespace-codering inschakelen

Om codering in te schakelen, start u uw database met de optie --early-plugin-load:

ofwel met de hand:

$ mysqld --early-plugin-load="keyring_file=keyring_file.so"

of door het configuratiebestand te wijzigen:

[mysqld]

early-plugin-load=keyring_file.so

Vanaf Percona Server 8.0 kunnen twee typen tabelruimten worden versleuteld. Algemene tabelruimte en systeemtabelruimte. Sys tablespace wordt bestuurd via parameter innodb_sys_tablespace_encrypt. Standaard is de sys-tabelruimte niet versleuteld, en als je er al een hebt, is het niet mogelijk om deze naar een versleutelde staat te converteren. Er moet een nieuwe instantie worden gemaakt (start een instantie met de optie --bootstrap).

Algemene tabelruimte ondersteunt encryptie van alle tabellen in tabelruimte of geen. Het is niet mogelijk om versleuteling in gemengde modus uit te voeren. Gebruik de vlag ENCRYPTION='Y/N' om een ​​ate tablespace met encryptie te creëren.

Voorbeeld:

mysql> CREATE TABLESPACE severalnines ADD DATAFILE 'severalnines.ibd' ENCRYPTION='Y';

Back-up maken van een versleutelde database

Als je versleutelde tabelruimten toevoegt, is het noodzakelijk om het sleutelringbestand op te nemen in het xtrabackup-commando. Om dit te doen, moet u het pad naar een sleutelhangerbestand specificeren als de waarde van de optie --keyring-file-data.

$ xtrabackup --backup --target-dir=/u01/mysql/data/backup/ --user=root --keyring-file-data=/u01/secure_location/keyring_file

Zorg ervoor dat u het sleutelringbestand op een veilige locatie opslaat. Zorg er ook voor dat u altijd een back-up van het bestand hebt. Xtrabackup kopieert het sleutelringbestand niet naar de back-upmap. Om de back-up voor te bereiden, moet u zelf een kopie van het sleutelhangerbestand maken.

De back-up voorbereiden

Zodra we ons back-upbestand hebben, moeten we het voorbereiden voor herstel. Hier moet u ook de keyring-file-data specificeren.

$ xtrabackup --prepare --target-dir=/u01/mysql/data/backup/ --keyring-file-data=/u01/secure_location/keyring_file

De back-up is nu voorbereid en kan worden hersteld met de optie --copy-back. In het geval dat de sleutelhanger is gedraaid, moet u de sleutelhanger herstellen (die werd gebruikt om de back-up te maken en voor te bereiden).

Om de back-up xtrabackup voor te bereiden, hebben we toegang nodig tot de sleutelhanger. Xtrabackup praat niet rechtstreeks met de MySQL-server en leest het standaard my.cnf-configuratiebestand niet tijdens het voorbereiden, specificeer de sleutelringinstellingen via de opdrachtregel:

$ xtrabackup --prepare --target-dir=/data/backup --keyring-vault-config=/etc/vault.cnf

De back-up is nu voorbereid en kan worden hersteld met de optie --copy-back:

$ xtrabackup --copy-back --target-dir=/u01/backup/ --datadir=/u01/mysql/data/

Incrementele back-ups uitvoeren

Het proces van het maken van incrementele back-ups met InnoDB-tabelruimteversleuteling is vergelijkbaar met het nemen van dezelfde incrementele back-ups met een niet-versleutelde tabelruimte.

Om een ​​incrementele back-up te maken, begint u met een volledige back-up. Het binaire bestand xtrabackup schrijft een bestand met de naam xtrabackup_checkpoints naar de doelmap van de back-up. Dit bestand bevat een regel met de to_lsn, de LSN van de database aan het einde van de back-up.

Eerst moet u een volledige back-up maken met het volgende commando:

$ xtrabackup --backup --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

Nu je een volledige back-up hebt, kun je op basis daarvan een incrementele back-up maken. Gebruik een commando zoals het volgende:

$ xtrabackup --backup --target-dir=/data/backups/inc1 \

--incremental-basedir=/data/backups/base \

--keyring-file-data=/var/lib/mysql-keyring/keyring

De map /data/backups/inc1/ zou nu deltabestanden moeten bevatten, zoals ibdata1.delta en test/table1.ibd.delta.

De betekenis zou vanzelfsprekend moeten zijn. Het is nu mogelijk om deze map te gebruiken als basis voor nog een incrementele back-up:

$ xtrabackup --backup --target-dir=/data/backups/inc2 \

--incremental-basedir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Incrementele back-ups voorbereiden

Tot nu toe is het proces van het maken van een back-up van de database vergelijkbaar met een normale back-up, behalve de vlag waar we de locatie van het sleutelringbestand hebben opgegeven.

Helaas is de stap --prepare voor incrementele back-ups niet hetzelfde als voor normale back-ups.

Bij normale back-ups worden twee soorten bewerkingen uitgevoerd om de database consistent te maken:vastgelegde transacties worden opnieuw afgespeeld vanuit het logbestand tegen de gegevensbestanden en niet-vastgelegde transacties worden teruggedraaid. U moet het terugdraaien van niet-vastgelegde transacties overslaan bij het voorbereiden van een back-up, omdat transacties die niet zijn vastgelegd op het moment van uw back-up mogelijk in uitvoering zijn en het waarschijnlijk is dat ze zullen worden vastgelegd in de volgende incrementele back-up. U moet de optie --apply-log-only gebruiken om de terugdraaifase te voorkomen.

Als je de optie --apply-log-only niet gebruikt om de terugdraaifase te voorkomen, dan zijn je incrementele back-ups nutteloos. Nadat transacties zijn teruggedraaid, kunnen geen verdere incrementele back-ups worden toegepast.

Begin met de volledige back-up die je hebt gemaakt, kun je deze voorbereiden en vervolgens de incrementele verschillen erop toepassen. Bedenk dat je de volgende back-ups hebt:

/data/backups/base

/data/backups/inc1

/data/backups/inc2

Om de basisback-up voor te bereiden, moet u --prepare uitvoeren zoals gewoonlijk, maar de rollback-fase voorkomen:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

Om de eerste incrementele back-up toe te passen op de volledige back-up, moet u de volgende opdracht gebruiken:

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

als de sleutelhanger is gedraaid tussen de basis en de incrementele back-up, moet u de sleutelhanger gebruiken die in gebruik was toen de eerste incrementele back-up werd gemaakt.

Het voorbereiden van de tweede incrementele back-up is een soortgelijk proces

$ xtrabackup --prepare --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc2 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Opmerking; --apply-log-only zou gebruikt moeten worden bij het samenvoegen van alle incrementals behalve de laatste. Daarom bevat de vorige regel niet de optie --apply-log-only. Zelfs als de --apply-log-only werd gebruikt bij de laatste stap, zou de back-up nog steeds consistent zijn, maar in dat geval zou de server de rollback-fase uitvoeren.
De laatste stap is om deze te herstellen met --copy-back optie. Als de sleutelhanger is gedraaid, moet je de sleutelhanger herstellen die is gebruikt om de back-up te maken en voor te bereiden.

Hoewel de beschreven herstelmethode werkt, vereist deze toegang tot dezelfde sleutelring die de server gebruikt. Het kan zijn dat het niet mogelijk is als de back-up wordt gemaakt op een andere server of op een veel later tijdstip, wanneer sleutels in de sleutelhanger worden gewist, of, in het geval van een storing, wanneer de sleutelringkluisserver helemaal niet beschikbaar is.

De optie --transition-key= moet worden gebruikt om xtrabackup in staat te stellen de back-up te verwerken zonder toegang tot de keyring-kluisserver. In dit geval leidt xtrabackup de AES-coderingssleutel af van de opgegeven wachtwoordzin en gebruikt deze om de tabelruimtesleutels te coderen van de tabelruimten waarvan een back-up wordt gemaakt.

Een back-up maken met een wachtwoordzin

Het volgende voorbeeld illustreert hoe de back-up in dit geval kan worden gemaakt:

$ xtrabackup --backup --user=root -p --target-dir=/data/backup \

--transition-key=MySecetKey

De back-up herstellen met een gegenereerde sleutel

Bij het terugzetten van een back-up moet u een nieuwe hoofdsleutel genereren. Hier is het voorbeeld voor keyring_file:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-file-data=/var/lib/mysql-keyring/keyring

In het geval van keyring_vault, ziet het er als volgt uit:

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-vault-config=/etc/vault.cnf