Back-up en herstel in Azure Database for MySQL - Flexibele server

  • Artikel

VAN TOEPASSING OP: Azure Database for MySQL - Flexibele server

Azure Database for MySQL Flexibele server maakt automatisch serverback-ups en slaat deze veilig op in lokale redundante opslag binnen de regio. 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.

Overzicht van Backup

Flexibele Azure Database for MySQL-server ondersteunt twee soorten back-ups om een verbeterde flexibiliteit te bieden voor het onderhouden van back-ups van de bedrijfskritieke gegevens.

Automatische back-up

Azure Database for MySQL Flexibele server maakt momentopnameback-ups van de gegevensbestanden en slaat deze op in een lokale redundante opslag. De server voert ook back-ups van transactielogboeken uit en slaat deze ook op in lokale redundante opslag. 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 de back-up van de database desgewenst 1 tot 35 dagen configureren. Alle back-ups worden versleuteld met AES 256-bits versleuteling voor de gegevens die at-rest zijn opgeslagen.

Back-up op aanvraag

Met azure Database for MySQL flexibele server kunt u ook back-ups op aanvraag van de productieworkload activeren, naast de automatische back-ups die door de service worden gemaakt en opslaan in overeenstemming met het bewaarbeleid voor back-ups van de server. U kunt deze back-ups gebruiken als een snelste herstelpunt om een herstel naar een bepaald tijdstip uit te voeren om hersteltijden met maximaal 90% te verminderen. De standaardretentieperiode voor back-ups is zeven dagen. U kunt de back-up van de database desgewenst 1 tot 35 dagen configureren. U kunt in totaal 50 back-ups op aanvraag activeren vanuit de portal. Alle back-ups worden versleuteld met AES 256-bits versleuteling voor de gegevens die at-rest zijn opgeslagen.

Deze back-upbestanden kunnen niet worden geëxporteerd. De back-ups kunnen alleen worden gebruikt voor herstelbewerkingen in azure Database for MySQL flexibele server. U kunt mysqldump ook gebruiken vanuit een MySQL-client om een database te kopiëren.

Back-upfrequentie

Back-ups op flexibele servers zijn gebaseerd op momentopnamen. De eerste momentopnameback-up wordt gepland direct nadat een server is gemaakt. Momentopnameback-ups worden eenmaal per dag gemaakt. Back-ups van transactielogboeken worden elke vijf minuten uitgevoerd. Als een geplande back-up mislukt, probeert onze back-upservice elke 20 minuten een back-up te maken totdat een back-up is geslaagd. Deze back-upfouten kunnen optreden als gevolg van zware transactionele productiebelastingen op het serverexemplaren.

Redundantieopties voor back-up

Azure Database for MySQL Flexibele server slaat meerdere kopieën van uw back-ups op, zodat uw gegevens worden beschermd tegen geplande en niet-geplande gebeurtenissen, waaronder tijdelijke hardwarestoringen, netwerk- of stroomstoringen en enorme natuurrampen. Flexibele Azure Database for MySQL-server biedt de flexibiliteit om te kiezen tussen lokaal redundante, zone-redundante of geografisch redundante back-upopslag in basic- en algemeen gebruik en Bedrijfskritiek lagen. Standaard is azure Database for MySQL flexibele serverback-upopslag lokaal redundant voor servers met hoge beschikbaarheid in dezelfde zone of geen configuratie met hoge beschikbaarheid en zone-redundant voor servers met zone-redundante HA-configuratie.

