Overzicht van bedrijfscontinuïteit met Azure SQL DatabaseOverview of business continuity with Azure SQL Database

VAN TOEPASSING OP: jaAzure SQL Database jaMet Azure SQL beheerd exemplaar APPLIES TO: yesAzure SQL Database yesAzure SQL Managed Instance

Bedrijfs continuïteit in Azure SQL database en SQL Managed instance verwijst naar de mechanismen, beleids regels en procedures waarmee uw bedrijf kan blijven werken in het geval van storingen, met name op de computer infrastructuur.Business continuity in Azure SQL Database and SQL Managed Instance refers to the mechanisms, policies, and procedures that enable your business to continue operating in the face of disruption, particularly to its computing infrastructure. In de meeste gevallen verwerkt SQL Database en SQL Managed instance de storende gebeurtenissen die zich in de cloud omgeving kunnen voordoen en blijven uw toepassingen en bedrijfs processen actief.In the most of the cases, SQL Database and SQL Managed Instance will handle the disruptive events that might happen in the cloud environment and keep your applications and business processes running. Er zijn echter enkele storende gebeurtenissen die niet automatisch kunnen worden verwerkt door SQL Database, zoals:However, there are some disruptive events that cannot be handled by SQL Database automatically such as:

  • Gebruiker heeft per ongeluk een rij in een tabel verwijderd of bijgewerkt.User accidentally deleted or updated a row in a table.
  • Kwaadwillende aanvaller heeft gegevens verwijderd of een Data Base verwijderen.Malicious attacker succeeded to delete data or drop a database.
  • Aarding heeft geleid tot een stroom storing en een tijdelijk uitgeschakeld Data Center.Earthquake caused a power outage and temporary disabled datacenter.

In dit overzicht worden de mogelijkheden beschreven die SQL Database en SQL Managed instance bieden voor bedrijfs continuïteit en herstel na nood gevallen.This overview describes the capabilities that SQL Database and SQL Managed Instance provide for business continuity and disaster recovery. Meer informatie over opties, aanbevelingen en zelf studies voor het herstellen van storende gebeurtenissen die gegevens verlies kunnen veroorzaken of ervoor zorgen dat uw data base en toepassing niet meer beschikbaar zijn.Learn about options, recommendations, and tutorials for recovering from disruptive events that could cause data loss or cause your database and application to become unavailable. Meer informatie over wat u moet doen wanneer een gebruiker of toepassings fout van invloed is op de gegevens integriteit, een Azure-regio een storing heeft of als uw toepassing onderhoud vereist.Learn what to do when a user or application error affects data integrity, an Azure region has an outage, or your application requires maintenance.

SQL Database-functies die u kunt gebruiken voor bedrijfscontinuïteitSQL Database features that you can use to provide business continuity

Vanuit het perspectief van een Data Base zijn er vier belang rijke scenario's voor onderbrekingen:From a database perspective, there are four major potential disruption scenarios:

  • Lokale hardware-of software fouten die van invloed zijn op het database knooppunt, zoals een fout in de schijf schijf.Local hardware or software failures affecting the database node such as a disk-drive failure.
  • Gegevens beschadiging of-verwijdering worden meestal veroorzaakt door een fout in de toepassing of door een humane fout.Data corruption or deletion typically caused by an application bug or human error. Dergelijke fouten zijn toepassingsspecifiek en worden normaal gesp roken niet gedetecteerd door de database service.Such failures are application-specific and typically cannot be detected by the database service.
  • Storing in Data Center, mogelijk veroorzaakt door een natuur ramp.Datacenter outage, possibly caused by a natural disaster. Dit scenario vereist een zekere mate van geo-redundantie met de failover van de toepassing naar een ander Data Center.This scenario requires some level of geo-redundancy with application failover to an alternate datacenter.
  • Upgrade-of onderhouds fouten, onverwachte problemen die optreden tijdens geplande onderhoud van de infra structuur of upgrades kunnen een snelle terugdraai bewerking naar een eerdere database status vereisen.Upgrade or maintenance errors, unanticipated issues that occur during planned infrastructure maintenance or upgrades may require rapid rollback to a prior database state.

SQL Database bevat een architectuur met hoge Beschik baarheidom de lokale hardware-en software fouten te verhelpen, waardoor automatisch herstel van deze fouten wordt gegarandeerd met een sla van maxi maal 99,995% Beschik baarheid.To mitigate the local hardware and software failures, SQL Database includes a high availability architecture, which guarantees automatic recovery from these failures with up to 99.995% availability SLA.

