Delen via

Automatische back-ups voor Hyperscale-databases

  • Artikel

Van toepassing op: Azure SQL Database

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

Hyperscale-databases maken gebruik van een unieke architectuur met zeer schaalbare opslag- en rekenprestatieslagen. 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.

Voor een Hyperscale-architectuur zijn geen volledige, differentiële of logboekback-ups vereist. Als zodanig 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.

Als zodanig is herstellen geen grootte van gegevensbewerkingen die hetzelfde blijven. 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.

Als u de opslagredundantie wijzigt bij het uitvoeren van een herstelbewerking, kan dit leiden tot langere hersteltijden, omdat de herstelbewerking 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.

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

Back-upplanning

Er zijn geen traditionele back-ups van volledige, differentiële en transactielogboeken voor Hyperscale-databases. In plaats daarvan worden normale opslagmomentopnamen 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 logboekback-upopslag (back-upgrootte van transactielogboek)

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 in de vervolgkeuzelijst Metrische gegevens de gegevensback-upopslag, de grootte van de gegevensopslag en de metrische gegevens voor logboekback-upopslag met een geschikte aggregatieregel.

Screenshot of the Azure portal that shows selections for viewing Hyperscale backup storage consumption.

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 verminderen voor 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 redundante of zone-redundante back-upopslag wanneer geo-herstelfunctie overbodig is (bijvoorbeeld ontwikkel-/testomgevingen).

Kosten voor opslag van back-ups

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

Werkbelastingen met veel schrijfbewerkingen hebben meer kans om vaak gegevenspagina's 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. Zie de pagina met prijzen voor Azure SQL Database voor meer informatie.

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 bewaken

Meer informatie over de kosten voor back-upopslag:

  1. Ga in Azure Portal naar Kostenbeheer en facturering.

  2. Selecteer Kostenanalyse van Cost Management>.

  3. Selecteer voor Bereik het 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 in de vervolgkeuzelijst.
    3. Voeg nog een filter toe voor Meter.
    4. Als u de back-upkosten voor herstel naar een bepaald tijdstip wilt bewaken, selecteert u Data Stored - Backup - RA in de vervolgkeuzelijst.

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

Screenshot of the Azure portal that shows Hyperscale Backup storage costs.

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 over 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-upopslag voor 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 databasekopie gebruiken.

Waarschuwing

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 noodherstelbewerking of -analyse of een herlocatie. 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 vanaf 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 gegevensgrootte, zelfs als het doel zich in de gekoppelde regio van de geografisch gerepliceerde opslag bevindt. Daarom duurt een geo-herstel aanzienlijk langer in vergelijking met een herstel naar een bepaald 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 grootte van de gegevensbewerking.

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 Hyperscale voor meer informatie.

Gerelateerde 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.