Back-upredundantie zorgt ervoor dat uw database voldoet aan de beschikbaarheids- en duurzaamheidsdoelen, zelfs als er fouten optreden en azure Database for MySQL flexibele server drie opties voor gebruikers uitbreidt-

  • Lokaal redundante back-upopslag : wanneer de back-ups worden opgeslagen in lokaal redundante back-upopslag, worden meerdere kopieën van back-ups opgeslagen in hetzelfde datacenter. Met deze optie worden uw gegevens beschermd tegen serverrack- en stationsfouten. Dit biedt ook ten minste 99,9999999999% (11 9's) duurzaamheid van Backups-objecten gedurende een bepaald jaar. Standaard is back-upopslag voor servers met hoge beschikbaarheid in dezelfde zone of geen configuratie voor hoge beschikbaarheid ingesteld op lokaal redundant.

  • Zone-redundante back-upopslag : wanneer de back-ups worden opgeslagen in zone-redundante back-upopslag, worden meerdere kopieën niet alleen opgeslagen in de beschikbaarheidszone waarin uw server wordt gehost, maar worden ze ook gerepliceerd naar een andere beschikbaarheidszone in dezelfde regio. Deze optie kan worden gebruikt voor scenario's waarvoor hoge beschikbaarheid is vereist of voor het beperken van de replicatie van gegevens naar binnen een land/regio om te voldoen aan de vereisten voor gegevenslocatie. Dit biedt ook ten minste 99,99999999999% (12 9's) duurzaamheid van Backups-objecten gedurende een bepaald jaar. U kunt zone-redundante optie voor hoge beschikbaarheid selecteren op de server om zone-redundante back-upopslag te garanderen. Hoge beschikbaarheid voor een server kan worden uitgeschakeld na het maken, maar de back-upopslag blijft zone-redundant.

  • Geografisch redundante back-upopslag : wanneer de back-ups worden opgeslagen in geografisch redundante back-upopslag, worden meerdere kopieën niet alleen opgeslagen in de regio waarin uw server wordt gehost, maar worden ze ook gerepliceerd naar de geografisch gekoppelde regio. Dit biedt betere beveiliging en de mogelijkheid om uw server in een andere regio te herstellen in een noodgeval. Dit biedt ook ten minste 99,999999999999999% (16 9's) duurzaamheid van Back-upobjecten gedurende een bepaald jaar. U kunt de optie Georedundantie op server inschakelen om geografisch redundante back-upopslag te garanderen. Daarnaast kunt u van lokaal redundante opslag naar geografisch redundante opslag gaan na het maken van de server. Geografische redundantie wordt ondersteund voor servers die worden gehost in een van de gekoppelde Azure-regio's.

Notitie

Zone-redundante hoge beschikbaarheid ter ondersteuning van zoneredundantie wordt alleen weergegeven als een tijdbewerking voor maken. Op dit moment kan georedundantie van een zone-redundante server met hoge beschikbaarheid alleen worden ingeschakeld/uitgeschakeld tijdens het maken van de server.

Overstappen van andere opties voor back-upopslag naar geografisch redundante back-upopslag

U kunt uw bestaande back-upopslag verplaatsen naar geografisch redundante opslag met behulp van de volgende voorgestelde manieren:

  • Overstappen van lokaal redundante back-upopslag naar geografisch redundante back-upopslag : als u uw back-upopslag wilt verplaatsen van lokaal redundante opslag naar geografisch redundante opslag, kunt u de configuratie van de Compute + Storage-server wijzigen vanuit Azure Portal om georedundantie in te schakelen voor de lokaal redundante bronserver. Dezelfde zone-redundante HA-servers kunnen ook worden hersteld als een geografisch redundante server op een vergelijkbare manier als de onderliggende back-upopslag lokaal redundant is voor hetzelfde.

  • Overstappen van zone-redundante back-upopslag naar geografisch redundante back-upopslag - Azure Database for MySQL flexibele server biedt geen ondersteuning voor zone-redundante opslag naar geografisch redundante opslagconversie via Compute + Storage-instellingen nadat de server is ingericht. Als u uw back-upopslag wilt verplaatsen van zone-redundante opslag naar geografisch redundante opslag, zijn er twee opties: a) Pitr gebruiken (herstel naar een bepaald tijdstip) om de server met de gewenste configuratie te herstellen. b) Maak een nieuwe server met de gewenste configuratie en migreer de gegevens met behulp van dump en herstel.

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 1 tot 35 dagen selecteren met een standaardretentieperiode van 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.