Om uw bedrijf te beschermen tegen gegevens verlies, maken SQL Database en SQL Managed instance automatisch wekelijks volledige back-ups van data bases, differentiële database back-ups om de 12 uur en back-ups van transactie Logboeken om de 5-10 minuten.To protect your business from data loss, SQL Database and SQL Managed Instance automatically create full database backups weekly, differential database backups every 12 hours, and transaction log backups every 5 - 10 minutes. De back-ups worden opgeslagen in RA-GRS-opslag gedurende ten minste 7 dagen voor alle service lagen.The backups are stored in RA-GRS storage for at least 7 days for all service tiers. Alle service lagen, met uitzonde ring van Basic Support Configureer bare Bewaar periode voor back-ups voor herstel naar een bepaald tijdstip, Maxi maal 35 dagen.All service tiers except Basic support configurable backup retention period for point-in-time restore, up to 35 days.

SQL Database en SQL Managed instance bieden ook verschillende functies voor bedrijfs continuïteit die u kunt gebruiken om verschillende niet-geplande scenario's te beperken.SQL Database and SQL Managed Instance also provide several business continuity features that you can use to mitigate various unplanned scenarios.

Een Data Base binnen dezelfde Azure-regio herstellenRecover a database within the same Azure region

U kunt automatische database back-ups gebruiken om een Data Base te herstellen naar een bepaald tijdstip in het verleden.You can use automatic database backups to restore a database to a point in time in the past. Op deze manier kunt u herstellen van gegevens beschadigingen die worden veroorzaakt door menselijke fouten.This way you can recover from data corruptions caused by human errors. Met het herstel naar een bepaald tijdstip kunt u een nieuwe data base maken op dezelfde server die de status van de gegevens van vóór de beschadigde gebeurtenis weergeeft.The point-in-time restore allows you to create a new database in the same server that represents the state of data prior to the corrupting event. Voor de meeste data bases worden de herstel bewerkingen minder dan 12 uur in beslag genomen.For most databases the restore operations takes less than 12 hours. Het kan langer duren om een zeer grote of zeer actieve Data Base te herstellen.It may take longer to recover a very large or very active database. Zie Data Base Recovery Time(Engelstalig) voor meer informatie over herstel tijd.For more information about recovery time, see database recovery time.

Als de maximale ondersteunde Bewaar periode voor back-ups voor PITR (Point-in-time Restore) niet voldoende is voor uw toepassing, kunt u deze uitbreiden door een beleid voor lange termijn retentie (LTR) voor de data base (s) te configureren.If the maximum supported backup retention period for point-in-time restore (PITR) is not sufficient for your application, you can extend it by configuring a long-term retention (LTR) policy for the database(s). Zie lange termijn retentie van back-upsvoor meer informatie.For more information, see Long-term backup retention.

Geo-replicatie met failover-groepen vergelijkenCompare geo-replication with failover groups

Met groepen voor automatische failover worden de implementatie en het gebruik van geo-replicatie vereenvoudigd en worden de extra mogelijkheden toegevoegd, zoals beschreven in de volgende tabel:Auto-failover groups simplify the deployment and usage of geo-replication and add the additional capabilities as described in the following table:

Geo-replicatieGeo-replication Failover-groepenFailover groups
Automatische failoverAutomatic failover NeeNo YesYes
Gelijktijdige failover van meerdere data basesFail over multiple databases simultaneously NeeNo YesYes
De gebruiker moet connection string bijwerken na een failoverUser must update connection string after failover YesYes NeeNo
Ondersteuning voor SQL Managed instanceSQL Managed Instance support NeeNo YesYes
Kan zich in dezelfde regio bevinden als primairCan be in same region as primary YesYes NeeNo
Meerdere replica'sMultiple replicas YesYes NeeNo
Ondersteunt Lees-ScaleSupports read-scale JaYes JaYes

Een Data Base naar de bestaande server herstellenRecover a database to the existing server

