Dela via

Säkerhetskopiering och återställning i Azure Database for MySQL – flexibel server

  • Artikel

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

Azure Database for MySQL – flexibel server skapar automatiskt serversäkerhetskopior och lagrar dem på ett säkert sätt i lokal redundant lagring i regionen. 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.

Översikt över Backup

Azure Database for MySQL – flexibel server stöder två typer av säkerhetskopior för att ge en förbättrad flexibilitet för att upprätthålla säkerhetskopior av affärskritiska data.

Automatisk säkerhetskopiering

Azure Database for MySQL – flexibel server tar säkerhetskopior av ögonblicksbilder av datafilerna och lagrar dem i en lokal redundant lagring. Servern utför också säkerhetskopiering av transaktionsloggar och lagrar dem även i lokal redundant lagring. 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 säkerhetskopieringen av databasen från 1 till 35 dagar. Alla säkerhetskopior krypteras med AES 256-bitarskryptering för de data som lagras i vila.

Säkerhetskopiering på begäran

Med Azure Database for MySQL – flexibel server kan du också utlösa säkerhetskopieringar på begäran av produktionsarbetsbelastningen, utöver de automatiserade säkerhetskopior som tas av tjänsten och lagra den i enlighet med serverns kvarhållningsprincip för säkerhetskopiering. Du kan använda dessa säkerhetskopior som en snabbaste återställningspunkt för att utföra en återställning till tidpunkt för att minska återställningstiderna med upp till 90 %. Standardperioden för kvarhållning av säkerhetskopior är sju dagar. Du kan också konfigurera säkerhetskopieringen av databasen från 1 till 35 dagar. Du kan utlösa totalt 50 säkerhetskopieringar på begäran från portalen. Alla säkerhetskopior krypteras med AES 256-bitarskryptering för de data som lagras i vila.

Dessa säkerhetskopieringsfiler kan inte exporteras. Säkerhetskopiorna kan endast användas för återställningsåtgärder i Azure Database for MySQL – flexibel server. Du kan också använda mysqldump från en MySQL-klient för att kopiera en databas.

Säkerhetskopieringsfrekvens

Säkerhetskopior på flexibla servrar ä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. Om en schemalagd säkerhetskopiering misslyckas försöker vår säkerhetskopieringstjänst att göra en säkerhetskopiering var 20:e minut tills en lyckad säkerhetskopiering görs. Dessa säkerhetskopieringsfel kan inträffa på grund av stora transaktionsproduktionsbelastningar på serverinstansen.

Kommentar

  • Om servern har en hög transaktionsbelastning, vilket resulterar i större och snabbare växande binlogfiler, utför säkerhetskopieringstjänsten flera säkerhetskopior per dag för att säkerställa tillförlitlig och snabbare återställning med hjälp av dessa säkerhetskopior.
  • För 5,7-servrar kan långvariga/stora transaktioner förhindra hämtning av globalt instansnivålås som krävs för lyckad daglig säkerhetskopiering. I sådana scenarier kan dagliga säkerhetskopieringar misslyckas. Lös problemet genom att antingen avsluta den långvariga transaktionen eller starta om servern. För att säkerställa smidigare åtgärder rekommenderar vi att du uppgraderar dina MySQL 5.7-servrar till version 8.0 med hjälp av en större versionsuppgradering.

Alternativ för säkerhetskopieringsredundans

Azure Database for MySQL – flexibel server lagrar flera kopior av dina säkerhetskopior så att dina data skyddas från planerade och oplanerade händelser, inklusive tillfälliga maskinvarufel, nätverks- eller strömavbrott och massiva naturkatastrofer. Azure Database for MySQL – flexibel server ger flexibiliteten att välja mellan lokalt redundant, zonredundant eller geo-redundant säkerhetskopieringslagring på nivåerna Basic, Generell användning och Affärskritisk. Som standard är Azure Database for MySQL – flexibel server för säkerhetskopiering lokalt redundant för servrar med hög tillgänglighet i samma zon (HA) eller ingen konfiguration med hög tillgänglighet och zonredundant för servrar med zonredundant HA-konfiguration.

