Back-up en herstel in Azure Database for MariaDB

  • Artikel

Belangrijk

Azure Database for MariaDB bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan om te migreren naar Azure Database for MySQL. Zie Wat gebeurt er met Azure Database for MariaDB voor meer informatie over migreren naar Azure Database for MySQL.

In Azure Database for MariaDB worden automatisch serverback-ups gemaakt en opgeslagen in lokaal redundante of geografisch redundante opslag. Back-ups kunnen worden gebruikt om de status van de server naar een bepaald tijdstip te herstellen. Back-ups maken en herstellen zijn essentiële onderdelen van een strategie voor bedrijfscontinuïteit omdat ze uw gegevens beschermen tegen onbedoelde beschadiging of verwijdering.

Back-ups

Azure Database for MariaDB maakt back-ups van de gegevensbestanden en het transactielogboek. Met deze back-ups kunt u een server herstellen naar een bepaald tijdstip binnen de geconfigureerde bewaarperiode voor back-ups. De standaardretentieperiode voor back-ups is zeven dagen. U kunt deze desgewenst tot 35 dagen configureren. Alle back-ups worden versleuteld met AES 256-bits versleuteling.

Deze back-upbestanden worden niet door de gebruiker blootgesteld en kunnen niet worden geëxporteerd. Deze back-ups kunnen alleen worden gebruikt voor herstelbewerkingen in Azure Database for MariaDB. U kunt mysqldump gebruiken om een database te kopiëren.

Het back-uptype en de frequentie zijn afhankelijk van de back-endopslag voor de servers.

Back-uptype en frequentie

Standaardopslagservers

De Basic-opslag is de back-endopslag die servers in de Basic-laag ondersteunt. Back-ups op Basic-opslagservers zijn gebaseerd op momentopnamen. Er wordt dagelijks een volledige momentopname van de database uitgevoerd. Er zijn geen differentiële back-ups uitgevoerd voor basisopslagservers en alle momentopnameback-ups zijn alleen volledige databaseback-ups.

Back-ups van transactielogboeken worden elke vijf minuten uitgevoerd.

Opslagservers voor algemeen gebruik met maximaal 4 TB opslag

De opslag voor algemeen gebruik is de back-endopslag die de server algemeen gebruik en geoptimaliseerd voor geheugen ondersteunt. Voor servers met opslag voor algemeen gebruik tot 4 TB vindt elke week volledige back-ups plaats. Differentiële back-ups vinden twee keer per dag plaats. Back-ups van transactielogboeken worden elke vijf minuten uitgevoerd. De back-ups voor opslag voor algemeen gebruik tot 4 TB-opslag zijn niet gebaseerd op momentopnamen en verbruiken I/O-bandbreedte op het moment van de back-up. Voor grote databases (> 1 TB) op 4 TB-opslag raden we u aan te overwegen

  • Meer IOPS inrichten voor account voor back-up-IOs OF
  • U kunt ook migreren naar opslag voor algemeen gebruik die ondersteuning biedt voor maximaal 16 TB-opslag als de onderliggende opslaginfrastructuur beschikbaar is in uw Favoriete Azure-regio's. Er zijn geen extra kosten verbonden aan opslag voor algemeen gebruik die ondersteuning biedt voor maximaal 16 TB opslagruimte. Voor hulp bij migratie naar 16 TB-opslag opent u een ondersteuningsticket vanuit De Azure-portal.

Opslagservers voor algemeen gebruik met maximaal 16 TB opslag

In een subset van Azure-regio's kunnen alle nieuw ingerichte servers opslag voor algemeen gebruik tot 16 TB-opslag ondersteunen. Met andere woorden, opslag tot 16 TB opslag is de standaardopslag voor algemeen gebruik voor alle regio's waar deze wordt ondersteund. Back-ups op deze opslagservers van 16 TB zijn gebaseerd op momentopnamen. De eerste volledige momentopnameback-up wordt gepland direct nadat een server is gemaakt. Deze eerste volledige momentopnameback-up wordt bewaard als de basisback-up van de server. Volgende momentopnameback-ups zijn alleen differentiële back-ups.