De bewaarperiode voor back-ups bepaalt hoe ver terug in de tijd een herstelbewerking naar een bepaald tijdstip kan worden uitgevoerd, 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 worden momentopnamen van databases en back-ups van transactielogboeken opgeslagen voor de afgelopen acht dagen (1 dag vóór het venster).

Kosten van back-upopslag

Flexibele Azure Database for MySQL-server 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 opslagruimte beschikbaar voor serverback-ups zonder extra kosten. Als het dagelijkse back-upgebruik 25 GB is, kunt u maximaal 10 dagen gratis back-upopslag hebben. Opslag die wordt verbruikt voor back-ups van meer dan 250 GB, wordt in rekening gebracht volgens het prijsmodel.

U kunt de metrische gegevens back-upopslag gebruiken in Azure Monitor die beschikbaar is in Azure Portal om de back-upopslag te bewaken die door een server wordt gebruikt. De metrische gegevens back-upopslag die wordt gebruikt, vertegenwoordigt de som van de opslag die wordt gebruikt door alle databaseback-ups en logboekback-ups die worden bewaard op basis van de retentieperiode voor de back-up die is ingesteld voor de server. Intensieve transactionele activiteit op de server kan ertoe leiden dat het gebruik van back-upopslag toeneemt, onafhankelijk van de totale databasegrootte. Back-upopslag die wordt gebruikt voor een geografisch redundante server is twee keer dat van een lokaal redundante server.

De primaire manier om de kosten voor back-upopslag te beheren, is door de juiste bewaarperiode voor back-ups in te stellen. U kunt een bewaarperiode tussen 1 en 35 dagen selecteren.

Belangrijk

Back-ups van een databaseserver die is geconfigureerd in een zone-redundante configuratie voor hoge beschikbaarheid vindt plaats vanaf de primaire databaseserver, omdat de overhead minimaal is met back-ups van momentopnamen.

Beschikbare volledige back-ups weergeven

De blade Back-up en herstel in Azure Portal biedt een volledige lijst met de volledige back-ups die op elk gewenst moment voor u beschikbaar zijn. Dit omvat geautomatiseerde back-ups en de on-demand back-ups. U kunt deze blade gebruiken om de voltooiingstijdstempels te bekijken voor alle beschikbare volledige back-ups binnen de bewaarperiode van de server en om herstelbewerkingen uit te voeren met behulp van deze volledige back-ups. De lijst met beschikbare back-ups bevat alle volledige back-ups binnen de bewaarperiode, een tijdstempel met de geslaagde voltooiing, een tijdstempel die aangeeft hoe lang een back-up wordt bewaard en een herstelactie.

Herstellen

In Azure Database for MySQL Flexibele server maakt het uitvoeren van een herstel een nieuwe server op basis van de back-ups van de oorspronkelijke 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.
  • Geo-herstel: is alleen beschikbaar als u uw server hebt geconfigureerd voor geografisch redundante opslag en u kunt uw server herstellen naar een geografisch gekoppelde regio of een andere ondersteuning voor Azure regio waar flexibele server beschikbaar is.

De geschatte tijd voor het herstel van de server is afhankelijk van verschillende factoren:

  • De grootte van de databases
  • Het aantal betrokken transactielogboeken
  • De hoeveelheid activiteit die opnieuw moet worden afgespeeld om te herstellen naar het herstelpunt
  • De netwerkbandbreedte als de herstelbewerking zich in een andere regio bevindt
  • Het aantal gelijktijdige herstelaanvragen dat wordt verwerkt in de doelregio
  • De aanwezigheid van primaire sleutel in de tabellen in de database. Voor sneller herstel kunt u overwegen om een primaire sleutel toe te voegen voor alle tabellen in uw database.

Notitie

Een server met hoge beschikbaarheid wordt niet-hoge beschikbaarheid (hoge beschikbaarheid uitgeschakeld) na herstel voor zowel herstel naar een bepaald tijdstip als geo-herstel.

Herstel naar een bepaald tijdstip

