Säkerhetskopiera och återställa i Azure Database for MariaDB

  • Artikel

Viktigt!

Azure Database for MariaDB är på väg att dras tillbaka. Vi rekommenderar starkt att du migrerar till Azure Database for MySQL. Mer information om hur du migrerar till Azure Database for MySQL finns i Vad händer med Azure Database for MariaDB?.

Azure Database for MariaDB skapar automatiskt serversäkerhetskopior och lagrar dem i användarkonfigurerad lokalt redundant eller geo-redundant lagring. Säkerhetskopieringar kan användas för att återställa servern till en vald tidpunkt. Säkerhetskopiering och återställning är en viktig del i strategin för affärskontinuitet, eftersom de skyddar dina data från oavsiktlig skada eller borttagning.

Säkerhetskopior

Azure Database for MariaDB tar säkerhetskopior av datafilerna och transaktionsloggen. Med de här säkerhetskopiorna kan du återställa en server till valfri tidpunkt inom den konfigurerade kvarhållningsperioden för säkerhetskopior. Standardperioden för kvarhållning av säkerhetskopior är sju dagar. Du kan också konfigurera den upp till 35 dagar. Alla säkerhetskopior krypteras med AES 256-bitars kryptering.

Dessa säkerhetskopieringsfiler är inte användarexponerade och kan inte exporteras. Dessa säkerhetskopior kan endast användas för återställningsåtgärder i Azure Database for MariaDB. Du kan använda mysqldump för att kopiera en databas.

Säkerhetskopieringstypen och frekvensen är beroende av serverdelslagringen för servrarna.

Typ och frekvens för säkerhetskopiering

Grundläggande lagringsservrar

Basic-lagringen är serverdelslagringen som stöder basic-nivåservrar. Säkerhetskopior på Grundläggande lagringsservrar är ögonblicksbildbaserade. En fullständig databasögonblicksbild utförs dagligen. Det finns inga differentiella säkerhetskopior som utförs för grundläggande lagringsservrar och alla säkerhetskopieringar av ögonblicksbilder är endast fullständiga databassäkerhetskopior.

Säkerhetskopieringar av transaktionsloggar sker var femte minut.

Lagringsservrar för generell användning med upp till 4 TB lagring

Lagring för generell användning är serverdelslagringen som stöder servern för generell användning och minnesoptimerad nivå . För servrar med allmän lagring upp till 4 TB sker fullständiga säkerhetskopieringar en gång i veckan. Differentiella säkerhetskopior sker två gånger om dagen. Säkerhetskopieringar av transaktionsloggar sker var femte minut. Säkerhetskopiorna på lagring för generell användning upp till 4 TB lagring är inte ögonblicksbildsbaserade och förbrukar I/O-bandbredd vid tidpunkten för säkerhetskopieringen. För stora databaser (> 1 TB) på 4 TB lagring rekommenderar vi att du överväger

  • Etablera fler IOP:er för att ta hänsyn till säkerhetskopierade IO:er ELLER
  • Du kan också migrera till allmän lagring som stöder upp till 16 TB lagring om den underliggande lagringsinfrastrukturen är tillgänglig i dina önskade Azure-regioner. Det finns ingen extra kostnad för generell lagring som stöder upp till 16 TB lagring. Om du vill ha hjälp med migrering till 16 TB-lagring öppnar du ett supportärende från Azure-portalen.

Lagringsservrar för generell användning med upp till 16 TB lagring

I en delmängd av Azure-regioner kan alla nyligen etablerade servrar ha stöd för allmän lagring på upp till 16 TB lagring. Med andra ord är lagring upp till 16 TB lagring standardlagring för generell användning för alla regioner där det stöds. Säkerhetskopior på dessa 16 TB lagringsservrar är ögonblicksbildbaserade. Den första fullständiga säkerhetskopieringen schemaläggs omedelbart efter att en server har skapats. Den första fullständiga säkerhetskopieringen av ögonblicksbilder behålls som serverns bassäkerhetskopia. Efterföljande säkerhetskopieringar av ögonblicksbilder är bara differentiella säkerhetskopieringar.

Differentiella säkerhetskopieringar av ögonblicksbilder görs minst en gång per dag. Differentiella säkerhetskopieringar av ögonblicksbilder sker inte enligt ett fast schema. Differentiella säkerhetskopieringar av ögonblicksbilder sker var 24:e timme om inte transaktionsloggen (binlog i MariaDB) överstiger 50 GB sedan den senaste differentiella säkerhetskopieringen. Högst sex differentiella ögonblicksbilder tillåts under samma dag.

Säkerhetskopieringar av transaktionsloggar sker var femte minut.

Kvarhållningsperiod för säkerhetskopior

Säkerhetskopior behålls baserat på inställningen för kvarhållningsperiod för säkerhetskopior på servern. Du kan välja en kvarhållningsperiod på 7 till 35 dagar. Standardkvarhållningsperioden är sju dagar. Du kan ange kvarhållningsperioden när servern skapas eller senare genom att uppdatera konfigurationen för säkerhetskopiering med hjälp av Azure-portalen eller Azure CLI.