Hoewel zeldzame gevallen kan een Azure-Data Center een storing hebben.Although rare, an Azure datacenter can have an outage. Wanneer er een storing optreedt, veroorzaakt deze een bedrijfsonderbreking die mogelijk slechts een paar minuten maar ook enkele uren kan duren.When an outage occurs, it causes a business disruption that might only last a few minutes or might last for hours.

  • Een optie is om te wachten tot de Data Base weer online is wanneer de storing van het Data Center is overschreden.One option is to wait for your database to come back online when the datacenter outage is over. Dit werkt voor toepassingen waarvoor het niet erg is dat de database offline is.This works for applications that can afford to have the database offline. Bijvoorbeeld een ontwikkelingsproject of een gratis proefversie waaraan u niet voortdurend hoeft te werken.For example, a development project or free trial you don't need to work on constantly. Als er een storing in een Data Center optreedt, weet u niet hoe lang de onderbreking kan duren, dus deze optie werkt alleen als u de data base enige tijd niet nodig hebt.When a datacenter has an outage, you do not know how long the outage might last, so this option only works if you don't need your database for a while.
  • Een andere mogelijkheid is om een Data Base op een wille keurige server in een Azure-regio te herstellen met behulp van geo-redundante database back-ups (geo-Restore).Another option is to restore a database on any server in any Azure region using geo-redundant database backups (geo-restore). Geo-Restore gebruikt een geografisch redundante back-up als bron en kan worden gebruikt om een Data Base te herstellen, zelfs als de data base of het Data Center niet toegankelijk is vanwege een storing.Geo-restore uses a geo-redundant backup as its source and can be used to recover a database even if the database or datacenter is inaccessible due to an outage.
  • Ten slotte kunt u snel de uitval van een storing herstellen als u geo-secundair hebt geconfigureerd met behulp van actieve geo-replicatie of een groep met automatische failover voor uw data base of data bases.Finally, you can quickly recover from an outage if you have configured either geo-secondary using active geo-replication or an auto-failover group for your database or databases. Afhankelijk van uw keuze van deze technologieën kunt u hand matig of automatisch een failover gebruiken.Depending on your choice of these technologies, you can use either manual or automatic failover. Hoewel failover zelf slechts een paar seconden duurt, zal de service ten minste één uur duren om deze te activeren.While failover itself takes only a few seconds, the service will take at least 1 hour to activate it. Dit is nodig om ervoor te zorgen dat de failover gerechtvaardigd is door de schaal van de storing.This is necessary to ensure that the failover is justified by the scale of the outage. De failover kan ook leiden tot een klein gegevens verlies als gevolg van de aard van de asynchrone replicatie.Also, the failover may result in small data loss due to the nature of asynchronous replication.

Tijdens het ontwikkelen van uw plan voor bedrijfscontinuïteit moet u weten wat de maximaal acceptabele tijd is voordat de toepassing volledig is hersteld na de verstorende gebeurtenis.As you develop your business continuity plan, you need to understand the maximum acceptable time before the application fully recovers after the disruptive event. De tijd die nodig is om de toepassing volledig te herstellen, wordt de beoogde herstel tijd (RTO) genoemd.The time required for application to fully recover is known as Recovery time objective (RTO). U moet ook inzicht krijgen in de maximale periode van recente gegevens updates (tijds interval) die de toepassing kan verliezen bij het herstellen van een niet-geplande verstorende gebeurtenis.You also need to understand the maximum period of recent data updates (time interval) the application can tolerate losing when recovering from an unplanned disruptive event. Het mogelijke gegevens verlies staat bekend als beoogd herstel punt (RPO).The potential data loss is known as Recovery point objective (RPO).

Verschillende herstel methoden bieden verschillende niveaus van RPO en RTO.Different recovery methods offer different levels of RPO and RTO. U kunt een specifieke herstel methode kiezen of een combi natie van methoden gebruiken om volledige toepassings herstel te krijgen.You can choose a specific recovery method, or use a combination of methods to achieve full application recovery. De volgende tabel vergelijkt RPO en RTO van elke herstel optie.The following table compares RPO and RTO of each recovery option. Met groepen voor automatische failover worden de implementatie en het gebruik van geo-replicatie vereenvoudigd en worden de extra mogelijkheden toegevoegd, zoals beschreven in de volgende tabel.Auto-failover groups simplify the deployment and usage of geo-replication and adds the additional capabilities as described in the following table.

Herstel methodeRecovery method RTORTO RPORPO
Geo-herstel van geo-gerepliceerde back-upsGeo-restore from geo-replicated backups 12 uur12 h 1 uur1 h
Automatische failover-groepenAuto-failover groups 1 uur1 h 5 s5 s
Hand matige data base-failoverManual database failover 30 s30 s 5 s5 s

Notitie

