Delen via

Automatische back-ups voor Hyperscale-databases

  • Artikel

van toepassing op:Azure SQL Database-

In dit artikel wordt de functie voor automatische back-up met Hyperscale-databases in Azure SQL Database uitgelegd.

Hyperscale-databases maken gebruik van een unieke architectuur met zeer schaalbare opslag- en rekenprestatielagen. Hyperscale-back-ups zijn gebaseerd op momentopnamen en zijn bijna onmiddellijk. Logboekback-ups worden opgeslagen in Azure Storage op lange termijn voor de bewaarperiode voor back-ups.

Een Hyperscale-architectuur vereist niet dezelfde back-upketen als back-ups op basis van bestanden die worden gebruikt in SQL Server en andere SQL Database-lagen, maar voldoet nog steeds aan dezelfde RTO- en RPO-vereisten. Het transactielogboek gedraagt zich op dezelfde manier en maakt hetzelfde herstel naar een bepaald tijdstip mogelijk. In Hyperscale verschillen de back-upfrequentie, opslagkosten, planning, opslagredundantie en herstelmogelijkheden van andere databases in Azure SQL Database.

Back-up- en herstelprestaties

Met opslag- en rekenscheiding kan Hyperscale back-up- en herstelbewerkingen naar de opslaglaag pushen om het resourceverbruik op rekenreplica's te elimineren. Databaseback-ups hebben geen invloed op de prestaties van primaire of secundaire rekenreplica's.

Back-up- en herstelbewerkingen voor Hyperscale-databases zijn snel, ongeacht de gegevensgrootte, omdat ze opslagmomentopnamen gebruiken. Back-up is vrijwel onmiddellijk.

U kunt een database herstellen naar elk tijdstip binnen de bewaarperiode van de back-up door:

  1. Terugkeren naar toepasselijke momentopnamen van bestanden.
  2. Transactielogboeken toepassen om de herstelde database transactioneel consistent te maken.

Herstellen is daarom geen bewerking met een gegevensgrootte die constant blijft. Het herstellen van een Hyperscale-database binnen dezelfde Azure-regio wordt binnen enkele minuten voltooid in plaats van uren of dagen, zelfs voor databases met meerdere terabyte.

Het wijzigen van de opslagredundantie bij het uitvoeren van een herstelbewerking kan leiden tot langere hersteltijden omdat het herstellen de grootte van de gegevens is en daarom de tijd evenredig is met de grootte van de database.

Het maken van nieuwe databases door een bestaande back-up te herstellen of de database te kopiëren, maakt ook gebruik van reken- en opslagscheiding in Hyperscale. U kunt kopieën maken voor ontwikkelings- of testdoeleinden, zelfs van databases met meerdere terabyte, in minuten binnen dezelfde regio wanneer u hetzelfde opslagtype gebruikt.

Back-upretentie

De standaardretentie op korte termijn van back-ups voor Hyperscale-databases is 7 dagen.

Kortetermijnretentie van back-ups in het bereik van 1 tot 35 dagen en langetermijnretentie (LTR) voor Hyperscale-databases zijn algemeen beschikbaar vanaf september 2023. Zie langetermijnretentie : Azure SQL Database en Azure SQL Managed Instancevoor meer informatie.

Back-up planning

Er zijn geen traditionele back-ups van volledige, differentiële en transactielogboeken voor Hyperscale-databases. In plaats daarvan worden er regelmatige opslag-snapshots van gegevensbestanden gemaakt.

De gegenereerde transactielogboeken worden bewaard zoals voor de geconfigureerde bewaarperiode. Tijdens het herstellen worden relevante transactielogboekrecords toegepast op de herstelde momentopname van de opslag. Het resultaat is een transactioneel consistente database zonder gegevensverlies vanaf het opgegeven tijdstip binnen de bewaarperiode.

Verbruik van back-upopslag bewaken

In Hyperscale rapporteren metrische gegevens van Azure Monitor de volgende verbruiksgegevens:

  • Grootte van gegevensback-upopslag (grootte van back-up van momentopnamen)
  • Grootte van gegevensopslag (toegewezen databasegrootte)
  • Grootte van back-upopslag voor logbestanden (transactielogboek-back-upgrootte)

Voer de volgende stappen uit om metrische gegevens over back-up en gegevensopslag weer te geven in Azure Portal:

  1. Ga naar de Hyperscale-database waarvoor u metrische gegevens over back-up en gegevensopslag wilt bewaken.
  2. Selecteer in de sectie Bewaking de pagina Metrische gegevens.
  3. Selecteer uit de vervolgkeuzelijst Metric de gegevensback-upopslag, gegevensopslaggrootteen logboekback-upopslag met de juiste aggregatieregel.