Kvarhållningsperioden för säkerhetskopior styr hur långt tillbaka i tiden en återställning till tidpunkt kan hämtas, eftersom den baseras på tillgängliga säkerhetskopior. Kvarhållningsperioden för säkerhetskopior kan också behandlas som ett återställningsfönster ur ett återställningsperspektiv. Alla säkerhetskopior som krävs för att utföra en återställning till tidpunkt inom kvarhållningsperioden för säkerhetskopior behålls i lagring av säkerhetskopior. Om kvarhållningsperioden för säkerhetskopior till exempel är inställd på sju dagar anses återställningsfönstret vara de senaste sju dagarna. I det här scenariot behålls alla säkerhetskopior som krävs för att återställa servern under de senaste sju dagarna. Med ett kvarhållningsfönster för säkerhetskopior på sju dagar:

  • Servrar med upp till 4 TB lagring behåller upp till två fullständiga databassäkerhetskopior, alla differentiella säkerhetskopior och säkerhetskopieringar av transaktionsloggar som utförts sedan den tidigaste fullständiga databassäkerhetskopian.
  • Servrar med upp till 16 TB lagring behåller den fullständiga databasögonblicksbilden, alla differentiella ögonblicksbilder och säkerhetskopior av transaktionsloggar under de senaste åtta dagarna.

Långsiktig kvarhållning av säkerhetskopior

Långsiktig kvarhållning av säkerhetskopior längre än 35 dagar stöds för närvarande inte internt av tjänsten ännu. Du kan använda mysqldump för att göra säkerhetskopior och lagra dem för långsiktig kvarhållning. Vårt supportteam har bloggat en steg för steg-artikel för att dela hur du kan uppnå det.

Alternativ för säkerhetskopieringsredundans

Azure Database for MariaDB ger flexibiliteten att välja mellan lokalt redundant eller geo-redundant lagring av säkerhetskopiering på nivåerna Generell användning och Minnesoptimerad. När säkerhetskopiorna lagras i geo-redundant lagring lagras de inte bara i den region där servern finns, utan replikeras också till ett kopplat datacenter. Detta ger bättre skydd och möjlighet att återställa servern i en annan region i händelse av ett haveri. Basic-nivån erbjuder endast lokalt redundant lagring av säkerhetskopior.

Flytta från lokalt redundant till geo-redundant lagring av säkerhetskopiering

Det går bara att konfigurera lokalt redundant eller geo-redundant lagring för säkerhetskopiering när servern skapas. När servern har etablerats kan du inte ändra redundansalternativet för lagringsenheten för säkerhetskopior. För att flytta din lagring av säkerhetskopior från lokalt redundant lagring till geo-redundant lagring är det enda alternativet som stöds att skapa en ny server och migrera data med hjälp av dumpning och återställning .

Kostnad för lagring av säkerhetskopior

Azure Database for MariaDB tillhandahåller upp till 100 % av din etablerade serverlagring som lagring av säkerhetskopior utan extra kostnad. Ytterligare lagringsutrymme för säkerhetskopiering som används debiteras i GB per månad. Om du till exempel har etablerat en server med 250 GB lagringsutrymme har du 250 GB extra lagringsutrymme tillgängligt för serversäkerhetskopior utan extra kostnad. Lagring som förbrukas för säkerhetskopieringar på mer än 250 GB debiteras enligt prismodellen.

Du kan använda måttet Backup Storage som används i Azure Monitor som är tillgängligt via Azure-portalen för att övervaka lagringen av säkerhetskopior som används av en server. Måttet Säkerhetskopieringslagring som används representerar summan av lagringen som förbrukas av alla fullständiga databassäkerhetskopieringar, differentiella säkerhetskopior och loggsäkerhetskopior som behålls baserat på kvarhållningsperioden för säkerhetskopior som angetts för servern. Säkerhetskopieringarnas frekvens hanteras av tjänsten och förklaras tidigare. Krävande transaktionsaktivitet på servern kan orsaka att lagringsanvändningen för säkerhetskopior ökar oberoende av databasens totala storlek. För geo-redundant lagring är användningen av säkerhetskopieringslagring dubbelt så stor som för den lokalt redundanta lagringen.

Det främsta sättet att kontrollera lagringskostnaden för säkerhetskopiering är genom att ange lämplig kvarhållningsperiod för säkerhetskopior och välja rätt alternativ för säkerhetskopieringsredundans för att uppfylla dina önskade återställningsmål. Du kan välja en kvarhållningsperiod mellan 7 och 35 dagar. Servrar för generell användning och minnesoptimerad kan välja att ha geo-redundant lagring för säkerhetskopior.

Återställning

I Azure Database for MariaDB skapar en återställning en ny server från den ursprungliga serverns säkerhetskopior och återställer alla databaser som finns på servern.

