Vanliga frågor och svar om SQL Server-databaser som körs på en säkerhetskopiering av virtuella Azure-datorer

Ja, du kan ha både säkerhetskopiering av virtuella datorer och SQL-säkerhetskopiering på samma virtuella dator. I det här fallet utlöser vi internt fullständig säkerhetskopiering endast för kopiering på den virtuella datorn för att inte trunkera loggarna.

Under vissa omständigheter utlöser Azure Backup-tjänsten reparationssäkerhetskopior. Automatisk läkning kan inträffa för något av följande sex villkor:

• Om logg- eller differentiell säkerhetskopiering misslyckas på grund av LSN-valideringsfel konverteras i stället nästa logg eller differentiella säkerhetskopiering till en fullständig säkerhetskopia.
• Om ingen fullständig säkerhetskopia har gjorts före en logg eller differentiell säkerhetskopia konverteras loggen eller differentiell säkerhetskopiering i stället till en fullständig säkerhetskopia.
• Om den senaste fullständiga säkerhetskopieringens tidpunkt är äldre än 15 dagar konverteras i stället nästa logg eller differentiella säkerhetskopiering till en fullständig säkerhetskopia.
• Alla säkerhetskopieringsjobb som avbryts på grund av en tilläggsuppgradering återställs när uppgraderingen har slutförts och tillägget har startats.
• Om du väljer att skriva över databasen under återställningen misslyckas nästa logg-/differentiella säkerhetskopiering och en fullständig säkerhetskopia utlöses i stället.
• I de fall där en fullständig säkerhetskopia krävs för att återställa loggkedjorna på grund av ändringar i databasåterställningsmodellen utlöses en fullständig automatiskt enligt nästa schema.

Nej, du kan inte avbryta ett automatiskt läkt jobb. Du kan dock välja bort det genom att följa dessa steg:

1. Skapa eller redigera ExtensionSettingsOverrides.json-filen i mappen C:\Program Files\Azure Workload Backup\bin på SQL Server-instansen.
2. I filen ExtensionSettingsOverrides.json anger du {"EnableAutoHealer": false}.
3. Spara ändringarna och stäng filen.
4. På SQL Server-instansen öppnar du Uppgiftshantera och startar sedan om tjänsten AzureWLBackupCoordinatorSvc .

Ja. Du kan begränsa den hastighet som säkerhetskopieringspolicyn körs med för att minimera påverkan på en SQL Server-instans. Så här ändrar du inställningen:

1. I SQL Server-instansen går du till C:\Program Files\Azure Workload Backup\bin-mappen och skapar filen ExtensionSettingsOverrides.json.

2. I filen ExtensionSettingsOverrides.json ändrar du inställningen DefaultBackupTasksThreshold till ett lägre värde (till exempel 5).
   {"DefaultBackupTasksThreshold": 5}
   Standardvärdet för DefaultBackupTasksThreshold är 20.

3. Spara ändringarna och stäng filen.

4. I SQL Server-instansen öppnar du Aktivitetshanteraren. Starta om tjänsten AzureWLBackupCoordinatorSvc.
   
   Den här metoden hjälper till om säkerhetskopieringsprogrammet förbrukar en stor mängd resurser, men SQL Server Resource Governor är ett mer allmänt sätt att ange gränser för hur mycket PROCESSOR, fysisk I/O och minne som inkommande programbegäranden kan använda.

Nej. Lyckade säkerhetskopieringsjobb genererar inte aviseringar. Aviseringar skickas bara för säkerhetskopieringsjobb som misslyckas. Det detaljerade beteendet för portalaviseringar dokumenteras här. Men om du är intresserad av att ha aviseringar även för lyckade jobb kan du använda Övervakning med Hjälp av Azure Monitor.

Ja, du kan uppnå den här funktionen med automatisk skydd.

Om en databas tas bort från en autoskyddad instans görs fortfarande ett försök att säkerhetskopiera databasen. Detta innebär att den borttagna databasen börjar visas som felaktig under Säkerhetskopieringsobjekt och fortfarande är skyddad.

Det rätta sättet att sluta skydda den här databasen är att stoppa säkerhetskopieringen med att ta bort data i den här databasen.

Ja, du kan skydda databaser på virtuella datorer som har Azure Disk Encryption (ADE) aktiverat.