Schermopname van Azure Portal waarin selecties worden weergegeven voor het weergeven van het gebruik van back-upopslag van Hyperscale.

Verbruik van back-upopslag verminderen

Het verbruik van back-upopslag voor een Hyperscale-database is afhankelijk van de retentieperiode, de keuze van de regio, redundantie van back-upopslag en het type workload. Overweeg enkele van de volgende afstemmingstechnieken om het verbruik van back-upopslag voor een Hyperscale-database te verminderen:

  • Verminder de bewaarperiode voor back-ups tot het minimum voor uw behoeften.
  • Vermijd het uitvoeren van grote schrijfbewerkingen, zoals indexonderhoud, vaker dan nodig is. Zie Indexonderhoud optimaliseren om de queryprestaties te verbeteren en het resourceverbruik te verminderenvoor aanbevelingen voor indexonderhoud.
  • Voor grote bewerkingen voor het laden van gegevens kunt u overwegen om gegevenscompressie te gebruiken wanneer dit van toepassing is.
  • Gebruik de tempdb-database in plaats van permanente tabellen in uw toepassingslogica om tijdelijke resultaten en/of tijdelijke gegevens op te slaan.
  • Gebruik lokaal of zone-redundante backupopslag wanneer geo-herstel mogelijkheid niet nodig is (bijvoorbeeld ontwikkel-/testomgevingen).

Kosten voor back-upopslag

De kosten voor hyperscale-back-upopslag zijn afhankelijk van de keuze van regio- en back-upopslagredundantie. Dit is ook afhankelijk van het workloadtype.

Schrijfintensieve werkbelastingen hebben de neiging om gegevenspagina's vaak te wijzigen, wat resulteert in grotere opslagmomentopnamen. Dergelijke workloads genereren ook meer transactielogboeken, wat bijdraagt aan de totale back-upkosten. Back-upopslag wordt in rekening gebracht op basis van gigabytes die per maand worden verbruikt. De hoeveelheid back-upopslag die gelijk is aan de databasegrootte wordt gratis verstrekt. Voor prijsinformatie, zie de Azure SQL Database-prijzen pagina.

Voor Hyperscale wordt factureerbare back-upopslag als volgt berekend:

Total billable backup storage size = (data backup storage size + log backup storage size)

De grootte van de gegevensopslag is niet opgenomen in de factureerbare back-up omdat deze al wordt gefactureerd als toegewezen databaseopslag.

Voor verwijderde Hyperscale-databases worden back-upkosten in rekening gebracht om herstel naar een bepaald tijdstip te ondersteunen voordat ze worden verwijderd. Voor een verwijderde Hyperscale-database wordt factureerbare back-upopslag als volgt berekend:

Total billable backup storage size for deleted Hyperscale database = (data storage size + data backup size + log backup storage size) * (remaining backup retention period after deletion / configured backup retention period)

De grootte van de gegevensopslag wordt opgenomen in de formule omdat toegewezen databaseopslag niet afzonderlijk wordt gefactureerd voor een verwijderde database. Voor een verwijderde database worden gegevens opgeslagen na verwijdering om herstel in te schakelen tijdens de geconfigureerde bewaarperiode voor back-ups.

Factureerbare back-upopslag voor een verwijderde database vermindert geleidelijk na het verwijderen ervan. Het wordt nul wanneer back-ups niet meer worden bewaard en vervolgens herstel niet meer mogelijk is. Als het een permanente verwijdering is en u geen back-ups meer nodig hebt, kunt u kosten optimaliseren door retentie te verminderen voordat u de database verwijdert.

Back-upkosten controleren

Meer informatie over de kosten voor back-upopslag:

  1. Ga in Azure Portal naar Cost Management + Billing.

  2. Selecteer Kostenbeheer>Kostenanalyse.

  3. Selecteer voor scopehet gewenste abonnement.

  4. Filter op de periode en service waarin u geïnteresseerd bent door de volgende stappen uit te voeren:

    1. Voeg een filter toe voor servicenaam.
    2. Kies sql-database uit de vervolgkeuzelijst.
    3. Voeg nog een filter toe voor Meter.
    4. Als u de back-upkosten voor herstel naar een specifiek tijdstip wilt bewaken, selecteert u Data Stored - Backup - RA in de vervolgkeuzelijst.