Säkerhetskopieringsredundans säkerställer att databasen uppfyller sina tillgänglighets- och hållbarhetsmål även vid fel och Azure Database for MySQL – flexibel server utökar tre alternativ till användare –

  • Lokalt redundant lagring av säkerhetskopiering : När säkerhetskopiorna lagras i lokalt redundant lagring av säkerhetskopior lagras flera kopior av säkerhetskopior i samma datacenter. Det här alternativet skyddar dina data mot serverrack och enhetsfel. Detta ger också minst 99,99999999999% (11 9:s) hållbarhet för säkerhetskopieringsobjekt under ett visst år. Som standard är säkerhetskopieringslagring för servrar med hög tillgänglighet i samma zon (HA) eller ingen konfiguration med hög tillgänglighet inställd på lokalt redundant.

  • Zonredundant lagring av säkerhetskopiering: När säkerhetskopiorna lagras i zonredundant lagring av säkerhetskopior lagras inte bara flera kopior i tillgänglighetszonen där servern finns, utan replikeras också till en annan tillgänglighetszon i samma region. Det här alternativet kan användas för scenarier som kräver hög tillgänglighet eller för att begränsa replikering av data till inom ett land/en region för att uppfylla kraven på datahemvist. Detta ger också minst 99,999999999999% (12 9:s) hållbarhet för säkerhetskopieringsobjekt under ett visst år. Man kan välja alternativet Zonredundant hög tillgänglighet på servern för att säkerställa zonredundant lagring av säkerhetskopior. Hög tillgänglighet för en server kan inaktiveras efter skapande, men lagringen för säkerhetskopior är fortfarande zonredundant.

  • Geo-redundant lagring av säkerhetskopiering : När säkerhetskopiorna lagras i geo-redundant lagring av säkerhetskopior lagras inte bara flera kopior i den region där servern finns, utan replikeras också till dess geo-kopplade region. Detta ger bättre skydd och möjlighet att återställa servern i en annan region i händelse av ett haveri. Detta ger också minst 99,9999999999999999999% (16 9: s) hållbarhet för säkerhetskopieringsobjekt under ett visst år. Man kan aktivera alternativet Geo-Redundans på servern för att säkerställa geo-redundant lagring av säkerhetskopior. Dessutom kan du gå från lokalt redundant lagring till geo-redundant lagring efter att servern har skapats. Geo-redundans stöds för servrar som finns i någon av de Azure-parkopplade regionerna.

Kommentar

Zonredundant hög tillgänglighet för att stödja zonredundans visas endast som en tidsåtgärd för att skapa. För närvarande kan geo-redundans endast aktiveras/inaktiveras när servern skapas för en zonredundant server med hög tillgänglighet.

Flytta från andra lagringsalternativ för säkerhetskopiering till geo-redundant lagring av säkerhetskopior

Du kan flytta din befintliga lagring av säkerhetskopior till geo-redundant lagring på följande föreslagna sätt:

  • Flytta från lokalt redundant till geo-redundant lagring av säkerhetskopiering – Om du vill flytta lagringen för säkerhetskopior från lokalt redundant lagring till geo-redundant lagring kan du ändra konfigurationen av Compute + Storage-servern från Azure Portal för att aktivera geo-redundans för den lokalt redundanta källservern. Samma zonredundanta HA-servrar kan också återställas som en geo-redundant server på ett liknande sätt som den underliggande lagringen för säkerhetskopiering är lokalt redundant för samma sak.

  • Flytta från zonredundant till geo-redundant lagring av säkerhetskopiering – Azure Database for MySQL – flexibel server stöder inte zonredundant lagring till geo-redundant lagringskonvertering via inställningar för beräkning och lagring när servern har etablerats. För att flytta din lagring av säkerhetskopior från zonredundant lagring till geo-redundant lagring finns det två alternativ: a) Använd PITR (återställning till tidpunkt) för att återställa servern med önskad konfiguration. b) Skapa en ny server med önskad konfiguration och migrera data med dump och återställning.

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å 1 till 35 dagar med en standardkvarhållningsperiod på sju dagar. Du kan ange kvarhållningsperioden när servern skapas eller senare genom att uppdatera säkerhetskopieringskonfigurationen med hjälp av Azure Portal.

Kvarhållningsperioden för säkerhetskopior styr hur långt tillbaka i tiden en återställningsåtgärd kan utföras vid tidpunkt, 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. Till exempel – om kvarhållningsperioden för säkerhetskopior ä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 lagras databasögonblicksbilder och säkerhetskopior av transaktionsloggar under de senaste åtta dagarna (1 dag före fönstret).