Differentiële momentopnameback-ups worden minstens één keer per dag uitgevoerd. Back-ups van differentiële momentopnamen worden niet volgens een vast schema uitgevoerd. Differentiële momentopnameback-ups worden elke 24 uur uitgevoerd, tenzij het transactielogboek (binlog in MariaDB) hoger is dan 50 GB sinds de laatste differentiële back-up. Op één dag zijn maximaal zes differentiële momentopnamen toegestaan.

Back-ups van transactielogboeken worden elke vijf minuten uitgevoerd.

Back-upretentie

Back-ups worden bewaard op basis van de instelling voor de bewaarperiode voor back-ups op de server. U kunt een bewaarperiode van 7 tot 35 dagen selecteren. De standaardretentieperiode is zeven dagen. U kunt de bewaarperiode instellen tijdens het maken van de server of later door de back-upconfiguratie bij te werken met behulp van Azure Portal of Azure CLI.

De bewaarperiode voor back-ups bepaalt hoe ver terug in de tijd een herstel naar een bepaald tijdstip kan worden opgehaald, omdat deze is gebaseerd op beschikbare back-ups. De bewaarperiode voor back-ups kan ook worden behandeld als een herstelvenster vanuit het perspectief van herstel. Alle back-ups die nodig zijn om een herstel naar een bepaald tijdstip in de bewaarperiode voor back-ups uit te voeren, worden bewaard in de back-upopslag. Als de bewaarperiode voor back-ups bijvoorbeeld is ingesteld op zeven dagen, wordt het herstelvenster beschouwd als afgelopen zeven dagen. In dit scenario worden alle back-ups die nodig zijn om de server in de afgelopen zeven dagen te herstellen bewaard. Met een bewaarperiode voor back-ups van zeven dagen:

  • Servers met maximaal 4 TB-opslag behouden maximaal twee volledige databaseback-ups, alle differentiële back-ups en back-ups van transactielogboeken die zijn uitgevoerd sinds de vroegste volledige databaseback-up.
  • Servers met maximaal 16 TB-opslag behouden de volledige momentopname van de database, alle differentiële momentopnamen en back-ups van transactielogboeken in de afgelopen acht dagen.

Langetermijnretentie van back-ups

Langetermijnretentie van back-ups van meer dan 35 dagen wordt momenteel nog niet door de service ondersteund. U hebt een optie om mysqldump te gebruiken om back-ups te maken en op te slaan voor langetermijnretentie. Ons ondersteuningsteam heeft een stapsgewijs artikel geregistreerd om te delen hoe u dit kunt bereiken.

Redundantieopties voor back-up

Azure Database for MariaDB biedt de flexibiliteit om te kiezen tussen lokaal redundante of geografisch redundante back-upopslag in de lagen Algemeen gebruik en Geoptimaliseerd voor geheugen. Wanneer de back-ups worden opgeslagen in geografisch redundante back-upopslag, worden ze niet alleen opgeslagen in de regio waarin uw server wordt gehost, maar worden ze ook gerepliceerd naar een gekoppeld datacenter. Dit biedt betere beveiliging en de mogelijkheid om uw server in een andere regio te herstellen in een noodgeval. De Basic-laag biedt alleen lokaal redundante back-upopslag.

Overstappen van lokaal redundante back-upopslag naar geografisch redundante back-upopslag

Het configureren van lokaal redundante of geografisch redundante opslag voor back-up is alleen toegestaan tijdens het maken van een server. Nadat de server is ingericht, kunt u de optie voor redundantie van back-upopslag niet meer wijzigen. Als u uw back-upopslag wilt verplaatsen van lokaal redundante opslag naar geografisch redundante opslag, is het maken van een nieuwe server en het migreren van de gegevens met behulp van dump en herstel de enige ondersteunde optie.