In de volgende schermopname ziet u een voorbeeld van een kostenanalyse.

Schermopname van Azure Portal waarin de kosten voor Hyperscale Backup-opslag worden weergegeven.

Redundantie van gegevens- en back-upopslag

Hyperscale ondersteunt configureerbare opslagredundantie. Wanneer u een Hyperscale-database maakt, kunt u het gewenste opslagtype kiezen: geografisch zone-redundante opslag met leestoegang (RA-GZRS), geografisch redundante opslag met leestoegang (RA-GRS), zone-redundante opslag (ZRS) of lokaal redundante opslag (LRS).

  • geografisch zone-redundante opslag: kopieert uw back-ups synchroon in drie Azure-beschikbaarheidszones in de primaire regio. vergelijkbaar met zone-redundante opslag (ZRS). Daarnaast worden uw gegevens asynchroon gekopieerd naar één fysieke locatie in de gekoppelde secundaire regio. Het is momenteel alleen beschikbaar in bepaalde regio's.

Zie redundantie van back-upopslagvoor meer informatie over hoe de back-ups worden gerepliceerd voor andere opslagtypen.

Omdat Hyperscale gebruikmaakt van opslagmomentopnamen voor back-ups, delen gegevens en back-ups hetzelfde opslagaccount. Hierdoor is de geselecteerde redundantie van back-upopslag van toepassing op zowel gegevens als back-ups.

Notitie

Overweeg redundantie van back-upopslag zorgvuldig wanneer u een Hyperscale-database maakt, omdat u deze alleen kunt instellen tijdens het maken van de database. U kunt deze instelling niet wijzigen nadat de resource is ingericht.

Gebruik actieve geo-replicatie om redundantie-instellingen voor back-upopslag bij te werken voor een bestaande Hyperscale-database met minimale downtime. U kunt ook de databasekopiegebruiken.

Waarschuwing

  • geo-herstel is uitgeschakeld zodra een database wordt bijgewerkt naar lokaal redundante of zone-redundante opslag.
  • Zone-redundante opslag is momenteel alleen beschikbaar in bepaalde regio's.
  • Geografisch zone-redundante opslag is momenteel alleen beschikbaar in bepaalde regio's.

Een Hyperscale-database herstellen naar een andere regio

Mogelijk moet u uw Hyperscale-database herstellen naar een andere regio dan de huidige regio. Veelvoorkomende redenen zijn een rampenhersteloefening, noodoperatie of verhuizing. De primaire methode is het uitvoeren van een geo-herstel van de database. U gebruikt dezelfde stappen die u zou gebruiken om een andere database in Azure SQL Database te herstellen naar een andere regio:

  1. Maak een -server in de doelregio als u daar nog geen geschikte server hebt. Deze server moet eigendom zijn van hetzelfde abonnement als de oorspronkelijke (bron) server.
  2. Volg de instructies in de sectie geo-herstel van de pagina over het herstellen van een database in Azure SQL Database vanuit automatische back-ups.

Notitie

Omdat de bron en het doel zich in afzonderlijke regio's bevinden, kan de database geen momentopnameopslag delen met de brondatabase, net zoals in niet-geo-herstelbewerkingen. Niet-geo-herstelbewerkingen worden snel voltooid, ongeacht de grootte van de database.

Een geo-herstel van een Hyperscale-database is een operatie met gegevensomvang, zelfs als het doelwit zich in de gekoppelde regio van de geo-gerepliceerde opslag bevindt. Daarom duurt een geo-herstel aanzienlijk langer dan een herstel op een specifiek tijdstip in dezelfde regio.

Als het doel zich in de gekoppelde regio bevindt, bevindt de gegevensoverdracht zich binnen een regio. Deze overdracht is aanzienlijk sneller dan een gegevensoverdracht tussen regio's. Maar het is nog steeds een bewerking met betrekking tot de gegevensomvang.

Als u wilt, kunt u de database naar een andere regio kopiëren. Gebruik deze methode als geo-herstel niet beschikbaar is omdat deze niet wordt ondersteund met het geselecteerde type opslagredundantie. Zie Databasekopie voor Hyperscalevoor meer informatie.

Verwante inhoud

Databaseback-ups zijn een essentieel onderdeel van elke strategie voor bedrijfscontinuïteit en herstel na noodgevallen, omdat ze uw gegevens helpen beschermen tegen onbedoelde beschadiging of verwijdering.