Kostnad för lagring av säkerhetskopior

Azure Database for MySQL – flexibel server 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 lagringsutrymme tillgängligt för serversäkerhetskopior utan extra kostnad. Om den dagliga säkerhetskopieringsanvändningen är 25 GB kan du ha upp till 10 dagars kostnadsfri säkerhetskopieringslagring. 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 i Azure Portal 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 databassäkerhetskopior och loggsäkerhetskopior som behålls baserat på kvarhållningsperioden för säkerhetskopior som angetts för servern. Krävande transaktionsaktivitet på servern kan orsaka att lagringsanvändningen för säkerhetskopior ökar oberoende av databasens totala storlek. Säkerhetskopieringslagring som används för en geo-redundant server är dubbelt så stor som för en lokalt redundant server.

Det primära sättet att kontrollera kostnaden för lagring av säkerhetskopior är genom att ange lämplig kvarhållningsperiod för säkerhetskopior. Du kan välja en kvarhållningsperiod mellan 1 och 35 dagar.

Viktigt!

Säkerhetskopieringar från en databasserver som konfigurerats i en zonredundant konfiguration med hög tillgänglighet sker från den primära databasservern eftersom kostnaderna är minimala med säkerhetskopieringar av ögonblicksbilder.

Visa tillgängliga fullständiga säkerhetskopior

Bladet Säkerhetskopiering och återställning i Azure Portal innehåller en fullständig lista över de fullständiga säkerhetskopior som är tillgängliga för dig vid en viss tidpunkt. Detta inkluderar automatiserade säkerhetskopieringar samt säkerhetskopieringar på begäran. Man kan använda det här bladet för att visa tidsstämplar för slutförande för alla tillgängliga fullständiga säkerhetskopior inom serverns kvarhållningsperiod och för att utföra återställningsåtgärder med hjälp av dessa fullständiga säkerhetskopior. Listan över tillgängliga säkerhetskopior innehåller alla fullständiga säkerhetskopior inom kvarhållningsperioden, en tidsstämpel som visar det lyckade slutförandet, en tidsstämpel som anger hur länge en säkerhetskopia ska behållas och en återställningsåtgärd.

Återställning

I Azure Database for MySQL – flexibel server skapar en återställning en ny server från den ursprungliga serverns säkerhetskopior. Det finns två typer av återställning:

  • Återställning till tidpunkt: är tillgänglig med alternativet för säkerhetskopieringsredundans och skapar en ny server i samma region som den ursprungliga servern.
  • 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 antingen en geo-länkad region eller någon annan Azure Support region där flexibel server är tillgänglig.

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.

Kommentar

En server med hög tillgänglighet blir icke-HA (hög tillgänglighet inaktiverad) efter återställning för både återställning till tidpunkt och geo-återställning.

Återställning till tidpunkt

I Azure Database for MySQL – flexibel server skapar en ny server från den flexibla serverns säkerhetskopior i samma region som källservern när du utför en återställning till tidpunkt. Den skapas med den ursprungliga serverns konfiguration för beräkningsnivån, antal virtuella kärnor, lagringsstorlek, kvarhållningsperiod för säkerhetskopiering och redundans för säkerhetskopiering. Taggar och inställningar som virtuellt nätverk och brandvägg ärvs också från källservern. Den återställda serverns beräknings- och lagringsnivå, konfiguration och säkerhetsinställningar kan ändras när återställningen har slutförts.

Kommentar

Det finns två serverparametrar som återställs till standardvärden (och kopieras inte över från den primära servern) efter återställningsåtgärden

  • time_zone – Det här ställer in standardvärde för SYSTEM
  • event_scheduler – För MySQL version 5.7-servrar stängs serverparametern event_scheduler automatiskt av när säkerhetskopieringen initieras och serverparametern event_scheduler aktiveras igen när säkerhetskopieringen har slutförts. I MySQL version 8.0 för Azure Database for MySQL – flexibel server påverkas event_scheduler inte under säkerhetskopieringar. För att säkerställa smidigare åtgärder rekommenderar vi att du uppgraderar dina MySQL 5.7-servrar till version 8.0 med hjälp av en större versionsuppgradering.