In Azure Database for MySQL flexibele server maakt het uitvoeren van een herstel naar een bepaald tijdstip een nieuwe server op basis van de back-ups van de flexibele server in dezelfde regio als uw bronserver. Deze wordt gemaakt met de configuratie van de oorspronkelijke server voor de rekenlaag, het aantal vCores, de opslaggrootte, de bewaarperiode voor back-ups en de optie voor back-upredundantie. Bovendien worden tags en instellingen, zoals het virtuele netwerk en de firewall, overgenomen van de bronserver. De reken- en opslaglaag van de herstelde server, configuratie- en beveiligingsinstellingen kunnen worden gewijzigd nadat het herstellen is voltooid.

Notitie

Er zijn twee serverparameters die na de herstelbewerking opnieuw worden ingesteld op standaardwaarden (en die niet worden gekopieerd van de primaire server)

  • time_zone: deze waarde moet worden ingesteld op de standaardwaarde SYSTEM
  • event_scheduler: de event_scheduler is ingesteld op UIT op de herstelde server

Herstel naar een bepaald tijdstip is handig in meerdere scenario's. Enkele van de veelvoorkomende gebruiksvoorbeelden zijn:

  • Wanneer een gebruiker per ongeluk gegevens in de database verwijdert
  • Gebruiker verwijdert een belangrijke tabel of database
  • Gebruikerstoepassing overschrijft per ongeluk goede gegevens met slechte gegevens vanwege een toepassingsfout.

U kunt kiezen tussen het meest recente herstelpunt, het aangepaste herstelpunt en het snelste herstelpunt (herstellen met volledige back-up) via Azure Portal.

  • Laatste herstelpunt: Met de optie voor het meest recente herstelpunt kunt u de server herstellen naar de tijdstempel wanneer de herstelbewerking is geactiveerd. Deze optie is handig om de server snel te herstellen naar de meest bijgewerkte status.
  • Aangepast herstelpunt: met deze optie kunt u een bepaald tijdstip kiezen binnen de retentieperiode die voor deze server is gedefinieerd. Deze optie is handig om de server op het precieze moment te herstellen om te herstellen van een gebruikersfout.
  • Snelste herstelpunt: met deze optie kunnen gebruikers de server in de snelst mogelijke tijd voor een bepaalde dag herstellen binnen de retentieperiode die is gedefinieerd voor hun server. Het snelste herstel is mogelijk door het herstelpunt te kiezen waarop de volledige back-up is voltooid. Deze herstelbewerking herstelt eenvoudig de volledige back-up van momentopnamen en garandeert niet dat logboeken worden hersteld of hersteld, waardoor het snel gaat. U wordt aangeraden een volledige tijdstempel voor back-ups te selecteren die groter is dan het vroegste herstelpunt voor een geslaagde herstelbewerking.

De geschatte hersteltijd is afhankelijk van verschillende factoren, waaronder de databasegrootte, de back-upgrootte van het transactielogboek, de rekenkracht van de SKU en de tijd van het herstellen. Het herstel van het transactielogboek is het meest tijdrovende onderdeel van het herstelproces. Als de hersteltijd dichter bij het back-upschema voor momentopnamen wordt gekozen, zijn de herstelbewerkingen sneller omdat de transactielogboektoepassing minimaal is. Als u de nauwkeurige hersteltijd voor uw server wilt schatten, raden we u ten zeerste aan om deze in uw omgeving te testen omdat deze te veel omgevingsspecifieke variabelen heeft.

Belangrijk

Als u een exemplaar van een flexibele Azure Database for MySQL-server herstelt dat is geconfigureerd met zone-redundante hoge beschikbaarheid, wordt de herstelde server geconfigureerd in dezelfde regio en zone als uw primaire server en geïmplementeerd als één server in de modus niet-HOGE BESCHIKBAARHEID. Raadpleeg zone-redundante hoge beschikbaarheid voor flexibele servers.

Belangrijk