Hand matige data base-failover verwijst naar een failover van een enkele data base naar het geo-gerepliceerde secundair met de niet- geplande modus.Manual database failover refers to failover of a single database to its geo-replicated secondary using the unplanned mode. Zie de tabel eerder in dit artikel voor meer informatie over de RTO en RPO van de automatische failover.See the table earlier in this article for details of the auto-failover RTO and RPO.

Gebruik groepen voor automatische failover als uw toepassing aan een van deze criteria voldoet:Use auto-failover groups if your application meets any of these criteria:

  • Is bedrijfskritiek.Is mission critical.
  • Heeft een service level agreement (SLA) die 12 uur of langer uitval tijd niet toestaat.Has a service level agreement (SLA) that does not allow for 12 hours or more of downtime.
  • Uitval tijd kan leiden tot financiële aansprakelijkheid.Downtime may result in financial liability.
  • Heeft een hoge mate van gegevens wijziging en 1 uur aan gegevens verlies is niet acceptabel.Has a high rate of data change and 1 hour of data loss is not acceptable.
  • De extra kosten van actieve geo-replicatie zijn lager dan de mogelijke financiële verplichting en het bijbehorende bedrijfsverlies.The additional cost of active geo-replication is lower than the potential financial liability and associated loss of business.

U kunt ervoor kiezen om een combi natie van database back-ups en actieve geo-replicatie te gebruiken, afhankelijk van de vereisten van uw toepassing.You may choose to use a combination of database backups and active geo-replication depending upon your application requirements. Zie een toepassing ontwerpen voor nood herstel in de Cloud en strategieën voor nood herstel voor elastische Poolsvoor een bespreking van ontwerp overwegingen voor zelfstandige data bases en voor elastische Pools met behulp van deze functies voor bedrijfs continuïteit.For a discussion of design considerations for stand-alone databases and for elastic pools using these business continuity features, see Design an application for cloud disaster recovery and Elastic pool disaster recovery strategies.

In de volgende secties vindt u een overzicht van de stappen die u kunt herstellen met behulp van database back-ups of actieve geo-replicatie.The following sections provide an overview of the steps to recover using either database backups or active geo-replication. Zie een Data Base herstellen in SQL database van een storingvoor gedetailleerde stappen, zoals plannings vereisten, stappen na herstel en informatie over het simuleren van een storing voor het uitvoeren van een nood herstel analyse.For detailed steps including planning requirements, post recovery steps, and information about how to simulate an outage to perform a disaster recovery drill, see Recover a database in SQL Database from an outage.

Voorbereiden op een storingPrepare for an outage

Ongeacht de functie voor bedrijfscontinuïteit die u gebruikt, moet u:Regardless of the business continuity feature you use, you must:

  • De doel server identificeren en voorbereiden, waaronder IP-firewall regels op server niveau, aanmeldingen en machtigingen op hoofd database niveau.Identify and prepare the target server, including server-level IP firewall rules, logins, and master database level permissions.
  • Bepalen hoe clients en clienttoepassingen naar de nieuwe server worden omgeleid.Determine how to redirect clients and client applications to the new server
  • Andere afhankelijkheden documenteren, zoals controle-instellingen en waarschuwingen.Document other dependencies, such as auditing settings and alerts

Als u zich niet op de juiste manier voorbereidt, kunt u uw toepassingen online brengen na een failover of een herstel bewerking van een Data Base meer tijd en waarschijnlijk ook problemen oplossen op het moment van stress. Dit is een ongeldige combi natie.If you do not prepare properly, bringing your applications online after a failover or a database recovery takes additional time and likely also require troubleshooting at a time of stress - a bad combination.

Een failover uitvoeren naar een secundaire data base met geo-replicatieFail over to a geo-replicated secondary database

Als u actieve groepen voor geo-replicatie of automatische failover gebruikt als herstel mechanisme, kunt u een automatisch failoverbeleid configureren of hand matig niet-geplande failovergebruiken.If you are using active geo-replication or auto-failover groups as your recovery mechanism, you can configure an automatic failover policy or use manual unplanned failover. Zodra de failover is gestart, wordt het secundaire de nieuwe primaire en gereed om nieuwe trans acties te registreren en te reageren op query's-met mini maal gegevens verlies voor de gegevens die nog niet zijn gerepliceerd.Once initiated, the failover causes the secondary to become the new primary and ready to record new transactions and respond to queries - with minimal data loss for the data not yet replicated. Zie een toepassing ontwerpen voor nood herstelin de Cloud voor meer informatie over het ontwerpen van het failoverproces.For information on designing the failover process, see Design an application for cloud disaster recovery.