Återställning till tidpunkt är användbar i flera scenarier. Några av de användningsfall som är vanliga är -

  • När en användare av misstag tar bort data i databasen
  • Användaren släpper en viktig tabell eller databas
  • Användarprogrammet skriver av misstag över bra data med felaktiga data på grund av ett programfel.

Du kan välja mellan den senaste återställningspunkten, den anpassade återställningspunkten och den snabbaste återställningspunkten (återställning med fullständig säkerhetskopiering) via Azure Portal.

  • Senaste återställningspunkten: Det senaste återställningspunktsalternativet hjälper dig att återställa servern till tidsstämpeln när återställningsåtgärden utlöstes. Det här alternativet är användbart för att snabbt återställa servern till det mest uppdaterade tillståndet.
  • Anpassad återställningspunkt: Med det här alternativet kan du välja valfri tidpunkt inom den kvarhållningsperiod som definierats för den här servern. Det här alternativet är användbart för att återställa servern vid den exakta tidpunkten för att återställa från ett användarfel.
  • Snabbaste återställningspunkt: Med det här alternativet kan användarna återställa servern så snabbt som möjligt under en viss dag inom den kvarhållningsperiod som definierats för servern. Den snabbaste återställningen är möjlig genom att välja den återställningspunkt i tiden då den fullständiga säkerhetskopieringen har slutförts. Den här återställningsåtgärden återställer helt enkelt den fullständiga säkerhetskopieringen av ögonblicksbilder och garanterar inte återställning eller återställning av loggar, vilket gör den snabb. Vi rekommenderar att du väljer en fullständig tidsstämpel för säkerhetskopiering som är större än den tidigaste återställningspunkten för en lyckad återställningsåtgärd.

Den uppskattade återställningstiden beror på flera faktorer, inklusive databasstorlekarna, storleken på säkerhetskopieringen av transaktionsloggen, beräkningsstorleken för SKU:n och tidpunkten för återställningen. Återställningen av transaktionsloggen är den mest tidskrävande delen av återställningsprocessen. Om återställningstiden väljs närmare schemat för säkerhetskopiering av ögonblicksbilder går återställningsåtgärderna snabbare eftersom transaktionsloggprogrammet är minimalt. För att beräkna den exakta återställningstiden för servern rekommenderar vi starkt att du testar den i din miljö eftersom den har för många miljöspecifika variabler.

Viktigt!

Om du återställer en Azure Database for MySQL Flexible Server-instans som konfigurerats med zonredundant hög tillgänglighet, konfigureras den återställda servern i samma region och zon som din primära server och distribueras som en enskild server i ett icke-HA-läge. Se zonredundant hög tillgänglighet för flexibel server.

Viktigt!

Du kan återställa en borttagen Azure Database for MySQL Flexible Server-resurs inom 5 dagar från det att servern togs bort. En detaljerad guide 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.

Geo-återställning

Du kan återställa en server till dess geo-kopplade region där tjänsten är tillgänglig om du har konfigurerat servern för geo-redundanta säkerhetskopior eller någon annan Azure Support region där Azure Database for MySQL – flexibel server är tillgänglig. Möjlighet att återställa till alla icke-kopplade Azure Support region (förutom Brazil South, USGov Virginia och West US 3) kallas "Universell geo-återställning".

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.

Geo-återställning kan också utföras på en stoppad server som utnyttjar Azure CLI. Läs Återställa Azure Database for MySQL – flexibel server med Azure CLI för att lära dig mer om geo-återställning av en server med Azure CLI.

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.

Kommentar

Om du geo-återställer en Azure Database for MySQL– flexibel serverinstans som konfigurerats med zonredundant hög tillgänglighet konfigureras den återställda servern i den geo-kopplade regionen och samma zon som din primära server och distribueras som en enda Azure Database for MySQL– flexibel serverinstans i ett icke-HA-läge. Se zonredundant hög tillgänglighet för Azure Database for MySQL – flexibel server.

Viktigt!

