Opties voor cloudback-up voor MySQL- en MariaDB-databases

Het belangrijkste doel van het maken van een back-up van uw gegevens is natuurlijk de mogelijkheid om terug te draaien en toegang te krijgen tot uw archieven in geval van hardwarestoringen. Om vandaag zaken te doen, moet u de zekerheid hebben dat uw gegevens in het geval van een ramp worden beschermd en toegankelijk zijn. U zou uw back-ups offsite moeten opslaan, voor het geval uw datacenter in vlammen opgaat.

Gegevensbescherming blijft een uitdaging voor kleine en middelgrote bedrijven. Kleine tot middelgrote bedrijven geven er de voorkeur aan de gegevens van hun bedrijf te archiveren met behulp van direct-attached storage, waarbij de meeste bedrijven plannen hebben om offsite back-ups te maken. Lokale opslagbenadering kan leiden tot een van de ernstigste dilemma's waarmee het moderne bedrijf kan worden geconfronteerd:gegevensverlies in geval van een ramp.

Veel factoren spelen een rol bij het beoordelen of een bedrijfskritieke database naar een andere locatie mag worden overgebracht, en bij het kiezen van een geschikte leverancier om dit te doen. Traditionele methoden, zoals het schrijven naar tape en verzenden naar een externe locatie, kunnen een gecompliceerd proces zijn waarvoor speciale hardware, adequaat opgeleid personeel en procedures nodig zijn om ervoor te zorgen dat back-ups regelmatig worden gemaakt en beschermd en dat de informatie erop wordt gecontroleerd op integriteit. Kleine bedrijven hebben meestal kleine IT-budgetten. Vaak kunnen ze het zich niet veroorloven om een ​​secundair datacenter te hebben, zelfs niet als ze een dedicated datacenter hebben. Maar toch is het nog steeds belangrijk om een ​​kopie van uw back-upbestanden offsite te bewaren. Rampen zoals orkaan, overstroming, brand of diefstal kunnen uw servers en opslag vernietigen. Door een back-up van gegevens in het afzonderlijke datacenter te bewaren, zijn de gegevens veilig, wat er ook gebeurt in uw primaire datacenter. Cloudopslag is een geweldige manier om dit probleem aan te pakken.
Bij de cloudback-upbenadering zijn er een aantal factoren waarmee u rekening moet houden. Enkele van de vragen die u heeft zijn:

• Zijn back-upgegevens beveiligd in het externe datacenter?
• Is overdracht van of naar het externe datacenter via het openbare internetnetwerk veilig?
• Is er een effect op RTO (Recovery Time Objective)?
• Is het back-up- en herstelproces eenvoudig genoeg voor ons IT-personeel?
• Zijn er wijzigingen nodig in bestaande processen?
• Zijn back-uptools van derden nodig?
• Wat zijn de extra kosten in termen van benodigde software of gegevensoverdracht?
• Wat zijn de opslagkosten?

Back-upfuncties bij het maken van een back-up naar de cloud

Als uw MySQL-server of back-upbestemming zich in een blootgestelde infrastructuur zoals een openbare cloud, hostingprovider of verbonden via een niet-vertrouwd WAN-netwerk bevindt, moet u nadenken over aanvullende acties in uw back-upbeleid. Er zijn weinig verschillende manieren om databaseback-ups voor MySQL uit te voeren, en afhankelijk van het type back-up, zullen de hersteltijd, grootte en infrastructuuropties variëren. Aangezien veel van de cloudopslagoplossingen eenvoudigweg opslag zijn met verschillende API-frontends, kan elke back-upoplossing worden uitgevoerd met een beetje scripting. Dus wat zijn de opties die we hebben om het proces soepel en veilig te laten verlopen?

Encryptie

Het is altijd een goed idee om codering af te dwingen om de beveiliging van back-upgegevens te verbeteren. Een eenvoudig gebruiksscenario om versleuteling te implementeren, is waar u de back-up naar een externe back-upopslag in de openbare cloud wilt pushen.

Wanneer u een versleutelde back-up maakt, moet u er rekening mee houden dat het meestal meer tijd kost om te herstellen. De back-up moet worden gedecodeerd voordat herstelactiviteiten worden uitgevoerd. Met een grote dataset kan dit enige vertraging opleveren voor de RTO.

