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

GÄLLER FÖR: Azure Database for MySQL – enskild server

Azure Database for MySQL 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 MySQL säkerhetskopierar 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.

De säkerhetskopierade filerna visas inte för användarna och kan inte exporteras. Dessa säkerhetskopior kan endast användas för återställningsåtgärder i Azure Database for MySQL. Du kan använda mysqldump för att kopiera en databas.

Säkerhetskopieringstypen och frekvensen beror på 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 v1 (stöder 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 för allmän lagring 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.

V2-servrar för generell lagring (stöder 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 säkerhetskopieringen schemaläggs omedelbart efter att en server har skapats. Säkerhetskopior av ögonblicksbilder görs en gång dagligen. Säkerhetskopieringar av transaktionsloggar sker var femte minut.

Mer information om grundläggande och allmän lagring finns i lagringsdokumentationen.

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 7 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å 7 dagar anses återställningsfönstret vara de senaste 7 dagarna. I det här scenariot behålls alla säkerhetskopior som krävs för att återställa servern under de senaste 7 dagarna. Med ett kvarhållningsfönster för säkerhetskopior på sju dagar:

• Servrar för generell lagring v1 (med stöd för upp till 4 TB lagring) behåller upp till 2 fullständiga databassäkerhetskopior, alla differentiella säkerhetskopior och säkerhetskopieringar av transaktionsloggar som utförts sedan den tidigaste fullständiga databassäkerhetskopian.
• Generell lagring v2-servrar (med stöd för upp till 16 TB lagring) behåller de fullständiga databasögonblicksbilderna och säkerhetskopieringarna av transaktionsloggar under de senaste 8 dagarna.

Långsiktig kvarhållning

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 har möjlighet att använda mysqldump för att ta 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 MySQL 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. Den här geo-redundansen ger bättre skydd och möjlighet att återställa servern i en annan region i händelse av en katastrof. 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 alternativet för redundant lagring 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 MySQL erbjuder upp till 100 % av din etablerade serverlagring som lagringsenhet för 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

När du utför en återställning i Azure Database for MySQL skapas en ny server från den ursprungliga serverns säkerhetskopior och alla databaser som finns på servern återställs. Återställning stöds för närvarande inte om den ursprungliga servern är i stoppat tillstånd.

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 tiden för serverns återställning beror på flera faktorer:

• Storleken på databaserna
• Antalet transaktionsloggar som ingår
• Mängden aktivitet som måste spelas upp igen för att återställa till återställningspunkten
• Nätverksbandbredden om återställningen är till en annan region
• Antalet samtidiga återställningsbegäranden som bearbetas i målregionen
• Förekomsten av primärnyckel i tabellerna i databasen. Överväg att lägga till primärnyckel för alla tabeller i databasen för snabbare återställning. Om du vill kontrollera om dina tabeller har primärnyckel kan du använda följande fråga:

select tab.table_schema as database_name, tab.table_name from information_schema.tables tab left join information_schema.table_constraints tco on tab.table_schema = tco.table_schema and tab.table_name = tco.table_name and tco.constraint_type = 'PRIMARY KEY' where tco.constraint_type is null and tab.table_schema not in('mysql', 'information_schema', 'performance_schema', 'sys') and tab.table_type = 'BASE TABLE' order by tab.table_schema, tab.table_name;

Återställningen ta flera timmar för en stor eller mycket aktiv databas. Efter ett långvarigt avbrott i en region kan ett stort antal förfrågningar om geo-återställning för haveriberedskap initieras ungefär samtidigt. Om många sådana förfrågningar körs samtidigt kan återställningstiden för enskilda databaser öka. De flesta databasåterställningar slutförs på mindre än 12 timmar.

Å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å, 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.

• Lagringsservrar för generell användning v1 (med stöd för upp till 4 TB lagring) kan återställas till den geo-kopplade regionen eller till valfri Azure-region som stöder Azure Database for MySQL – enskild servertjänst.
• Generell lagring v2-servrar (med stöd för upp till 16 TB lagring) kan bara återställas till Azure-regioner som stöder infrastruktur för generell lagring v2-servrar. Listan över de regioner som stöds finns i prisnivåer för Azure Database for MySQL.

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.

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. Ändring av prisnivå (Basic, Generell användning eller Minnesoptimerad) eller lagringsstorlek under geo-återställning stöds inte.

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 vanligtvis 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

• Mer information om affärskontinuitet finns i översikten över affärskontinuitet.
• Information om hur du återställer till en tidpunkt med hjälp av Azure-portalen finns i Återställa servern till en tidpunkt med hjälp av Azure-portalen.
• Om du vill återställa till en tidpunkt med Hjälp av Azure CLI kan du läsa återställa servern till en tidpunkt med CLI.