U kunt binnen 5 dagen na het verwijderen van de server een verwijderde flexibele Azure Database for MySQL-serverresource herstellen. Raadpleeg de gedocumenteerde stappen voor een gedetailleerde handleiding over het herstellen van een verwijderde server. Beheerders kunnen gebruikmaken van beheervergrendelingen om serverbronnen na de implementatie te beveiligen tegen onbedoelde verwijdering of onverwachte wijzigingen.

Geo-herstel

U kunt een server herstellen naar de geografisch gekoppelde regio waar de service beschikbaar is als u uw server hebt geconfigureerd voor geografisch redundante back-ups of een andere ondersteuning voor Azure regio waar azure Database for MySQL flexibele server beschikbaar is. Mogelijkheid om te herstellen naar een niet-gekoppelde ondersteuning voor Azure ed regio (behalve Brazil South, USGov Virginia en West US 3) wordt ook wel 'Universal Geo-restore' genoemd.

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.

Geo-herstel kan ook worden uitgevoerd op een gestopte server die gebruikmaakt van Azure CLI. Lees Azure Database for MySQL Flexibele server herstellen met Azure CLI voor meer informatie over geo-herstel van een server met Azure CLI.

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.

Notitie

Als u geo-herstelt van een exemplaar van een flexibele Azure Database for MySQL-server dat is geconfigureerd met zone-redundante hoge beschikbaarheid, wordt de herstelde server geconfigureerd in de geografisch gekoppelde regio en dezelfde zone als uw primaire server en geïmplementeerd als één exemplaar van een flexibele Azure Database for MySQL-server in een niet-HA-modus. Raadpleeg zone-redundante hoge beschikbaarheid voor flexibele Azure Database for MySQL-server.

Belangrijk

Wanneer de primaire regio niet beschikbaar is, kunt u geen geografisch redundante servers maken in de respectieve regio met geo-gekoppelde regio, omdat opslag niet kan worden ingericht in de primaire regio. U moet wachten totdat de primaire regio is ingesteld op het inrichten van geografisch redundante servers in de geografisch gekoppelde regio. Als de primaire regio offline is, kunt u de bronserver nog steeds geo-herstellen naar de geografisch gekoppelde regio door de optie voor georedundantie uit te schakelen in de instellingen voor compute en opslag server configureren in de herstelportal-ervaring en herstellen als een lokaal redundante server om bedrijfscontinuïteit te garanderen.

Taken na herstel uitvoeren

Na een herstelbewerking vanaf het meest recente herstelpunt of een aangepast herstelpuntmechanisme moet u de volgende taken uitvoeren om uw gebruikers en toepassingen weer aan de slag te laten:

  • Als de nieuwe server bedoeld is om de oorspronkelijke server te vervangen, moet u clients en clienttoepassingen omleiden naar de nieuwe server.
  • Zorg ervoor dat de juiste firewall- en virtuele netwerkregels op serverniveau aanwezig zijn om gebruikers verbinding te laten maken.
  • Zorg ervoor dat de juiste aanmeldingen en machtigingen op databaseniveau aanwezig zijn.
  • Configureer waarschuwingen, indien van toepassing.

Langetermijnretentie (preview)

Azure Backup- en Azure Database for MySQL Flexibele serverservices hebben een langetermijnback-upoplossing voor Azure Database for MySQL flexibele serverexemplaren gebouwd die back-ups maximaal 10 jaar bewaren. U kunt langetermijnretentie onafhankelijk of naast de automatische back-upoplossing van Azure Database for MySQL flexibele server gebruiken, die retentie van maximaal 35 dagen biedt. Automatische back-ups zijn momentopnameback-ups die geschikt zijn voor operationele herstelbewerkingen, met name wanneer u wilt herstellen vanaf de meest recente back-ups. Langetermijnback-ups helpen u bij uw nalevingsbehoeften en controlebehoeften. Naast langetermijnretentie biedt de oplossing de volgende mogelijkheden:

  • Door de klant beheerde geplande en on-demand back-ups
  • Beheer en bewaak alle back-upbewerkingen en -taken op servers, resourcegroepen, locaties, abonnementen en tenants vanuit één venster met de naam Backup Center.
  • Back-ups die zijn opgeslagen in een afzonderlijk beveiligings- en foutdomeinen. Als de bronserver of het abonnement is gecompromitteerd, blijven de back-ups veilig in de Backup-kluis (in door Azure Backup beheerde opslagaccounts).