Det finns två typer av återställning:

  • Återställning till tidpunkt är tillgänglig med antingen alternativ för säkerhetskopieringsredundans och skapar en ny server i samma region som den ursprungliga servern med hjälp av kombinationen av fullständiga säkerhetskopior och säkerhetskopior av transaktionsloggar.
  • Geo-återställning är endast tillgängligt om du har konfigurerat servern för geo-redundant lagring och gör att du kan återställa servern till en annan region med den senaste säkerhetskopieringen.

Den beräknade återställningstiden beror på flera faktorer, däribland databasstorlekarna, transaktionsloggens storlek, nätverkets bandbredd samt det totala antalet databaser som återställs i samma region vid samma tidpunkt. Återställningstiden är mindre än 12 timmar.

Viktigt!

Borttagna servrar kan bara återställas inom fem dagar efter borttagningen, varefter säkerhetskopiorna tas bort. Databassäkerhetskopian kan endast nås och återställas från Den Azure-prenumeration som är värd för servern. Information om hur du återställer en borttagen server finns i dokumenterade steg. Administratörer kan använda hanteringslås för att skydda serverresurser, efter distribution, från oavsiktlig borttagning eller oväntade ändringar.

Återställning till tidpunkt

Oberoende av alternativet för säkerhetskopieringsredundans kan du utföra en återställning till valfri tidpunkt inom kvarhållningsperioden för säkerhetskopior. En ny server skapas i samma Azure-region som den ursprungliga servern. Den skapas med den ursprungliga serverns konfiguration för prisnivån, beräkningsgenerering, antal virtuella kärnor, lagringsstorlek, kvarhållningsperiod för säkerhetskopiering och redundans för säkerhetskopiering.

Återställning till tidpunkt är användbar i flera scenarier. Till exempel när en användare oavsiktligt tar bort data, släpper en viktig tabell eller databas eller om ett program oavsiktligt skriver över bra data med felaktiga data på grund av ett programfel.

Du kan behöva vänta tills nästa säkerhetskopiering av transaktionsloggen har gjorts innan du kan återställa till en tidpunkt under de senaste fem minuterna.

Geo-återställning

Du kan återställa en server till en annan Azure-region där tjänsten är tillgänglig om du har konfigurerat servern för geo-redundanta säkerhetskopior. Servrar som har stöd för upp till 4 TB lagring kan återställas till den geo-kopplade regionen eller till en region som har stöd för upp till 16 TB lagring. För servrar som har stöd för upp till 16 TB lagring kan geo-säkerhetskopior återställas i alla regioner som har stöd för 16 TB-servrar. Se prisnivåerna för Azure Database for MariaDB för listan över regioner som stöds.

Geo-återställning är standardåterställningsalternativet när servern inte är tillgänglig på grund av en incident i den region där servern finns. Om en storskalig incident i en region resulterar i att databasprogrammet inte är tillgängligt kan du återställa en server från de geo-redundanta säkerhetskopiorna till en server i någon annan region. Geo-återställning använder den senaste säkerhetskopieringen av servern. Det finns en fördröjning mellan när en säkerhetskopia görs och när den replikeras till en annan region. Den här fördröjningen kan vara upp till en timme, så om en katastrof inträffar kan dataförlusten vara upp till en timme.

Viktigt!

Om en geo-återställning utförs för en nyligen skapad server kan den inledande synkroniseringen av säkerhetskopior ta mer än 24 timmar beroende på datastorleken eftersom den första fullständiga kopieringstiden för säkerhetskopiering av ögonblicksbilder är mycket högre. Efterföljande säkerhetskopieringar av ögonblicksbilder är inkrementell kopiering och därför går återställningarna snabbare efter 24 timmars serverskapande. Om du utvärderar geo-återställningar för att definiera din RTO rekommenderar vi att du väntar och utvärderar geo-återställning först efter 24 timmars serverskapande för bättre uppskattningar.

Under geo-återställning inkluderar de serverkonfigurationer som kan ändras beräkningsgenerering, vCore, kvarhållningsperiod för säkerhetskopiering och redundansalternativ för säkerhetskopiering. Det går inte att ändra prisnivå (Grundläggande, Generell användning eller Minnesoptimerad) eller lagringsstorlek under geo-återställning.

Den beräknade återställningstiden beror på flera faktorer, däribland databasstorlekarna, transaktionsloggens storlek, nätverkets bandbredd samt det totala antalet databaser som återställs i samma region vid samma tidpunkt. Återställningstiden är mindre än 12 timmar.

Utföra uppgifter efter återställningen

Efter en återställning från någon av återställningsmekanismerna bör du utföra följande uppgifter för att få igång dina användare och program igen:

  • Om den nya servern är avsedd att ersätta den ursprungliga servern omdirigerar du klienter och klientprogram till den nya servern
  • Se till att lämpliga VNet-regler finns på plats för användare att ansluta. Dessa regler kopieras inte från den ursprungliga servern.
  • Se till att lämpliga inloggningar och behörigheter på databasnivå finns på plats
  • Konfigurera aviseringar efter behov

Nästa steg