Aan de andere kant, als u een privésleutel gebruikt voor codering, zorg er dan voor dat u de sleutel op een veilige plaats bewaart. Als de privésleutel ontbreekt, is de back-up nutteloos en onherstelbaar. Als de sleutel wordt gestolen, worden alle gemaakte back-ups die dezelfde sleutel gebruiken in gevaar gebracht omdat ze niet langer beveiligd zijn. U kunt de populaire GnuPG of OpenSSL gebruiken om de privé- of openbare sleutels te genereren.
Als u mysqldump-codering wilt uitvoeren met GnuPG, genereert u een privésleutel en volgt u de wizard dienovereenkomstig:

$ gpg --gen-key

Maak zoals gewoonlijk een gewone mysqldump-back-up:

$ mysqldump --routines --events --triggers --single-transaction db1 | gzip > db1.tar.gz

Versleutel het dumpbestand en verwijder de oudere gewone back-up:

$ gpg --encrypt -r ‘[email protected]’ db1.tar.gz
$ rm -f db1.tar.gz

GnuPG voegt automatisch de .gpg-extensie toe aan het versleutelde bestand. Om te decoderen,
voer je gewoon het gpg-commando uit met --decrypt flag:

$ gpg --output db1.tar.gz --decrypt db1.tar.gz.gpg

Om een ​​versleutelde mysqldump te maken met OpenSSL, moet men een privésleutel en een openbare sleutel genereren:
OpenSSL req -x509 -nodes -newkey rsa:2048 -keyout dump.priv.pem -out dump.pub.pem

Deze privésleutel (dump.priv.pem) moet op een veilige plaats worden bewaard voor toekomstige decodering. Voor mysqldump kan een versleutelde back-up worden gemaakt door de inhoud bijvoorbeeld naar openssl te pipen

mysqldump --routines --events --triggers --single-transaction database | openssl smime -encrypt -binary -text -aes256
-out database.sql.enc -outform DER dump.pub.pem

Om te decoderen, gebruikt u gewoon de privésleutel (dump.priv.pem) naast de vlag -decrypt:
openssl smime -decrypt -in database.sql.enc -binary -inform

DEM -inkey dump.priv.pem -out database.sql

Percona XtraBackup kan worden gebruikt om lokale of streaming-back-ups te versleutelen of te ontsleutelen met de xbstream-optie om een ​​extra beveiligingslaag aan de back-ups toe te voegen. Versleuteling gebeurt met de libgcrypt-bibliotheek. Zowel de optie --encrypt-key als --encryptkey-file kunnen worden gebruikt om de encryptiesleutel op te geven. Versleutelingssleutels kunnen worden gegenereerd met opdrachten zoals

$ openssl rand -base64 24
$ bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1

Deze waarde kan vervolgens worden gebruikt als de coderingssleutel. Voorbeeld van het innobackupex-commando met de --encrypt-key:

$ innobackupex --encrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1” /storage/backups/encrypted

De uitvoer van het bovenstaande OpenSSL-commando kan ook worden omgeleid naar een bestand en kan worden behandeld als een sleutelbestand:

openssl rand -base64 24 > /etc/keys/pxb.key

Gebruik het in plaats daarvan met de --encrypt-key-file optie:

innobackupex --encrypt=AES256 --encrypt-key-file=/etc/keys/pxb.key /storage/backups/encrypted

Om te decoderen, gebruik je gewoon de --decrypt optie met de juiste --encrypt-key of --encrypt-key-file:

$ innobackupex --decrypt=AES256 --encrypt-key=”bWuYY6FxIPp3Vg5EDWAxoXlmEFqxUqz1”
/storage/backups/encrypted/2018-11-18_11-10-09/

Raadpleeg onze andere blogpost voor meer informatie over MySQL- en MariaDB-codering.

Compressie

Binnen de wereld van database-cloudback-up is compressie een van je beste vrienden. Het kan niet alleen opslagruimte besparen, maar het kan ook de tijd die nodig is om gegevens te downloaden/uploaden aanzienlijk verkorten.
Er zijn veel compressietools beschikbaar, namelijk gzip, bzip2, zip, rar en 7z.
Normaal gesproken kan mysqldump de beste compressiesnelheden hebben omdat het een plat tekstbestand is. Afhankelijk van de compressietool en -verhouding kan een gecomprimeerde mysqldump tot 6 keer kleiner zijn dan de oorspronkelijke back-upgrootte. Om de back-up te comprimeren, kunt u de uitvoer van mysqldump naar een compressietool sturen en deze omleiden naar een doelbestand. U kunt ook verschillende dingen overslaan, zoals opmerkingen, tabellen vergrendelen (indien InnoDB), GTID-opgeruimd en triggers overslaan:

mysqldump --single-transaction --skip-comments --skip-triggers --skip-lock-tables --set-gtid-purged OFF --all-databases | gzip > /storage/backups/all-databases.sql.gz

Met Percona Xtrabackup kunt u de streamingmodus (innobackupex) gebruiken, die de back-up naar STDOUT stuurt in een speciaal tar- of xbstream-formaat in plaats van bestanden naar de back-upmap te kopiëren. Met een gecomprimeerde back-up kunt u tot 50% van de oorspronkelijke back-upgrootte besparen, afhankelijk van de dataset. Voeg de --compress optie toe aan het backup commando. Door de xbstream te gebruiken bij het streamen van back-ups, kunt u het compressieproces versnellen door de optie --compress-threads te gebruiken. Deze optie specificeert het aantal threads dat door xtrabackup is gemaakt voor parallelle gegevenscompressie. De standaardwaarde voor deze optie is 1. Om deze functie te gebruiken, voegt u de optie toe aan een lokale back-up. Een voorbeeld van een back-up met compressie:

innobackupex --stream=xbstream --compress --compress-threads=4 > /storage/backups/backup.xbstream

Voordat u logs toepast tijdens de voorbereidingsfase, moeten gecomprimeerde bestanden worden
gedecomprimeerd met xbstream:
Gebruik vervolgens qpress om elk bestand dat eindigt op .qp uit te pakken in hun respectievelijke directory voordat
uitgevoerd wordt -- Apply-log commando om de MySQL-gegevens voor te bereiden.

$ xbstream -x < /storage/backups/backup.xbstream

Beperk netwerkdoorvoer

Een goede optie voor back-ups in de cloud is om de bandbreedte voor netwerkstreaming (Mb/s) te beperken bij het maken van een back-up. U kunt dat bereiken met pv-tool. Het pv-hulpprogramma wordt geleverd met de optie voor gegevensmodificaties -L RATE, --rate-limit RATE die de overdracht beperken tot een maximum van RATE-bytes per seconde. Het onderstaande voorbeeld beperkt het tot 2 MB/s.

$ pv -q -L 2m

In onderstaand voorbeeld ziet u xtrabackup met parallelle gzip, encryptie

 /usr/bin/innobackupex --defaults-file=/etc/mysql/my.cnf --galera-info --parallel 4 --stream=xbstream --no-timestamp . | pv -q -L 2m | pigz -9 - | openssl enc -aes-256-cbc -pass file:/var/tmp/cmon-008688-19992-72450efc3b6e9e4f.tmp > /home/ubuntu/backups/BACKUP-3445/backup-full-2018-11-28_213540.xbstream.gz.aes256 ) 2>&1.

Back-up overzetten naar cloud

Wanneer uw back-up nu is gecomprimeerd en versleuteld, is deze klaar voor overdracht.

Google-cloud

De gsutil-opdrachtregeltool wordt gebruikt om uw opslagbuckets op Google Cloud Storage te beheren, controleren en gebruiken. Als je de gcloud-util al hebt geïnstalleerd, heb je de gsutil al geïnstalleerd. Volg anders de instructies voor uw Linux-distributie vanaf hier.

Om de gcloud CLI te installeren, volgt u onderstaande procedure:

curl https://sdk.cloud.google.com | bash

Herstart je shell:

exec -l $SHELL

Voer gcloud init uit om de gcloud-omgeving te initialiseren:

gcloud init

Met de gsutil-opdrachtregeltool geïnstalleerd en geverifieerd, maakt u een regionale opslagbucket met de naam mysql-backups-storage in uw huidige project.

gsutil mb -c regional -l europe-west1 gs://severalnines-storage/
Creating gs://mysql-backups-storage/

Amazon S3

Als u geen RDS gebruikt om uw databases te hosten, is het zeer waarschijnlijk dat u uw eigen back-ups maakt. Amazon's AWS-platform, S3 (Amazon Simple Storage Service) is een gegevensopslagservice die kan worden gebruikt om databaseback-ups of andere bedrijfskritieke bestanden op te slaan. Of het nu een Amazon EC2-instantie is of uw lokale omgeving, u kunt de service gebruiken om uw gegevens te beveiligen.