Notitie

Wanneer het Data Center weer online komt, wordt de oude Primaries automatisch opnieuw verbonden met de nieuwe primaire en worden secundaire data bases.When the datacenter comes back online the old primaries automatically reconnect to the new primary and become secondary databases. Als u de primaire keer terug naar de oorspronkelijke regio wilt verplaatsen, kunt u een geplande failover hand matig initiëren (failback).If you need to relocate the primary back to the original region, you can initiate a planned failover manually (failback).

Geo-herstel uitvoerenPerform a geo-restore

Als u gebruikmaakt van de automatische back-ups met geografisch redundante opslag (standaard ingeschakeld), kunt u de data base herstellen met behulp van geo-Restore.If you are using the automated backups with geo-redundant storage (enabled by default), you can recover the database using geo-restore. Herstel plaatsvindt doorgaans binnen 12 uur, met gegevens verlies van Maxi maal één uur, afhankelijk van het moment waarop de laatste back-up van het logboek is gemaakt en gerepliceerd.Recovery usually takes place within 12 hours - with data loss of up to one hour determined by when the last log backup was taken and replicated. Totdat het herstellen is voltooid, kan de database geen transacties registreren en niet reageren op query's.Until the recovery completes, the database is unable to record any transactions or respond to any queries. Opmerking: met geo-Restore wordt de data base alleen teruggezet naar het laatst beschik bare tijdstip.Note, geo-restore only restores the database to the last available point in time.

Notitie

Als het Data Center weer online komt voordat u de toepassing overschakelt naar de herstelde data base, kunt u het herstel annuleren.If the datacenter comes back online before you switch your application over to the recovered database, you can cancel the recovery.

Taken na failover/hersteltaken uitvoerenPerform post failover / recovery tasks

Na herstel via een van beide herstelmechanismen moet u de volgende aanvullende taken uitvoeren voordat uw gebruikers en toepassingen opnieuw actief zijn:After recovery from either recovery mechanism, you must perform the following additional tasks before your users and applications are back up and running:

  • Clients en client toepassingen omleiden naar de nieuwe server en de data base herstellen.Redirect clients and client applications to the new server and restored database.
  • Zorg ervoor dat de juiste IP-firewall regels op server niveau zijn ingesteld voor gebruikers om verbinding te maken met firewalls op database niveau om de juiste regels in te scha kelen.Ensure appropriate server-level IP firewall rules are in place for users to connect or use database-level firewalls to enable appropriate rules.
  • Zorg ervoor dat de juiste aanmeldingen en machtigingen op hoofd database niveau aanwezig zijn (of gebruik Inge sloten gebruikers).Ensure appropriate logins and master database level permissions are in place (or use contained users).
  • Configureer de controle, indien van toepassing.Configure auditing, as appropriate.
  • Waarschuwingen configureren, indien van toepassing.Configure alerts, as appropriate.

Notitie

Als u een failovergroep gebruikt en verbinding maakt met de data bases met behulp van de Read-Write-listener, wordt de omleiding na een failover automatisch en transparant voor de toepassing uitgevoerd.If you are using a failover group and connect to the databases using the read-write listener, the redirection after failover will happen automatically and transparently to the application.

Een toepassing upgraden met minimale uitvaltijdUpgrade an application with minimal downtime

Soms moet een toepassing offline worden gehaald vanwege gepland onderhoud, zoals een toepassings upgrade.Sometimes an application must be taken offline because of planned maintenance such as an application upgrade. Bij het beheren van toepassings upgrades wordt beschreven hoe u actieve geo-replicatie kunt gebruiken om rolling upgrades van uw Cloud toepassing mogelijk te maken om de downtime tijdens upgrades te minimaliseren en een herstelpad op te geven als er iets verkeerd gaat.Manage application upgrades describes how to use active geo-replication to enable rolling upgrades of your cloud application to minimize downtime during upgrades and provide a recovery path if something goes wrong.

Volgende stappenNext steps

Zie een toepassing ontwerpen voor nood herstel in de Cloud en strategieën voor nood herstel voor elastische Poolsvoor een bespreking van overwegingen voor het ontwerpen van toepassingen voor afzonderlijke data bases en voor elastische Pools.For a discussion of application design considerations for single databases and for elastic pools, see Design an application for cloud disaster recovery and Elastic pool disaster recovery strategies.