Kosten van back-upopslag

Azure Database for MariaDB biedt maximaal 100% van uw ingerichte serveropslag als back-upopslag zonder extra kosten. Eventuele extra gebruikte back-upopslag wordt in GB per maand in rekening gebracht. Als u bijvoorbeeld een server hebt ingericht met 250 GB opslagruimte, hebt u 250 GB extra opslagruimte beschikbaar voor serverback-ups zonder extra kosten. Opslag die wordt verbruikt voor back-ups van meer dan 250 GB, wordt in rekening gebracht volgens het prijsmodel.

U kunt de metrische gegevens van Backup Storage gebruiken in Azure Monitor die beschikbaar zijn via Azure Portal om de back-upopslag te bewaken die door een server wordt verbruikt. De metrische gegevens back-upopslag die wordt gebruikt, vertegenwoordigt de som van de opslag die wordt gebruikt door alle volledige databaseback-ups, differentiële back-ups en logboekback-ups die worden bewaard op basis van de bewaarperiode voor back-ups die zijn ingesteld voor de server. De frequentie van de back-ups wordt beheerd door de service en wordt eerder uitgelegd. Intensieve transactionele activiteit op de server kan ertoe leiden dat het gebruik van back-upopslag toeneemt, onafhankelijk van de totale databasegrootte. Voor geografisch redundante opslag is het gebruik van back-upopslag twee keer zo hoog als die van de lokaal redundante opslag.

De belangrijkste manier om de kosten voor back-upopslag te beheren, is door de juiste bewaarperiode voor back-ups in te stellen en de juiste opties voor back-upredundantie te kiezen om te voldoen aan de gewenste hersteldoelen. U kunt een bewaarperiode van 7 tot 35 dagen selecteren. Servers voor algemeen gebruik en geoptimaliseerd voor geheugen kunnen ervoor kiezen om geografisch redundante opslag voor back-ups te hebben.

Herstellen

In Azure Database for MariaDB maakt het uitvoeren van een herstel een nieuwe server op basis van de back-ups van de oorspronkelijke server en herstelt u alle databases in de server.

Er zijn twee soorten herstel beschikbaar:

  • Herstel naar een bepaald tijdstip is beschikbaar met de optie back-upredundantie en maakt een nieuwe server in dezelfde regio als de oorspronkelijke server die gebruikmaakt van de combinatie van volledige back-ups en back-ups van transactielogboeken.
  • Geo-herstel is alleen beschikbaar als u uw server hebt geconfigureerd voor geografisch redundante opslag. Hiermee kunt u uw server herstellen naar een andere regio met behulp van de meest recente back-up die u hebt gemaakt.

De geschatte duur van het herstel is afhankelijk van diverse factoren, waaronder de grootte van de databases, de transactielogboekgrootte, de netwerkbandbreedte en het totale aantal databases dat op hetzelfde moment in dezelfde regio moet worden hersteld. De hersteltijd is minder dan 12 uur.

Belangrijk

Verwijderde servers kunnen slechts binnen vijf dagen na verwijdering worden hersteld waarna de back-ups worden verwijderd. De databaseback-up kan alleen worden geopend en hersteld vanuit het Azure-abonnement dat als host fungeert voor de server. Raadpleeg de gedocumenteerde stappen om een verwijderde server te herstellen. Beheerders kunnen beheervergrendelingen gebruiken om serverbronnen te beveiligen, na de implementatie, tegen onbedoelde verwijdering of onverwachte wijzigingen.

Herstel naar een bepaald tijdstip

Onafhankelijk van de optie voor back-upredundantie kunt u een herstelbewerking uitvoeren naar een bepaald tijdstip binnen de bewaarperiode voor back-ups. Er wordt een nieuwe server gemaakt in dezelfde Azure-regio als de oorspronkelijke server. Deze wordt gemaakt met de configuratie van de oorspronkelijke server voor de prijscategorie, het genereren van berekeningen, het aantal vCores, de opslaggrootte, de bewaarperiode voor back-ups en de optie voor back-upredundantie.