Hoewel back-ups kunnen worden geüpload via de webinterface, kan de speciale s3-opdrachtregelinterface worden gebruikt om dit te doen vanaf de opdrachtregel en via back-upautomatiseringsscripts. Als back-ups heel lang moeten worden bewaard en de hersteltijd geen probleem is, kunnen back-ups worden overgebracht naar de Amazon Glacier-service, wat een veel goedkopere langetermijnopslag oplevert. Bestanden (amazon-objecten) worden logisch opgeslagen in een enorme platte container met de naam bucket. S3 presenteert een REST-interface aan zijn internals. U kunt deze API gebruiken om CRUD-bewerkingen op buckets en objecten uit te voeren en om machtigingen en configuraties voor beide te wijzigen.

De primaire distributiemethode voor de AWS CLI op Linux, Windows en macOS is pip, een pakketbeheerder voor Python. Instructies zijn hier te vinden.

aws s3 cp severalnines.sql s3://severalnine-sbucket/mysql_backups

Standaard biedt S3 elf 9s objectduurzaamheid. Het betekent dat als je er 1.000.000.000 (1 miljard) objecten in opslaat, je kunt verwachten dat je gemiddeld elke 10 jaar 1 object verliest. De manier waarop S3 dat indrukwekkende aantal 9s behaalt, is door het object automatisch te repliceren in meerdere beschikbaarheidszones, waarover we in een ander bericht zullen praten. Amazon heeft regionale datacenters over de hele wereld.

Microsoft Azure-opslag

Het openbare cloudplatform van Microsoft, Azure, heeft opslagopties met hun besturingslijninterface. Informatie is hier te vinden. De open-source, platformonafhankelijke Azure CLI biedt een set opdrachten voor het werken met het Azure-platform. Het biedt veel van de functionaliteit van de Azure-portal, inclusief uitgebreide gegevenstoegang.

De installatie van Azure CLI is vrij eenvoudig, instructies vind je hier. Hieronder vindt u hoe u uw back-up kunt overbrengen naar Microsoft-opslag.

az storage blob upload --container-name severalnines --file severalnines.sql --name severalnines_backup

Hybride opslag voor MySQL- en MariaDB-back-ups

Met de groeiende publieke en private cloudopslagindustrie hebben we een nieuwe categorie genaamd hybride opslag. Met deze technologie kunnen de bestanden lokaal worden opgeslagen, waarbij wijzigingen automatisch worden gesynchroniseerd met remote in de cloud. Een dergelijke benadering komt voort uit de behoefte om recente back-ups lokaal te bewaren voor snel herstel (lagere RTO), evenals voor bedrijfscontinuïteitsdoelstellingen.
Het belangrijkste aspect van efficiënt gebruik van bronnen is om afzonderlijke back-upretenties te hebben. Gegevens die lokaal op redundante schijven worden opgeslagen, worden voor een kortere periode bewaard, terwijl back-upopslag in de cloud langer wordt bewaard. Vaak komt de vereiste voor een langere bewaring van back-ups voort uit wettelijke verplichtingen voor verschillende industrieën (zoals telecom die metadata van verbindingen moet opslaan). Cloudproviders zoals Google Cloud Services, Microsoft Azure en Amazon S3 bieden elk vrijwel onbeperkte opslag, waardoor er minder lokale ruimte nodig is. Hiermee kunt u uw back-upbestanden langer bewaren, zo lang als u wilt en hoeft u zich geen zorgen te maken over de lokale schijfruimte.

Bij het plannen van een back-up met ClusterControl, kan elk van de back-upmethoden worden geconfigureerd met een reeks opties voor hoe u wilt dat de back-up wordt uitgevoerd. Het belangrijkste voor de hybride cloudopslag zou zijn:

• Netwerkbeperking
• Encryptie met het ingebouwde sleutelbeheer
• Compressie
• Bewaarperiode voor de lokale back-ups
• Bewaarperiode voor de cloudback-ups

Conclusie

De cloud heeft de databack-upindustrie veranderd. Vanwege de betaalbare prijs hebben kleinere bedrijven een externe oplossing die een back-up van al hun gegevens maakt.

Uw bedrijf kan profiteren van de schaalbaarheid van de cloud en betalen per gebruik voor de groeiende opslagbehoeften. U kunt een back-upstrategie ontwerpen om zowel lokale kopieën in het datacenter te bieden voor onmiddellijk herstel, als een naadloze toegangspoort tot cloudopslagservices van AWS, Google en Azure.

Geavanceerde TLS- en AES 256-bits encryptie- en compressiefuncties ondersteunen veilige back-ups die aanzienlijk minder ruimte innemen in de cloud.