Beperkingen en overwegingen

  • In preview is LTR-herstel momenteel beschikbaar als RestoreasFiles voor opslagaccounts. RestoreasServer-mogelijkheid wordt in de toekomst toegevoegd.

  • LTR-back-up wordt momenteel niet ondersteund voor servers met hoge beschikbaarheid. Deze mogelijkheid wordt in de toekomst toegevoegd.

  • Ondersteuning voor het maken en beheren van LTR via Azure CLI wordt momenteel niet ondersteund.

Voor meer informatie over het uitvoeren van een back-up op lange termijn raadpleegt u de handleiding

Back-up en export op aanvraag (preview)

Azure Database for MySQL Flexibele server biedt nu de mogelijkheid om een fysieke back-up op aanvraag van de server te activeren en deze te exporteren naar een Azure-opslagaccount (Azure Blob Storage). Zodra deze back-ups zijn geëxporteerd, kunnen deze back-ups worden gebruikt voor gegevensherstel, migratie en redundantie. Deze geëxporteerde fysieke back-upbestanden kunnen worden gebruikt om terug te herstellen naar een on-premises MySQL-server om te voldoen aan de controle-/nalevings-/archiveringsbehoeften van een organisatie. De functie is momenteel beschikbaar als openbare preview en is alleen beschikbaar in openbare cloudregio's.

Raadpleeg de instructiegids voor meer informatie over het exporteren van back-ups