När den primära regionen är nere kan du inte skapa geo-redundanta servrar i respektive geo-parkopplade region eftersom lagring inte kan etableras i den primära regionen. Du måste vänta tills den primära regionen har etablerat geo-redundanta servrar i den geo-kopplade regionen. Med den primära regionen nere kan du fortfarande geo-återställa källservern till den geo-kopplade regionen genom att inaktivera alternativet geo-redundans i inställningarna För beräkning + lagring Konfigurera server i återställningsportalen och återställa som en lokalt redundant server för att säkerställa affärskontinuitet.

Utföra uppgifter efter återställningen

Efter en återställning från antingen den senaste återställningspunkten eller återställningsmekanismen för anpassad återställningspunkt 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 brandväggsregler på servernivå och regler för virtuella nätverk finns på plats för användare att ansluta.
  • Se till att lämpliga inloggningar och behörigheter på databasnivå finns på plats.
  • Konfigurera aviseringar efter behov.

Långsiktig kvarhållning (förhandsversion)

Azure Backup och Azure Database for MySQL – flexibla servertjänster har skapat en långsiktig säkerhetskopieringslösning i företagsklass för Azure Database for MySQL– flexibla serverinstanser som behåller säkerhetskopior i upp till 10 år. Du kan använda långsiktig kvarhållning oberoende av varandra eller utöver den automatiserade säkerhetskopieringslösning som erbjuds av Azure Database for MySQL – flexibel server, som erbjuder kvarhållning på upp till 35 dagar. Automatiserade säkerhetskopieringar är säkerhetskopieringar av ögonblicksbilder som lämpar sig för driftåterställning, särskilt när du vill återställa från de senaste säkerhetskopiorna. Långsiktiga säkerhetskopior hjälper dig med dina efterlevnadsbehov och granskningsbehov. Utöver långsiktig kvarhållning erbjuder lösningen följande funktioner:

  • Kundkontrollerade schemalagda säkerhetskopieringar och säkerhetskopieringar på begäran
  • Hantera och övervaka alla säkerhetskopieringsrelaterade åtgärder och jobb mellan servrar, resursgrupper, platser, prenumerationer och klientorganisationer från en enda fönsterruta med namnet Backup Center.
  • Säkerhetskopior som lagras i separata säkerhets- och feldomäner. Om källservern eller prenumerationen äventyras förblir säkerhetskopiorna säkra i säkerhetskopieringsvalvet (i Azure Backup-hanterade lagringskonton).

Begränsningar och överväganden

  • I förhandsversionen är LTR-återställning för närvarande tillgänglig som RestoreasFiles till lagringskonton. RestoreasServer-funktionen kommer att läggas till i framtiden.
  • Stöd för att skapa och hantera LTR via Azure CLI stöds för närvarande inte.

Mer information om hur du utför en långsiktig säkerhetskopiering finns i guiden

Säkerhetskopiering och export på begäran (förhandsversion)

Azure Database for MySQL – flexibel server erbjuder nu möjligheten att utlösa en fysisk säkerhetskopiering på begäran för tillfället av servern och exportera den till ett Azure Storage-konto (Azure Blob Storage). När de har exporterats kan dessa säkerhetskopior användas för dataåterställning, migrering och redundans. Dessa exporterade fysiska säkerhetskopieringsfiler kan användas för att återställa tillbaka till en lokal MySQL-server för att uppfylla organisationens gransknings-/efterlevnads-/arkiveringsbehov. Funktionen är för närvarande i offentlig förhandsversion och är endast tillgänglig i offentliga molnregioner.

Mer information om exportsäkerhetskopiering finns i guiden