Ja, Azure Backup stöder säkerhetskopiering av SQL Server-databaser eller -server med TDE aktiverat. Säkerhetskopiering stöder TDE med nycklar som hanteras av Azure eller med kundhanterade nycklar (BYOK). Säkerhetskopiering utför ingen SQL-kryptering som en del av säkerhetskopieringsprocessen, så databasen förblir krypterad när den säkerhetskopieras.

Vi utför en kontrollsummaåtgärd på dataströmmen. Detta ska dock inte förväxlas med SQL-kontrollsumma. Säkerhetskopiering av Azure-arbetsbelastning beräknar kontrollsumman på dataströmmen och lagrar den explicit under säkerhetskopieringen. Den här kontrollsummaströmmen tas sedan som en referens och korsverifieras med kontrollsumman för dataströmmen under återställningsåtgärden för att säkerställa att data är konsekventa.

Ja. Azure Site Recovery utlöser en fullständig säkerhetskopia endast för kopiering samtidigt som den programkonsekventa ögonblicksbilden på den virtuella datorn tas för att inte trunkera loggarna. Läs mer.

Menyn Säkerhetskopieringsjobb visar alla schemalagda åtgärder och åtgärder på begäran, förutom schemalagda loggsäkerhetskopior eftersom de kan vara mycket frekventa. För schemalagda loggjobb använder du Övervakning med Hjälp av Azure Monitor.

Om du stoppar säkerhetskopieringen med kvarhållningsdata sker inga framtida säkerhetskopior och de befintliga återställningspunkterna förblir intakta. Databasen betraktas fortfarande som skyddad och visas under säkerhetskopieringsobjekten.

Om du stoppar säkerhetskopieringen med borttagningsdata sker inga framtida säkerhetskopior och de befintliga återställningspunkterna tas också bort. Databasen anses vara oskyddad och visas under instansen på bladet Konfigurera säkerhetskopiering . Men till skillnad från andra uppskyddade databaser som kan väljas manuellt eller som kan få automatiskt skydd, visas den här databasen nedtonad och kan inte väljas. Det enda sättet att skydda databasen på nytt är att inaktivera automatiskt skydd på instansen. Nu kan du välja den här databasen och konfigurera skydd på den eller återaktivera automatiskt skydd på instansen igen.

En omdöpt databas behandlas som en ny databas. Så tjänsten hanterar den här situationen som om databasen inte hittades och säkerhetskopieringarna misslyckas.

Du kan välja databasen, som nu har bytt namn och konfigurera skydd på den. Om det automatiska skyddet är aktiverat på instansen identifieras och skyddas den omdöpta databasen automatiskt.

En databas som du lägger till i en automatiskt skyddad instans visas kanske inte omedelbart under skyddade objekt. Det beror på att identifieringen vanligtvis körs var 8:e timme, och det faktiska skyddet av systemet kan ta ytterligare tid eftersom det beror på storleken på den virtuella datorn. Du kan dock identifiera nya databaser omedelbart om du kör en identifiering manuellt genom att välja Rediscover DBs, som du ser i följande bild:

Ja, du kan ladda ned filer delvis enligt beskrivningen här.

Ja, du behöver en filsökväg i en registrerad virtuell dator för att ladda ned filer. Den sökvägen kan också vara en nätverksresurs. Konfigurera en nätverksresurs från den oregistrerade virtuella datorn till den registrerade virtuella datorn och välj sedan den registrerade virtuella datorn som mål och nätverksresursen som målfilsökväg. När filerna har laddats ned kan du helt enkelt demontera nätverksresursen från den registrerade virtuella datorn och filerna är nu tillgängliga på den oregistrerade virtuella datorn.

Under säkerhetskopieringen ansluter säkerhetskopieringsjobbet till tre tjänstslutpunkter – AzureBackup, AzureStorageoch Microsoft Entra ID. In this scenario, we recommend you to configure the Service Endpoint to AzureStorage", vilket hjälper till att skicka trafiken från det virtuella nätverket till lagringen direkt. För Azure Backup och Microsoft Entra-ID kan du konfigurera UDR över tjänsttaggar så att trafiken färdas till stamnätverket i stället för lokalt.

Nästa steg

Lär dig hur du säkerhetskopierar en SQL Server-databas som körs på en virtuell Azure-dator.