Veelgestelde vragen

  • Hoe kan ik een back-up maken van mijn server?

    Standaard maakt Azure Database for MySQL flexibele server automatische back-ups van uw hele server mogelijk (die alle databases omvat) met een standaard retentieperiode van 7 dagen. U kunt ook een handmatige back-up activeren met behulp van de functie Back-up op aanvraag. De andere manier om handmatig een back-up te maken, is door gebruik te maken van communityhulpprogramma's zoals mysqldump zoals hier wordt beschreven of mydumper, zoals hier wordt beschreven. Als u een back-up wilt maken van een exemplaar van een flexibele Azure Database for MySQL-server naar een Blob-opslag, raadpleegt u onze tech communityblog Backup Azure Database for MySQL flexibele server naar een Blob Storage.

  • Kan ik automatische back-ups zo configureren dat deze op lange termijn worden bewaard?

    Nee, momenteel ondersteunen we maximaal 35 dagen aan automatische back-upretentie. U kunt handmatige back-ups maken en deze gebruiken voor langetermijnretentievereisten.

  • Wat zijn de back-upvensters voor mijn server? Kan ik het aanpassen?

    De eerste momentopnameback-up wordt gepland direct nadat een server is gemaakt. Back-ups van momentopnamen worden eenmaal per dag gemaakt. Back-ups van transactielogboeken worden elke vijf minuten uitgevoerd. Back-upvensters worden inherent beheerd door Azure en kunnen niet worden aangepast.

  • Worden mijn back-ups versleuteld?

    Alle flexibele Azure Database for MySQL-servergegevens, back-ups en tijdelijke bestanden die tijdens de uitvoering van de query zijn gemaakt, worden versleuteld met AES 256-bits versleuteling. De opslagversleuteling is altijd actief en kan niet worden uitgeschakeld.

  • Kan ik een of meer databases herstellen?

    Het herstellen van een of meer databases of tabellen wordt niet ondersteund. Als u specifieke databases wilt herstellen, voert u een herstel naar een bepaald tijdstip uit en extraheert u de benodigde tabellen of databases.

  • Is mijn server beschikbaar tijdens het back-upvenster?

    Ja. Back-ups zijn onlinebewerkingen en zijn gebaseerd op momentopnamen. De momentopnamebewerking duurt slechts enkele seconden en interfereert niet met productieworkloads, waardoor hoge beschikbaarheid van de server wordt gegarandeerd.

  • Bij het instellen van het onderhoudsvenster voor de server moet u rekening houden met het back-upvenster?

    Nee, back-ups worden intern geactiveerd als onderdeel van de beheerde service en hebben geen invloed op het venster Beheerd onderhoud.

  • Waar worden mijn geautomatiseerde back-ups opgeslagen en hoe beheer ik hun retentie?

    Met Azure Database for MySQL flexibele server worden automatisch serverback-ups gemaakt en opgeslagen in door de gebruiker geconfigureerde, lokaal redundante opslag of in geografisch redundante opslag. Deze back-upbestanden kunnen niet worden geëxporteerd. De standaardretentieperiode voor back-ups is zeven dagen. U kunt de back-up van de database desgewenst 1 tot 35 dagen configureren.

  • Hoe kan ik mijn back-ups valideren?

    De beste manier om de beschikbaarheid van voltooide back-ups te valideren, is door de volledig geautomatiseerde back-ups weer te geven die zijn gemaakt binnen de bewaarperiode op de blade Back-up en Herstellen. Als een back-up mislukt, wordt deze niet vermeld in de lijst met beschikbare back-ups en probeert de back-upservice elke 20 minuten een back-up te maken totdat een geslaagde back-up is gemaakt. Deze back-upfouten worden veroorzaakt door zware transactionele productiebelastingen op de server.

  • Waar kan ik het back-upgebruik zien?

    In Azure Portal, onder het tabblad Bewaking - Metrische gegevens, vindt u de metrische gegevens back-upopslag die wordt gebruikt , zodat u het totale back-upgebruik kunt bewaken.

  • Wat gebeurt er met mijn back-ups als ik mijn server verwijder?

    Als u de server verwijdert, worden alle back-ups van de server ook verwijderd en kunnen ze niet worden hersteld. Beheerders kunnen beheervergrendelingen gebruiken om serverbronnen na de implementatie te beschermen tegen onbedoelde verwijdering of onverwachte wijzigingen.

  • Wat gebeurt er met mijn back-ups wanneer ik een server herstel?

    Als u een server herstelt, resulteert dit altijd in het maken van een netto nieuwe server die is hersteld met behulp van de back-ups van de oorspronkelijke server. De oude back-up van de oorspronkelijke server wordt niet gekopieerd naar de zojuist herstelde server en blijft bij de oorspronkelijke server. Voor de zojuist gemaakte server wordt de eerste momentopnameback-up echter onmiddellijk gepland nadat een server is gemaakt en zorgt de service ervoor dat dagelijkse automatische back-ups worden gemaakt en opgeslagen volgens de geconfigureerde bewaarperiode van de server.

  • Hoe worden er kosten in rekening gebracht en gefactureerd voor mijn gebruik van back-ups?

    Flexibele Azure Database for MySQL-server biedt maximaal 100% van uw ingerichte serveropslag als back-upopslag zonder extra kosten. Er worden meer gebruikte back-upopslag in GB per maand in rekening gebracht volgens het prijsmodel. Facturering voor back-upopslag wordt ook bepaald door de geselecteerde back-upretentieperiode en de gekozen optie voor back-upredundantie, afgezien van de transactionele activiteit op de server, wat van invloed is op de totale back-upopslag die rechtstreeks wordt gebruikt.

  • Hoe worden back-ups bewaard voor gestopte servers?

    Er worden geen nieuwe back-ups uitgevoerd voor gestopte servers. Alle oudere back-ups (binnen het bewaarvenster) op het moment dat de server wordt gestopt, worden bewaard totdat de server opnieuw wordt opgestart, waarna de back-upretentie voor de actieve server wordt beheerd door het back-upretentievenster.

  • Hoe wordt er gefactureerd voor back-ups voor een gestopte server?

    Terwijl uw serverexemplaren zijn gestopt, worden er kosten in rekening gebracht voor ingerichte opslag (inclusief ingerichte IOPS) en back-upopslag (back-ups die zijn opgeslagen in het opgegeven bewaarvenster). Gratis back-upopslag is beperkt tot de grootte van uw ingerichte database en is alleen van toepassing op actieve servers.

  • Hoe worden mijn back-upgegevens beveiligd?

    Azure Database for MySQL Flexibele server beschermt uw back-upgegevens door bewerkingen te blokkeren die kunnen leiden tot verlies van herstelpunten voor de duur van de geconfigureerde bewaarperiode. Back-ups die tijdens de bewaarperiode zijn gemaakt, kunnen alleen worden gelezen voor herstel en worden verwijderd na de bewaarperiode. Bovendien worden alle back-ups in azure Database for MySQL flexibele server versleuteld met behulp van AES 256-bits versleuteling voor de gegevens die in rust zijn opgeslagen.

  • Hoe is een herstelbewerking (Point-In-Time Restore) van invloed op het IOPS-gebruik?

    Tijdens een PITR-bewerking in Azure Database for MySQL - Flexible Server wordt een nieuwe server gemaakt en worden gegevens gekopieerd van de opslag van de bronserver naar de opslag van de nieuwe server. Dit proces resulteert in een verhoogd IOPS-gebruik op de bronserver. Deze toename van het IOPS-gebruik is normaal en geeft geen problemen aan met de bronserver of de PITR-bewerking. Zodra de PITR-bewerking is voltooid, keert het IOPS-gebruik op de bronserver terug naar de gebruikelijke niveaus.

  • Hoe kan ik mijn server herstellen? Azure Portal biedt ondersteuning voor herstel naar een bepaald tijdstip voor alle servers, zodat gebruikers kunnen herstellen naar de meest recente of aangepaste herstelpunten. Als u uw server handmatig wilt herstellen vanaf de back-ups die zijn gemaakt door mysqldump/myDumper, raadpleegt u Uw database herstellen met behulp van myLoader.

  • Waarom duurt het zoveel tijd voor mijn herstel?

    De geschatte tijd voor het herstel van de server is afhankelijk van verschillende factoren:

    • De grootte van de databases. Als onderdeel van het herstelproces moet de database worden gehydrateerd vanaf de laatste fysieke back-up, waardoor de tijd die nodig is om te herstellen evenredig is met de grootte van de database.
    • Het actieve deel van de transactieactiviteit dat opnieuw moet worden afgespeeld om te herstellen. Herstel kan langer duren, afhankelijk van de toegevoegde transactieactiviteit vanaf het laatste geslaagde controlepunt.
    • De netwerkbandbreedte als het herstelpunt in een andere regio is.
    • Het aantal gelijktijdige herstelaanvragen dat wordt verwerkt in de doelregio.
    • De aanwezigheid van primaire sleutels in de tabellen in de database. Voor sneller herstel kunt u primaire sleutels toevoegen voor alle tabellen in uw database.

  • Heeft het wijzigen van databasevariabelen op sessieniveau invloed op herstel?

    Het wijzigen van variabelen op sessieniveau en het uitvoeren van DML-instructies in een MySQL-clientsessie kan van invloed zijn op de PITR-bewerking (herstel naar een bepaald tijdstip), omdat deze wijzigingen niet worden vastgelegd in het binaire logboek dat wordt gebruikt voor back-up- en herstelbewerking. Foreign_key_checks zijn bijvoorbeeld een dergelijke variabele op sessieniveau. Als deze optie is uitgeschakeld voor het uitvoeren van een DML-instructie die de beperking voor refererende sleutels schendt, resulteert dit in een PITR-fout (herstel naar een bepaald tijdstip). De enige tijdelijke oplossing in een dergelijk scenario is het selecteren van een pitrtijd eerder dan het tijdstip waarop foreign_key_checks zijn uitgeschakeld. Onze aanbeveling is om geen sessievariabelen te wijzigen voor een geslaagde PITR-bewerking.

Volgende stappen