Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Azure Backup erbjuder helhetsstöd för säkerhetskopiering av SQL Server Always On-tilgänglighetsgrupper (AG) om alla noder finns i samma region och prenumeration som återställningstjänstvalvet. Men om AG noderna är spridda över regioner, prenumerationer, lokalt och Azure, finns det flera viktiga aspekter att beakta.
Information om hur du visar de säkerhetskopierings- och återställningsscenarier som vi stöder i dag finns i supportmatrisen. Vanliga frågor finns i vanliga frågor och svar.
Anmärkning
Azure Backup stöder inte säkerhetskopiering av databaser för grundläggande tillgänglighetsgrupp.
Beteende för säkerhetskopieringsinställningar efter SQL Server version
Stöd för fullständig och differentiell säkerhetskopiering på sekundära repliker beror på SQL Server version. Inställningar för ag-säkerhetskopiering och SQL Server version avgör vilken nod som valts för varje typ av säkerhetskopiering.
SQL Server 2022 och tidigare
Säkerhetskopieringsinställningen som används av Azure Backup SQL AG stöder endast fullständiga och differentiella säkerhetskopieringar från den primära repliken. De här säkerhetskopieringsjobben körs därför alltid på den primära noden oavsett säkerhetskopieringsinställningen. För säkerhetskopior av endast fullständiga och transaktionsloggar beaktas inställningen för säkerhetskopiering av tillgänglighetsgruppen vid beslut om vilken nod som säkerhetskopieringen ska köras på.
| AG Backup-inställningar | Fullständiga säkerhetskopieringar och Diff-säkerhetskopieringar körs på | Copy-Only och loggsäkerhetskopior hämtas från |
|---|---|---|
| Primär | Primär kopia | Primär kopia |
| Endast sekundär | Primär kopia | Någon av de sekundära replikerna |
| Föredrar sekundär | Primär kopia | Sekundära repliker är att föredra, men säkerhetskopieringar kan också köras på den primära repliken. |
| Ingen/alla | Primär kopia | Valfri replik |
SQL Server 2025 och senare
I SQL Server 2025 och senare stöder sekundära repliker även fullständiga och differentiella säkerhetskopior. Säkerhetskopieringsinställningen styr nu båda säkerhetskopieringstyperna på ett enhetligt sätt. När du anger Sekundär endast eller Föredrar sekundär, kräver fullständiga och differentiella säkerhetskopior inte längre den primära noden.
| AG Backup-inställningar | Fullständiga säkerhetskopieringar och Diff-säkerhetskopieringar körs på | Copy-Only och loggsäkerhetskopior hämtas från |
|---|---|---|
| Primär | Primär kopia | Primär kopia |
| Endast sekundär | Någon av de sekundära replikerna | Någon av de sekundära replikerna |
| Föredrar sekundär | Sekundära repliker är att föredra, men säkerhetskopieringar kan också köras på den primära repliken. | Sekundära repliker är att föredra, men säkerhetskopieringar kan också köras på den primära repliken. |
| Ingen/alla | Valfri replik | Valfri replik |
När du registrerar en nod med tjänsten Azure Backup installerar du tillägget för säkerhetskopiering av arbetsbelastningar på noden. När du konfigurerar en tillgänglighetsgruppsdatabas för säkerhetskopiering skickas scheman för säkerhetskopiering till alla registrerade noder i tillgänglighetsgruppen. Schemaläggningen utlöses på alla AG-noder, och arbetsbelastningarnas säkerhetskopieringstillägg på dessa noder synkroniserar med varandra för att avgöra vilken nod som kan hantera säkerhetskopieringen. Valet av nod beror på typen av säkerhetskopiering och den säkerhetskopieringsinställning som beskrivs i Beteende för säkerhetskopieringsinställningar efter SQL Server version.
Den valda noden fortsätter med säkerhetskopieringsjobbet, medan jobbet som utlöses på de andra noderna hoppar över jobbet.
Anmärkning
Azure Backup överväger inte säkerhetskopieringsprioriteringar eller repliker när du bestämmer dig för de sekundära replikerna.
Registrera AG-noder i Recovery Services-valvet
Ett Recovery Services-valv stöder endast säkerhetskopiering av databaser från virtuella datorer i samma region och prenumeration som i valvet.
SQL Server 2022 och tidigare:
- Registrera den primära noden i valvet (annars kan fullständiga säkerhetskopieringar inte ske).
- Registrera minst en sekundär nod i valvet (annars kan logg-/kopieringsbefriade fullständiga säkerhetskopior inte ske) om säkerhetskopieringsinställningen endast är sekundär.
Det går inte att konfigurera säkerhetskopieringar för AG-databaser med felkoden FabricSvcBackupPreferenceCheckFailedUserError om ovanstående villkor inte uppfylls.
SQL Server 2025 och senare:
- Registrering av primär nod är inte längre obligatorisk för tillgänglighetsgruppens säkerhetskopieringskonfiguration. Eftersom fullständiga och differentiella säkerhetskopior nu kan köras på sekundära repliker kan du konfigurera säkerhetskopior med endast sekundära noder registrerade (när säkerhetskopieringsinställningen är endast sekundär eller Föredrar sekundär).
- För primär säkerhetskopieringsinställning måste den primära noden fortfarande vara registrerad.
- Registrera minst en nod som uppfyller den valda säkerhetskopieringsinställningen.
Anmärkning
Lättnaden av kravet på registrering av den primära noden styrs av den SQL Server-version som identifieras vid identifiering av databaser i tillgänglighetsgruppen. Om någon replik i AG kör SQL Server 2022 eller tidigare, gäller fortfarande kravet på registrering av den primära noden för den AG:n.
Låt oss betrakta följande tillgänglighetsgruppsimplementering som en referens.
Baserat på den angivna driftsättningen av tillgänglighetsgrupp, behöver följande aspekter övervägas:
- Eftersom den primära noden finns i region 1 och prenumeration 1 måste Recovery Services-valvet (Valv 1) finnas i region 1 och prenumeration 1 för att skydda den här tillgänglighetsgruppen.
-
VM3kan inte registreras i Valv 1 eftersom det finns i en annan prenumeration. -
VM4kan inte registreras i Valv 1 eftersom det finns i en annan region. - Om säkerhetskopieringsinställningen endast är sekundär registrerar du VM1 (primär) och VM2 (sekundär) till Valv 1. På SQL Server 2022 och tidigare kräver fullständiga säkerhetskopior den primära noden så registrera båda noderna. På SQL Server 2025 och senare räcker det med enbart VM2. För andra säkerhetskopieringsinställningar registrerar du VM1 (primär) till Valv 1; VM2 är valfritt.
- Även om du kan registrera VM3 i valv 2 i prenumeration 2 och AG-databaserna då visas för skydd i valv 2, går det inte att konfigurera säkerhetskopior i SQL Server 2022 och tidigare eftersom den primära noden saknas i valv 2. På SQL Server 2025 och senare kan du konfigurera säkerhetskopior i valv 2 om säkerhetskopieringsinställningen är Endast sekundär eller Föredrar sekundär.
- På samma sätt kan du registrera VM4 i valv 4 i region 2, men det går inte att konfigurera säkerhetskopiering i SQL Server 2022 och tidigare versioner eftersom den primära noden inte är registrerad i valv 4. På SQL Server 2025 och senare kan du konfigurera säkerhetskopior i valv 4 om säkerhetskopieringsinställningen är Endast sekundär eller Föredrar sekundär.
Hantera övergång
När tillgänglighetsgruppen har växlat över till en av de sekundära noderna:
- SQL Server 2022 och tidigare: Fullständiga och differentiella säkerhetskopior fortsätter från den nya primära noden om den är registrerad i valvet.
- SQL Server 2025 och senare: Fullständiga och differentiella säkerhetskopior fortsätter från noden som uppfyller säkerhetskopieringsinställningen. För sekundär endast eller Föredrar sekundär kan dessa säkerhetskopior köras på en sekundär replik.
- Logg- och kopieringssäkerhetskopiorna fortsätter från den primära/sekundära noden baserat på säkerhetskopieringsinställningen.
Anmärkning
Loggkedjebrytningar sker inte vid redundansväxling om redundansväxlingen inte sammanfaller med en säkerhetskopia.
Baserat på ovanstående exempel på ag-distribution är följande de olika redundansmöjligheterna:
- Redundansväxling till VM2
- Fullständiga och differentiella säkerhetskopieringar sker från VM2.
- Logg- och kopieringsbara fullständiga säkerhetskopior kommer att ske från VM1 eller VM2 baserat på säkerhetskopieringspreferens.
- Övergång till VM3 (en annan abonnemang)
- Eftersom säkerhetskopior inte konfigureras i Valv 2 sker inga säkerhetskopior.
- På SQL Server 2022 och tidigare, om säkerhetskopieringsinställningen inte är sekundär, kan du nu konfigurera säkerhetskopior i Valv 2 eftersom den primära noden är registrerad i det här valvet. På SQL Server 2025 och senare kan du även konfigurera säkerhetskopior när den registrerade noden i Valv 2 uppfyller den valda säkerhetskopieringsinställningen. Det här villkoret kan leda till konflikter eller säkerhetskopieringsfel. Mer information finns i Konfigurera säkerhetskopior för en multiregional AG.
- Redundansväxling till VM4 (en annan region)
- Eftersom säkerhetskopior inte har konfigurerats i Valv 4 sker inga säkerhetskopior.
- På SQL Server 2022 och tidigare, om säkerhetskopieringsinställningen inte är sekundär, kan du nu konfigurera säkerhetskopior i Valv 4 eftersom den primära noden är registrerad i det här valvet. På SQL Server 2025 och senare kan du även konfigurera säkerhetskopior när den registrerade noden i Valv 4 uppfyller den valda säkerhetskopieringsinställningen. Det här villkoret kan leda till konflikter eller säkerhetskopieringsfel. Mer information finns i Konfigurera säkerhetskopior för en AG i flera regioner.
Konfigurera säkerhetskopior för en tillgänglighetsgrupp för flera regioner
Recovery Services-valv stöder inte säkerhetskopieringar mellan prenumerationer eller regioner. I det här avsnittet sammanfattas hur du aktiverar säkerhetskopieringar för AG:er som omfattar prenumerationer eller Azure-regioner och tillhörande överväganden.
Utvärdera om du verkligen behöver aktivera säkerhetskopieringar från alla noder. Om en region/prenumeration har de flesta ag-noder och redundansväxling till andra noder sker mycket sällan, kan det räcka med att konfigurera säkerhetskopieringen i den första regionen. Om failover till andra regioner eller abonnemang sker ofta och under längre perioder, kan det vara en bra idé att proaktivt konfigurera säkerhetskopieringar även i den andra regionen.
Varje valv där säkerhetskopieringen aktiveras har en egen uppsättning återställningspunktskedjor. Återställningar från dessa återställningspunkter kan endast göras till virtuella datorer som är registrerade i valvet.
SQL Server 2022 och tidigare: Fullständiga och differentiella säkerhetskopior fungerar endast i valvet som har den primära noden. De här säkerhetskopiorna i andra valv fortsätter att misslyckas. I SQL Server 2025 och senare ändras det här beteendet för inställningarna Endast sekundär och Föredra sekundär – se SQL Server 2025: Ändringar för säkerhetskopiering i AG för flera regioner.
Loggsäkerhetskopior fortsätter att fungera i föregående valv tills en loggsäkerhetskopia körs i det nya valvet (dvs. i valvet där den nya primära noden finns) och bryter loggkedjan för det gamla valvet.
Anmärkning
Det finns en hård gräns på 15 dagar efter vilken loggsäkerhetskopieringar börjar misslyckas.
Fullständiga säkerhetskopior med endast kopiering fungerar i alla valv.
Skyddet i varje valv behandlas som en distinkt datakälla och faktureras separat.
För att undvika loggsäkerhetskopieringskonflikter mellan de två valven rekommenderar vi att du ställer in säkerhetskopieringsinställningen på Primär. Då kommer det valvet som har den primära noden även att ta loggsäkerhetskopiorna.
SQL Server 2025: Backupändringar för AG för flera regioner
Med SQL Server 2025 kräver fullständiga och differentiella säkerhetskopieringar inte längre den primära noden. Den här ändringen innebär:
Registrering av primär nod krävs inte – Om säkerhetskopieringsinställningen är Endast sekundär eller Föredrar sekundär kan du konfigurera och köra säkerhetskopior från en registrerad sekundär nod, även om den primära noden finns i en annan region eller prenumeration.
Minskad redundanspåverkan – Efter redundansväxling till en nod i en annan region kan säkerhetskopieringar fortsätta i det ursprungliga valvet så länge en registrerad nod som uppfyller säkerhetskopieringsinställningen är tillgänglig.
Den grundläggande samordningsbegränsningen mellan valv kvarstår dock – säkerhetskopieringar kan inte samordnas mellan flera valv. Om du registrerar AG-noder i olika valv mellan regioner kan samtidiga säkerhetskopieringsscheman vara i konflikt och orsaka loggkedjebrytningar eller duplicerade säkerhetskopior.
Rekommendation för att undvika konflikter mellan valv:
- Tillgänglighetsgrupp med 2 noder: Ställ in säkerhetskopieringsinställningen på Endast sekundär eller Primär.
- Tillgänglighetsgrupp för 3 noder: Ställ in säkerhetskopieringsinställningen på Primär.
Den här konfigurationen säkerställer att endast ett valvs nod är berättigad till säkerhetskopior när som helst.
Här är stegen för att aktivera säkerhetskopiering från alla noder baserat på ovanstående exempel på ag-distribution. Antagandet är att säkerhetskopieringsinställningen uppfylls i alla steg.
Steg 1: Aktivera säkerhetskopior i region 1, prenumeration 1 (valv 1)
Eftersom den primära noden finns i region och prenumeration fungerar de vanliga stegen för att aktivera säkerhetskopieringar.
Steg 2: Aktivera säkerhetskopieringar i region 1, prenumeration 2 (valv 2)
- Flytta över tillgänglighetsgruppen till VM3 så att den primära noden ska finnas i Valv 2.
- Konfigurera säkerhetskopior för tillgänglighetsgruppens databaser i Valv 2.
- I det här läget:
- De fullständiga/differentiella säkerhetskopiorna misslyckas i Valv 1 eftersom ingen av de registrerade noderna kan ta den här säkerhetskopian.
- Loggsäkerhetskopiorna lyckas i Valv 1 tills en loggsäkerhetskopia körs i Valv 2 och bryter loggkedjan för Vault 1.
- Återväxla AG till VM1.
Steg 3: Aktivera säkerhetskopior i region 2, prenumeration 1 (valv 4)
Samma som steg 2.
Säkerhetskopiera en tillgänglighetsgrupp som sträcker sig över Azure och lokalt
Azure Backup för SQL Server kan inte köras lokalt. Om den primära noden finns i Azure och säkerhetskopieringsinställningen uppfylls av noderna i Azure kan du följa ovanstående riktlinjer för tillgänglighetsgruppen för flera regioner för att aktivera säkerhetskopieringar för replikerna i Azure. Om en redundansväxling till en lokal nod sker börjar de fullständiga och differentiella säkerhetskopiorna i Azure att misslyckas. Loggsäkerhetskopior kan fortsätta tills avbrott i loggkedjan sker/15 dagar har passerat.
Begränsning för säkerhetskopieringsjobb i en tillgänglighetsgruppsdatabas
Begränsningarna för säkerhetskopiering gäller för närvarande för varje enskild dator. Standardgränsen är 20 – om fler än 20 säkerhetskopior utlöses samtidigt körs de första 20 och de andra placeras i kö. När jobben som körs är klara börjar de köade jobben att köras.
Du kan ändra det här värdet till ett mindre värde om de samtidiga säkerhetskopiorna orsakar minnes-/I/O-/CPU-belastning på noden. Eftersom begränsningen är på nodnivå kan obalanserade AG-noder leda till problem med säkerhetskopieringssynkronisering. För att förstå detta bör du till exempel överväga en tillgänglighetsgrupp på 2 noder.
Den första noden har till exempel 50 fristående databaser skyddade och båda noderna har 5 AG-databaser skyddade. I själva verket har Nod 1 55 databassäkerhetskopieringsjobb schemalagda medan Nod 2 bara har 5. Dessutom är alla dessa säkerhetskopior konfigurerade att köras samtidigt, varje timme. Vid ett tillfälle utlöses alla 55 säkerhetskopior på nod 1 och 35 av dessa placeras i kö. Några av dessa skulle vara säkerhetskopior av tillgänglighetsgruppens databas. Men på nod 2 skulle säkerhetskopieringen av AG-databasen fortsätta utan väntetider.
Eftersom AG-databasjobben läggs i kö på en nod och körs på en annan, fungerar inte säkerhetskopieringssynkroniseringen korrekt. Nod 2 kan anta att nod 1 är nere och därför kommer inte jobb från nod 1 för synkronisering. Det här problemet kan leda till loggkedjebrytningar eller extra säkerhetskopior eftersom båda noderna kan ta säkerhetskopior separat.
Liknande problem kan inträffa om antalet AG-databaser som skyddas är fler än begränsningsgränsen. I sådana fall kan säkerhetskopiering för till exempel DB1 placeras i kö på nod 1 medan den körs på nod 2.
Vi rekommenderar att du använder följande säkerhetskopieringsinställningar för att undvika dessa synkroniseringsproblem:
- För en tillgänglighetsgrupp på 2 noder ställer du in säkerhetskopieringsinställningen på Endast primär eller Sekundär – sedan kan bara en nod göra säkerhetskopiorna, den andra löser alltid ut.
- För en tillgänglighetsgrupp med fler än 2 noder ställer du in säkerhetskopieringspreferens på Primär – sedan kan endast den primära noden göra säkerhetskopiorna, andra kommer inte att delta.
Fakturering av AG-säkerhetskopior
Samma som en fristående SQL-instans, betraktas en säkerhetskopierad AG-instans som en skyddad instans. Den totala gränssnittsstorleken för alla skyddade databaser i en instans debiteras. Överväg följande distribution:
De skyddade instanserna beräknas på följande sätt:
| Skyddad instans/faktureringsenhet | Databaser som övervägs för beräkning av klientdelsstorlek |
|---|---|
| AG1 | DB1, DB2 |
| AG2 | DB4 |
| VM2 | DB3 |
| VM3 | DB6 |
| VM4 | DB5 |
Flytta en skyddad databas till eller från en AG
Azure Backup betraktar SQL-instansen eller tillgänglighetsgruppens namn\Databasnamn som databasens unika namn. När den fristående databasen skyddades var dess unika namn StandAloneInstanceName\DBName. När den flyttas under en AG ändras det unika namnet till AGName\DBName. Säkerhetskopiorna för den fristående databasen börjar misslyckas med felkoden : UserErrorBackupFailedStandaloneDatabaseMovedInToAG.
Databasen måste konfigureras för skydd från under tillgänglighetsgruppen. Detta behandlas som en ny datakälla med en separat återställningspunktkedja. Det äldre skyddet av fristående databas kan förhindras genom att bibehålla data för att undvika att framtida säkerhetskopior utlöses och misslyckas vid dessa. När en skyddad AG-databas flyttas ut ur AG och blir en fristående databas, börjar säkerhetskopiorna misslyckas med felkoden UserErrorBackupFailedDatabaseMovedOutOfAG.
Databasen måste konfigureras för skydd från under den fristående instansen. Detta behandlas som en ny datakälla med en separat återställningspunktkedja. Det äldre skyddet av AG-databasen kan stoppas genom att bevara data för att undvika att framtida säkerhetskopior utlöses och misslyckas på den.
Lägga till eller ta bort en nod i en AG
När en ny nod läggs till i en tillgänglighetsgrupp som har konfigurerats för säkerhetskopior identifierar tilläggen för säkerhetskopiering av arbetsbelastningar som körs på de redan registrerade tillgänglighetsgruppen ändringen av tillgänglighetsgruppens topologi och informerar Azure Backup-tjänsten under nästa schemalagda databasidentifieringsjobb. När den nya noden registreras för säkerhetskopior till samma Recovery Services-valv som de andra befintliga noderna utlöser Azure Backup-tjänsten ett arbetsflöde som konfigurerar den nya noden med nödvändiga metadata för att utföra ag-säkerhetskopieringar.
Efter det här steget synkroniserar den nya noden schemainformationen för tillgänglighetsgruppens säkerhetskopiering från Azure Backup-tjänsten och börjar delta i den synkroniserade säkerhetskopieringsprocessen. Om den nya noden inte kan synkronisera säkerhetskopieringsscheman och delta i säkerhetskopieringar, tvingar utlösande av en omregistrering på noden omkonfiguration av noden även för tillgänglighetsgruppens säkerhetskopior. På samma sätt upptäcker arbetsbelastningstilläggen topologiändringen i AG vid borttagning av en nod och informerar Azure Backup-tjänsten. Tjänsten startar ett arbetsflöde för nodens avkonfiguration på den nod som har tagits bort för att rensa säkerhetskopieringsscheman för AG-databaser och ta bort AG-relaterade metadata.
Avregistrera en tillgänglighetsgruppsnod från Azure Backup
Om en nod är en del av en tillgänglighetsgrupp som har en eller flera databaser konfigurerade för säkerhetskopiering tillåter Inte Azure Backup avregistrering av noden. Detta för att förhindra framtida säkerhetskopieringsfel om säkerhetskopieringsinställningen inte kan uppfyllas utan den här noden. För att avregistrera noden måste du först ta bort den från AG:n. När nodens avkonfigurationsarbetsflöde har slutförts och rensar noden kan du avregistrera den.
Återställ en databas från Azure Backup till en SQL-tillgänglighetsgrupp. SQL-tillgänglighetsgrupper stöder inte direkt återställning av en databas in i tillgänglighetsgruppen. Databasen måste återställas till en fristående SQL-instans och sedan anslutas till en AG.
Scenarier för återskapande av tillgänglighetsgrupp för SQL-databasservern
Återskapande av tillgänglighetsgrupp (AG), duplicerade AG:er och säkerhetskopieringsobjekt visas som skyddsbara objekt eller skyddade objekt i följande scenarier:
Återskapande av AG:er som redan är skyddade visas som duplicerade AG:er på sidan Konfigurera säkerhetskopiering och i listan Skyddade objekt . Om du vill behålla de säkerhetskopierade data som redan finns i den äldre tillgänglighetsgruppen stoppar du säkerhetskopieringen med hjälp av alternativet Stoppa skydd och behåller data innan du återskapar och schemalägger säkerhetskopieringar på de nya tillgänglighetsgruppens objekt.
Azure Backup listar avsiktligt de duplicerade objekten i listan Skyddade objekt och sidan Konfigurera säkerhetskopiering eller Listan över skyddsbara objekt och visar dessa objekt tills du vill behålla säkerhetskopieringsdata.
Om du inte vill ha säkerhetskopierade data från den äldre tillgänglighetsgruppen stoppar du säkerhetskopieringsåtgärden med hjälp av alternativet Stoppa skydd och ta bort data för det äldre objektet innan du skapar och schemalägger säkerhetskopieringar på den nya tillgänglighetsgruppen igen.
Försiktighet
Att stoppa skyddet och ta bort data är en destruktiv åtgärd.
Du kan återskapa tillgänglighetsgruppen efter att ha utfört någon av ovanstående stoppskyddsprocess för att undvika säkerhetskopieringsfel.
Överväganden för säkerhetskopiering för SQL Server 2025 AG
Inställningar för säkerhetskopiering ändras efter konfigurationen
Om du ändrar inställningen för AG-säkerhetskopiering men inte registrerar den nödvändiga noden i valvet, misslyckas säkerhetskopieringarna. Om du till exempel ändrar inställningen från Primär till Endast sekundär men ingen sekundär nod har registrerats, misslyckas logg- och fullständiga/Diff-säkerhetskopieringar. Se alltid till att noder som uppfyller den nya säkerhetskopieringsinställningen registreras i valvet innan du gör ändringen.
Samordning av AG-säkerhetskopiering i flera regioner
När du skyddar AG-noder i flera valv i olika regioner kan valven inte samordna säkerhetskopieringar mellan varandra, oavsett SQL Server-version. Mer information om inställningar för säkerhetskopieringspreferenser som undviker avbrott i loggkedjan och dubbla säkerhetskopior i det här scenariot finns i SQL Server 2025: Ändringar för säkerhetskopiering i AG med flera regioner.
Stöd för säkerhetskopiering av ögonblicksbilder
Säkerhetskopiering av ögonblicksbilder stöds inte på sekundära repliker av en tillgänglighetsgrupp. När du aktiverar säkerhetskopiering av ögonblicksbilder på säkerhetskopieringsprincipen förblir registrering av primär nod obligatorisk oavsett SQL Server version.
Nästa steg
Lär dig att:
Relaterat innehåll
- Säkerhetskopiera SQL Server-databaser på virtuella Azure-datorer med Hjälp av Azure Backup via REST API.
- Återställa SQL Server-databaser på virtuella Azure-datorer med REST API.
- Hantera SQL Server-databaser på virtuella Azure-datorer med Azure-portalen, Azure CLI, REST API.