Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
van toepassing op:
Azure SQL DatabaseSQL-database in Fabric
Dit artikel bevat een overzicht van de mogelijkheden voor bedrijfscontinuïteit en herstel na noodgevallen van Azure SQL Database, waarin de opties en aanbevelingen worden beschreven voor het herstellen van verstorende gebeurtenissen die kunnen leiden tot gegevensverlies of waardoor uw database en toepassing niet meer beschikbaar zijn. Meer informatie over wat u moet doen wanneer een gebruiker of toepassingsfout van invloed is op de gegevensintegriteit, een Azure-beschikbaarheidszone of -regio heeft een storing of dat uw toepassing onderhoud vereist.
Overzicht
Bedrijfscontinuïteit in Azure SQL Database verwijst naar de mechanismen, beleidsregels en procedures waarmee uw bedrijf kan blijven werken in het gezicht van onderbrekingen door beschikbaarheid, hoge beschikbaarheid en herstel na noodgevallen te bieden.
In de meeste gevallen verwerkt SQL Database verstorende gebeurtenissen die zich in een cloudomgeving kunnen voordoen en blijven uw toepassingen en bedrijfsprocessen actief. Er zijn echter enkele verstorende gebeurtenissen waarbij het beperken enige tijd kan duren, zoals:
- Gebruiker verwijdert of werkt per ongeluk een rij in een tabel bij.
- Kwaadwillende aanvaller verwijdert gegevens of verwijdert een database.
- Een catastrofale natuurrampgebeurtenis legt een datacenter, beschikbaarheidszone of regio plat.
- Zeldzame datacenter-, beschikbaarheidszone- of regiobrede storing veroorzaakt door een configuratiewijziging, softwarefout of hardwarefout.
Zie voor prescriptieve aanbevelingen om de beschikbaarheid te maximaliseren en een hogere bedrijfscontinuïteit te bereiken:
- controlelijst voor beschikbaarheid
- controlelijst voor hoge beschikbaarheid
- controlelijst voor herstel na noodgevallen
Hoge beschikbaarheid
Azure SQL Database wordt geleverd met een kerntolerantie en betrouwbaarheidsbelofte die deze beschermt tegen software- of hardwarefouten. Databaseback-ups worden geautomatiseerd om uw gegevens te beschermen tegen beschadiging of onbedoeld verwijderen. Als PaaS (Platform-as-a-Service) biedt de Azure SQL Database-service beschikbaarheid als een standaardfunctie met een toonaangevende SLA voor beschikbaarheid van 99,99%.
Schakel zoneredundantie in om hoge beschikbaarheid te bereiken in de Azure-cloudomgeving. Bij zoneredundantie maakt de database of elastische pool gebruik van Azure-beschikbaarheidszones om tolerantie voor zonefouten te garanderen.
- Veel Azure-regio's bieden beschikbaarheidszones, die gescheiden groepen datacenters zijn binnen een regio met onafhankelijke energie-, koelings- en netwerkinfrastructuur.
- Beschikbaarheidszones zijn ontworpen om regionale services, capaciteit en hoge beschikbaarheid in de resterende zones te bieden als één zone een storing ondervindt.
Door zoneredundantie in te schakelen, is de database of elastische pool bestand tegen zonegebonden hardware- en softwarefouten en is het herstel transparant voor toepassingen. Wanneer hoge beschikbaarheid is ingeschakeld, kan de Azure SQL Database-service een SLA met een hogere beschikbaarheid van 99.995%bieden.
Herstel na een ramp
Als u een hogere beschikbaarheid en redundantie in verschillende regio's wilt bereiken, kunt u mogelijkheden voor herstel na noodgevallen inschakelen om de database snel te herstellen na een catastrofale regionale storing. Opties voor herstel na noodgevallen met Azure SQL Database zijn:
- Actieve geo-replicatie kunt u een continu gesynchroniseerde leesbare secundaire database maken in elke regio voor een primaire database.
- failovergroepen, naast continue synchronisatie tussen een primaire en secundaire database, kunt u ook de replicatie en failover van sommige of alle databases op een logische server beheren naar een secundaire logische server in een andere regio. Failover-groepen bieden lees-schrijf- en alleen-lezen-listener-eindpunten die ongewijzigd blijven, zodat het bijwerken van verbindingsreeksen van de applicatie na een failover niet nodig is.
- Geo-herstel stelt u in staat om te herstellen van een regionale storing door gebruik te maken van geo-gerepliceerde back-ups. Dit doet u wanneer u geen toegang hebt tot uw database in de primaire regio, door een nieuwe database aan te maken op een bestaande server in een van de Azure-regio's.
De volgende tabel vergelijkt actieve geo-replicatie en failovergroepen, twee opties voor herstel na noodgevallen voor Azure SQL Database:
| Actieve geo-replicatie | Failovergroepen | |
|---|---|---|
| continue gegevenssynchronisatie tussen primaire en secundaire | Ja | Ja |
| Overstappen naar meerdere databases tegelijkertijd | Nee | Ja |
| verbindingsreeks blijft ongewijzigd na failover | Nee | Ja |
| Ondersteunt leesopschaling | Ja | Ja |
| meerdere replica's | Ja | Nee |
| kan zich in dezelfde regio bevinden als de primaire | Ja | Nee |
RTO en RPO
Wanneer u uw bedrijfscontinuïteitsplan ontwikkelt, begrijpt u de maximaal acceptabele tijd voordat de toepassing volledig wordt hersteld na de verstorende gebeurtenis. Twee veelvoorkomende manieren om bedrijfsvereisten te kwantificeren rond herstel na noodgevallen zijn:
- Beoogde hersteltijd (RTO):de tijd die nodig is voor een toepassing om volledig te herstellen na een ongeplande verstorende gebeurtenis.
- Recovery Point Objective (RPO): de tijdsduur van gegevensverlies die kan worden getolereerd door een ongeplande verstorende gebeurtenis.
In de volgende tabel worden RPO en RTO van elke optie voor bedrijfscontinuïteit vergeleken:
| optie bedrijfscontinuïteit | RTO (uitvaltijd) | RPO (gegevensverlies) |
|---|---|---|
| Hoge beschikbaarheid (zoneredundantie gebruiken) |
Doorgaans minder dan 30 seconden | 0 |
| Herstel na noodgevallen (failovergroepen gebruiken met door de klant beheerd failoverbeleid of actieve geo-replicatie) |
Doorgaans minder dan 60 seconden | Gelijk aan of groter dan 0 (is afhankelijk van gegevenswijzigingen vóór de verstorende gebeurtenis die niet is gerepliceerd) |
| Herstel na noodgevallen (gebruikmakend van geo-herstel) |
Doorgaans minuten of uren, afhankelijk van Azure Storage-replicatie | Meestal minuten of uren, afhankelijk van de grootte van de back-up van de database |
Functies die bedrijfscontinuïteit bieden
Vanuit databaseperspectief zijn er vier belangrijke scenario's voor mogelijke onderbrekingen. De volgende tabel bevat functies voor bedrijfscontinuïteit van SQL Database die u kunt gebruiken om een mogelijk scenario voor bedrijfsonderbreking te beperken:
| Scenario voor bedrijfsonderbreking | Bedrijfscontinuïteitsfunctie |
|---|---|
| Lokale hardware- of softwarefouten die van invloed zijn op het databaseknooppunt. | Om lokale hardware- en softwarefouten te beperken, bevat Azure SQL Database een beschikbaarheidsarchitectuur, die automatisch herstel van deze fouten garandeert met maximaal 99,99% sla voor beschikbaarheid. |
| Gegevensbeschadiging of -verwijdering, meestal veroorzaakt door een fout of menselijke fout in de toepassing. Dergelijke fouten zijn toepassingsspecifiek en kunnen doorgaans niet worden gedetecteerd door de databaseservice. | Om uw bedrijf te beschermen tegen gegevensverlies, maakt SQL Database elke 12 of 24 uur automatisch volledige databaseback-ups, differentiële databaseback-ups en elke 5 tot 10 minuten back-ups van transactielogboeken. Standaard worden back-ups opgeslagen in geografisch redundante opslag gedurende zeven dagen voor alle servicelagen. Alle serviceniveaus behalve Basic bieden ondersteuning voor een configureerbare bewaarperiode voor back-ups voor herstel op een specifiek tijdstip van maximaal 35 dagen. U kunt een verwijderde database herstellen naar het punt waarop deze is verwijderd als de server niet is verwijderd of als u langetermijnretentie (LTR)hebt geconfigureerd. |
| Zeldzame storingen in datacenters of beschikbaarheidszones, mogelijk veroorzaakt door een natuurramp, configuratiewijziging, softwarefout of hardwarestoring. | Als u storing op datacenter- of beschikbaarheidszoneniveau wilt beperken, schakelt u zoneredundantie voor de database of elastische pool in om Azure-beschikbaarheidszones te gebruiken en redundantie te bieden voor meerdere fysieke zones binnen een Azure-regio. Door zoneredundantie in te schakelen, zorgt u ervoor dat de database of elastische pool bestand is tegen zonefouten met maximaal 99.995% SLA voor hoge beschikbaarheid. |
| Zeldzame regionale storingen die van invloed zijn op alle beschikbaarheidszones en de datacenters waaruit deze bestaan, mogelijk veroorzaakt door een catastrofale natuurramp. | Als u een storing in de hele regio wilt beperken, schakelt u herstel na noodgevallen in met behulp van een van de volgende opties: - Opties voor continue gegevenssynchronisatie, zoals failovergroepen (aanbevolen) of actieve geo-replicatie waarmee u replica's in een secundaire regio kunt maken voor failover. Backupopslagredundantie instellen op geografisch redundante opslag om geo-herstel te gebruiken. |
Voorbereiden op een regiostoring
Ongeacht welke functies voor bedrijfscontinuïteit u gebruikt, moet u de secundaire database in een andere regio voorbereiden. Als u zich niet goed voorbereidt, neemt het online brengen van uw toepassingen na een failover of herstel extra tijd in beslag en vereist waarschijnlijk ook probleemoplossing, waardoor RTO kan worden vertraagd. Volg de checklist voor het voorbereiden van de secundaire systemen bij een regio-uitval.
Een database binnen dezelfde Azure-regio herstellen
U kunt automatische databaseback-ups gebruiken om een database te herstellen naar een bepaald tijdstip in het verleden. Op deze manier kunt u gegevensbeschadigingen herstellen die worden veroorzaakt door menselijke fouten. Met herstel naar een bepaald tijdstip (PITR) kunt u een nieuwe database maken op dezelfde server die de status van de gegevens vertegenwoordigt vóór de beschadigde gebeurtenis. Zie RTO en RPOvoor hersteltijden.
Als de maximaal ondersteunde bewaarperiode voor back-ups voor herstel naar een bepaald tijdstip niet voldoende is voor uw toepassing, kunt u deze uitbreiden door een langetermijnretentiebeleid (LTR) te configureren. Zie langetermijnretentievoor meer informatie.
Een toepassing upgraden met minimale downtime
Soms moet een toepassing offline worden gehaald vanwege onderhoud, zoals een upgrade van een toepassing. U kunt rolling upgrades van cloudtoepassingen beheren met behulp van actieve geo-replicatie van SQL Database. Geo-replicatie kan ook een herstelpad bieden als er iets misgaat.
Bespaar op kosten met een reservekopie.
Als uw secundaire replica wordt gebruikt alleen voor herstel na noodgevallen en geen lees- of schrijfworkloads heeft, kunt u besparen op licentiekosten door de database voor stand-by aan te wijzen wanneer u een nieuwe actieve geo-replicatierelatie configureert.
Bekijk licentievrije stand-bykopie voor meer informatie.
Volgende stap
Verwante inhoud
- Wereldwijd beschikbare services ontwerpen met behulp van Azure SQL Database
- Strategieën voor herstel na noodgevallen voor toepassingen die elastische Pools van Azure SQL Database gebruiken
- Richtlijnen voor herstel na noodgevallen - Azure SQL Database
- Controlelijst voor hoge beschikbaarheid en herstel na noodgevallen - Azure SQL Database