Herstel naar een bepaald tijdstip is handig in meerdere scenario's. Wanneer een gebruiker bijvoorbeeld per ongeluk gegevens verwijdert, een belangrijke tabel of database verwijdert of als een toepassing per ongeluk goede gegevens overschrijft met slechte gegevens vanwege een toepassingsfout.

Mogelijk moet u wachten tot de volgende back-up van het transactielogboek is gemaakt voordat u binnen de afgelopen vijf minuten kunt herstellen naar een bepaald tijdstip.

Geo-herstel

U kunt een server herstellen naar een andere Azure-regio waar de service beschikbaar is als u uw server hebt geconfigureerd voor geografisch redundante back-ups. Servers die maximaal 4 TB opslagruimte ondersteunen, kunnen worden hersteld naar de geografisch gekoppelde regio of naar elke regio die ondersteuning biedt voor maximaal 16 TB aan opslag. Voor servers die maximaal 16 TB aan opslag ondersteunen, kunnen geo-back-ups worden hersteld in elke regio die ook 16 TB-servers ondersteunt. Bekijk de prijscategorieën van Azure Database for MariaDB voor de lijst met ondersteunde regio's.

Geo-herstel is de standaardhersteloptie wanneer uw server niet beschikbaar is vanwege een incident in de regio waar de server wordt gehost. Als een grootschalig incident in een regio ertoe leidt dat uw databasetoepassing niet beschikbaar is, kunt u een server herstellen van de geografisch redundante back-ups naar een server in een andere regio. Geo-herstel maakt gebruik van de meest recente back-up van de server. Er is een vertraging tussen het moment waarop een back-up wordt gemaakt en wanneer deze naar een andere regio wordt gerepliceerd. Deze vertraging kan maximaal een uur duren, dus als er zich een noodgeval voordoet, kan er maximaal één uur gegevensverlies optreden.

Belangrijk

Als een geo-herstelbewerking wordt uitgevoerd voor een zojuist gemaakte server, kan de initiële back-upsynchronisatie meer dan 24 uur duren, afhankelijk van de grootte van de gegevens omdat de eerste volledige back-uptijd van de back-up veel hoger is. Volgende momentopnameback-ups zijn incrementele kopieën en daarom zijn de herstelbewerkingen na 24 uur na het maken van de server sneller. Als u geo-herstel evalueert om uw RTO te definiëren, raden we u aan om pas na 24 uur na het maken van servers te wachten en te evalueren voor betere schattingen.

Tijdens een geografisch herstel zijn de serverconfiguraties die kunnen worden gewijzigd onder andere: compute-generatie, vCore, bewaarperioden voor back-ups en opties voor redundantie van back-ups. Het wijzigen van de prijscategorie (Basic, Algemeen gebruik of Geoptimaliseerd voor geheugen) of de opslaggrootte tijdens geo-herstel wordt niet ondersteund.

De geschatte duur van het herstel is afhankelijk van diverse factoren, waaronder de grootte van de databases, de transactielogboekgrootte, de netwerkbandbreedte en het totale aantal databases dat op hetzelfde moment in dezelfde regio moet worden hersteld. De hersteltijd is minder dan 12 uur.

Taken na herstel uitvoeren

Nadat een herstelmechanisme is hersteld, moet u de volgende taken uitvoeren om uw gebruikers en toepassingen weer aan de slag te laten gaan:

  • Als de nieuwe server bedoeld is om de oorspronkelijke server te vervangen, stuurt u clients en clienttoepassingen om naar de nieuwe server
  • Zorg ervoor dat de juiste VNet-regels zijn ingesteld om gebruikers verbinding te laten maken. Deze regels worden niet gekopieerd van de oorspronkelijke server.
  • Zorg ervoor dat de juiste aanmeldingen en machtigingen op databaseniveau aanwezig zijn
  • Waarschuwingen configureren, indien van toepassing

Volgende stappen