Vanliga frågor (FAQ)

  • Hur gör jag för att säkerhetskopiera min server?

    Som standard möjliggör Azure Database for MySQL – flexibel server automatiska säkerhetskopieringar av hela servern (som omfattar alla databaser som skapats) med en standard kvarhållningsperiod på 7 dagar. Du kan också utlösa en manuell säkerhetskopiering med hjälp av säkerhetskopieringsfunktionen på begäran. Det andra sättet att manuellt ta en säkerhetskopia är genom att använda communityverktyg som mysqldump som dokumenteras här eller mydumper som dokumenteras här. Om du vill säkerhetskopiera en Azure Database for MySQL – flexibel serverinstans till en Blob Storage kan du läsa vår tech community-blogg Backup Azure Database for MySQL – flexibel server till en Blob Storage.

  • Kan jag konfigurera att automatiska säkerhetskopieringar ska behållas på lång sikt?

    Nej, för närvarande stöder vi bara högst 35 dagars automatisk kvarhållning av säkerhetskopior. Du kan göra manuella säkerhetskopieringar och använda dem för långsiktig kvarhållning.

  • Vilka är säkerhetskopieringsfönstren för min server? Kan jag anpassa den?

    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. Säkerhetskopieringsfönster hanteras i sig av Azure och kan inte anpassas.

  • Är mina säkerhetskopior krypterade?

    Alla Azure Database for MySQL – flexibel server-data, säkerhetskopior och temporära filer som skapas under frågekörningen krypteras med hjälp av AES 256-bitarskryptering. Lagringskrypteringen är alltid aktiv och kan inte inaktiveras.

  • Kan jag återställa en eller flera databaser?

    Det går inte att återställa en eller flera databaser eller tabeller. Om du vill återställa specifika databaser utför du en återställning till tidpunkt och extraherar sedan de tabeller eller databaser som behövs.

  • Är min server tillgänglig under säkerhetskopieringsfönstret?

    Ja. Säkerhetskopieringar är onlineåtgärder och är ögonblicksbildbaserade. Åtgärden för ögonblicksbilder tar bara några sekunder och stör inte produktionsarbetsbelastningar, vilket säkerställer serverns höga tillgänglighet.

  • Behöver vi ta hänsyn till säkerhetskopieringsfönstret när du konfigurerar underhållsperioden för servern?

    Nej, säkerhetskopior utlöses internt som en del av den hanterade tjänsten och har ingen betydelse för fönstret Hanterat underhåll.

  • Var lagras mina automatiserade säkerhetskopior och hur hanterar jag deras kvarhållning?

    Azure Database for MySQL – flexibel server skapar automatiskt serversäkerhetskopior och lagrar dem i användarkonfigurerad, lokalt redundant lagring eller i geo-redundant lagring. Dessa säkerhetskopierade filer kan inte exporteras. Standardperioden för kvarhållning av säkerhetskopior är sju dagar. Du kan också konfigurera säkerhetskopieringen av databasen från 1 till 35 dagar.

  • Hur verifierar jag mina säkerhetskopior?

    Det bästa sättet att verifiera tillgängligheten för slutförda säkerhetskopior är att visa de fullständiga automatiserade säkerhetskopior som gjorts inom kvarhållningsperioden på bladet Säkerhetskopiering och återställning. Om en säkerhetskopia misslyckas visas den inte i listan över tillgängliga säkerhetskopior, och säkerhetskopieringstjänsten försöker var 20:e minut att ta en säkerhetskopia tills en lyckad säkerhetskopiering har gjorts. Dessa säkerhetskopieringsfel beror på stora transaktionsproduktionsbelastningar på servern.

  • Var kan jag se användningen av säkerhetskopiering?

    I Azure Portal, under fliken Övervakning – Mått, hittar du måttet Backup Storage Used som kan hjälpa dig att övervaka den totala användningen av säkerhetskopiering.

  • Vad händer med mina säkerhetskopior om jag tar bort min server?

    Om du tar bort servern tas även alla säkerhetskopior som tillhör servern bort och kan inte återställas. Administratörer kan använda hanteringslås för att skydda serverresurser efter distributionen från oavsiktlig borttagning eller oväntade ändringar.

  • Vad händer med mina säkerhetskopior när jag återställer en server?

    Om du återställer en server resulterar det alltid i att en ny net-server skapas som har återställts med hjälp av den ursprungliga serverns säkerhetskopior. Den gamla säkerhetskopian från den ursprungliga servern kopieras inte över till den nyligen återställde servern och den förblir med den ursprungliga servern. För den nyligen skapade servern schemaläggs dock den första säkerhetskopieringen av ögonblicksbilden omedelbart efter att en server har skapats och tjänsten ser till att dagliga automatiserade säkerhetskopieringar tas och lagras enligt den konfigurerade kvarhållningsperioden för servern.

  • Hur debiteras och debiteras jag för min användning av säkerhetskopior?

    Azure Database for MySQL – flexibel server tillhandahåller upp till 100 % av din etablerade serverlagring som lagring av säkerhetskopior utan extra kostnad. Allt mer lagringsutrymme för säkerhetskopiering som används debiteras i GB per månad enligt prismodellen. Fakturering av lagring av säkerhetskopior styrs också av den valda kvarhållningsperioden för säkerhetskopior och alternativet för säkerhetskopieringsredundans, förutom transaktionsaktiviteten på servern, vilket påverkar den totala lagringen av säkerhetskopior som används direkt.

  • Hur behålls säkerhetskopior för stoppade servrar?

    Inga nya säkerhetskopior utförs för stoppade servrar. Alla äldre säkerhetskopior (inom kvarhållningsfönstret) vid tidpunkten för att stoppa servern behålls tills servern startas om, efter vilken kvarhållning av säkerhetskopior för den aktiva servern styrs av dess kvarhållningsfönster för säkerhetskopior.

  • Hur debiteras jag för säkerhetskopior för en stoppad server?

    När serverinstansen har stoppats debiteras du för etablerad lagring (inklusive etablerad IOPS) och lagring av säkerhetskopior (säkerhetskopior som lagras i det angivna kvarhållningsfönstret). Lagringsutrymme för kostnadsfri säkerhetskopiering är begränsat till storleken på din etablerade databas och gäller endast för aktiva servrar.

  • Hur skyddas mina säkerhetskopierade data?

    Azure Database for MySQL – flexibel server skyddar dina säkerhetskopieringsdata genom att blockera åtgärder som kan leda till förlust av återställningspunkter under den konfigurerade kvarhållningsperioden. Säkerhetskopior som görs under kvarhållningsperioden kan bara läsas för återställning och tas bort efter kvarhållningsperioden. Dessutom krypteras alla säkerhetskopior i Azure Database for MySQL – flexibel server med AES 256-bitarskryptering för de data som lagras i vila.

  • Hur påverkar en PITR-åtgärd (Point-In-Time Restore) IOPS-användningen?

    Under en PITR-åtgärd i Azure Database for MySQL – Flexibel server skapas en ny server och data kopieras från källserverns lagring till den nya serverns lagring. Den här processen resulterar i en ökad IOPS-användning på källservern. Den här ökningen av IOPS-användningen är en normal förekomst och tyder inte på några problem med källservern eller PITR-åtgärden. När PITR-åtgärden är klar återgår IOPS-användningen på källservern till sina vanliga nivåer.

  • Hur gör jag för att återställa servern? Azure Portal stöder återställning till tidpunkt för alla servrar, så att användarna kan återställa till de senaste eller anpassade återställningspunkterna. Information om hur du återställer servern manuellt från säkerhetskopiorna som görs av mysqldump/myDumper finns i Återställa databasen med myLoader.

  • Varför tar återställningen så lång tid?

    Den beräknade tiden för serverns återställning beror på flera faktorer:

    • Databasernas storlek. Som en del av återställningsprocessen måste databasen hydratiseras från den senaste fysiska säkerhetskopieringen och därför är den tid det tar att återställa proportionell mot databasens storlek.
    • Den aktiva delen av transaktionsaktiviteten som måste spelas upp igen för att återställas. Återställningen kan ta längre tid beroende på den tillagda transaktionsaktiviteten från den senaste lyckade kontrollpunkten.
    • Nätverksbandbredden om återställningen görs till en annan region.
    • Antalet samtidiga återställningsförfrågningar som bearbetas i målregionen.
    • Förekomsten av primära nycklar i tabellerna i databasen. Överväg att lägga till primära nycklar för alla tabeller i databasen för snabbare återställning.

  • Kommer ändring av databasvariabler på sessionsnivå att påverka återställningen?

    Att ändra variabler på sessionsnivå och köra DML-instruktioner i en MySQL-klientsession kan påverka PITR-åtgärden (återställning till tidpunkt), eftersom dessa ändringar inte registreras i den binära loggen som används för säkerhetskopiering och återställning. Till exempel är foreign_key_checks en sådan variabel på sessionsnivå, som om den inaktiveras för att köra en DML-instruktion som bryter mot villkoret för sekundärnyckel resulterar i pitr-fel (återställning till tidpunkt). Den enda lösningen i ett sådant scenario är att välja en PITR-tid tidigare än den tidpunkt då foreign_key_checks inaktiverades. Vår rekommendation är att INTE ändra några sessionsvariabler för en lyckad PITR-åtgärd.

Nästa steg