Övning – Återställa till en tidpunkt

10 minuter

I den här övningen får du lära dig hur du kan återställa från ett vanligt fel med hjälp av återställning till tidpunkt (PITR). Den här processen är enkel att utföra både i portalen och programmatiskt. I den här övningen ska du utföra processen via Azure CLI.

Installation: Använda skript för att distribuera Azure SQL Database

I terminalen till höger ser du Azure Cloud Shell, vilket är ett sätt att interagera med Azure med hjälp av en webbläsare. Innan du startar övningarna måste du köra ett skript där för att skapa miljön, en Azure SQL Database-instans som innehåller databasen AdventureWorks. Det finns ett par prompter i skriptet om ett lösenord och din lokala IP-adress.

De här skripten bör ta tre till fem minuter att slutföra. Observera lösenordet, det unika ID:t och regionen eftersom de inte visas igen.

För att få fram IP-adressen du behöver måste du koppla bort eventuella VPN-tjänster och köra (Invoke-WebRequest -Uri "https://ipinfo.io/ip").Content i ett lokalt PowerShell-fönster (inte i den här webbläsaren). Anteckna IP-adressen som visas.

Kör följande skript i Azure Cloud Shell till höger på den här sidan. Ange ett komplext lösenord och en offentlig IP-adress när du uppmanas att göra det.

$adminSqlLogin = "cloudadmin"
$password = Read-Host "Your username is 'cloudadmin'. Please enter a password for your Azure SQL Database server that meets the password requirements"
# Prompt for local IP address
$ipAddress = Read-Host "Disconnect your VPN, open PowerShell on your machine and run '(Invoke-WebRequest -Uri "https://ipinfo.io/ip").Content'. Please enter the value (include periods) next to 'Address': "
# Get resource group and location and random string
$resourceGroup = Get-AzResourceGroup | Where ResourceGroupName -like "<rgn>[sandbox resource group name]</rgn>"
$resourceGroupName = "<rgn>[sandbox resource group name]</rgn>"
$uniqueID = Get-Random -Minimum 100000 -Maximum 1000000
$storageAccountName = "mslearnsa"+$uniqueID
$location = $resourceGroup.Location
# The logical server name has to be unique in the system
$serverName = "aw-server$($uniqueID)"

Mata ut och lagra (i en textfil eller liknande) den information du behöver i resten av modulen genom att köra följande skript i Azure Cloud Shell. Du måste förmodligen trycka på Retur när du har klistrat in koden eftersom den sista raden inte körs som standard.
```
Write-Host "Please note your unique ID for future exercises in this module:"  
Write-Host $uniqueID
Write-Host "Your resource group name is:"
Write-Host $resourceGroupName
Write-Host "Your resources were deployed in the following region:"
Write-Host $location
Write-Host "Your server name is:"
Write-Host $serverName
```
Viktigt!

Glöm inte att anteckna lösenordet, det unika ID:t och regionen. Du behöver den här informationen i resten av modulen.

Kör följande skript för att distribuera en Azure SQL Database-instans och logisk server med exempeldatabasen AdventureWorks. Det här skriptet lägger också till din IP-adress som en brandväggsregel, aktiverar Microsoft Defender för molnet och skapar ett lagringskonto för användning i kommande enheter.

# The logical server name has to be unique in the system
$serverName = "aw-server$($uniqueID)"
# The sample database name
$databaseName = "AdventureWorks"
# The storage account name has to be unique in the system
$storageAccountName = $("sql$($uniqueID)")
# Create a new server with a system-wide unique server name
$server = New-AzSqlServer -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -Location $location `
    -SqlAdministratorCredentials $(New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $adminSqlLogin, $(ConvertTo-SecureString -String $password -AsPlainText -Force))
# Create a server firewall rule that allows access from the specified IP range and all Azure services
$serverFirewallRule = New-AzSqlServerFirewallRule `
    -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -FirewallRuleName "AllowedIPs" `
    -StartIpAddress $ipAddress -EndIpAddress $ipAddress
$allowAzureIpsRule = New-AzSqlServerFirewallRule `
    -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -AllowAllAzureIPs
# Create a database
$database = New-AzSqlDatabase  -ResourceGroupName $resourceGroupName `
    -ServerName $serverName `
    -DatabaseName $databaseName `
    -SampleName "AdventureWorksLT" `
    -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5"
# Enable Azure Defender
$azureDefender = Enable-AzSqlServerAdvancedDataSecurity `
    -ResourceGroupName $resourceGroupName `
    -ServerName $serverName
# Create a storage account
$storageAccount = New-AzStorageAccount -ResourceGroupName $resourceGroupName `
    -AccountName $storageAccountName `
    -Location $location `
    -Type "Standard_LRS"

Öppna SSMS lokalt i datorn och skapa en ny anslutning till din logiska server. Som servernamn anger du namnet på den logiska Azure SQL Database-servern. Om du inte sparade namnet tidigare kan du behöva hämta det från Azure-portalen igen. Exempel: aw-server\<unique ID>.database.windows.net.

Azure-portalen
1. Från Azure-portalen kan du ange AdventureWorks i sökfältet för att hitta din databas och den tillhörande logiska servern.
2. I fältet Autentisering väljer du SQL Server-autentisering. Ange serveradministratörens Inloggning och Lösenord (de du angav vid distributionen i föregående övning).
3. Markera rutan Kom ihåg lösenord och välj sedan Anslut.
Kommentar

Beroende på den lokala konfigurationen (till exempel VPN) kan klientens IP-adress skilja sig från IP-adressen som användes till distributionen i Azure-portalen. Om så är fallet visas ett meddelande som lyder ”Klientens IP-adress har inte åtkomst till servern. Logga in på ett Azure-konto och skapa en ny brandväggsregel för att aktivera åtkomst." Om du får det här meddelandet loggar du in med det konto som du använder för sandbox-miljön och lägger till en brandväggsregel för klientens IP-adress. Du kan utföra alla de här stegen i popup-guiden i SSMS.

Utföra återställning till tidpunkt

Innan du går vidare är det viktigt att förstå den rekommenderade processen för återställning till tidpunkt:

En tabell eller databas raderas av misstag.
Fastställ den tid som du behöver gå tillbaka till; det bör vara innan felet inträffade.
Slutför återställningen till tidpunkt via PowerShell eller Azure Portal för att gå tillbaka till den tidpunkten. Då distribueras en ny databas och en kopia av databasen återställs. Till exempel: AdventureWorks-copy.
Bekräfta att den nya databasen (till exempel AdventureWorks-copy) är i rätt tillstånd (som den var innan olyckan inträffade).
Byt namn på den ursprungliga databasen. Du kan till exempel byta namn på AdventureWorks till AdventureWorks-old.
Ge den nya databasen det ursprungliga databasnamnet. Du kan till exempel byta namn på AdventureWorks-copy till AdventureWorks.
Ta bort den ursprungliga databasen. Till exempel: AdventureWorks-old.

I den här övningen ska du utföra de här stegen.

Simulera borttagning av data

Först bekräftar vi att tabellen vi ska ta bort av misstag finns och att den innehåller data. Vi tittar på några värden i SalesLT.OrderDetail.

Gå till SSMS och kontrollera/uppdatera din anslutning. Välj Filanslutningsobjektutforskaren> och välj sedan knappen Alternativ.
Kontrollera att anslutningen du använder ansluter till den logiska servern, men inte till en viss databas. (Använd till exempel <standard enligt> följande skärmbild.) Bekräfta också att fliken Ytterligare anslutningsparametrar inte innehåller någon text.
Expandera mappen Databaser, högerklicka sedan på din AdventureWorks-databas och välj Ny fråga. Ange följande fråga och kör den genom att välja Kör och granska sedan resultatet:
```
SELECT TOP 10 * from SalesLT.SalesOrderDetail
```
Nu ska vi simulera dataförlust genom att ta bort en tabell i databasen.

I samma frågefönster kör du den här frågan och väljer sedan fliken Meddelanden i fönstret Resultat och noterar slutförandetiden:
```
DROP TABLE SalesLT.SalesOrderDetail
```
Viktigt!

Spara körningstiden. Du behöver det senare. Här följer ett exempel: Completion time: 2020-06-22T09:20:27.1859237-07:00.

Innan du påbörjar stegen för att återställa databasen kör du slutligen följande kod i Azure Cloud Shell till höger på den här sidan för att konfigurera din miljö:

$resourceGroup = Get-AzResourceGroup | Where ResourceGroupName -like <rgn>[sandbox resource group name]</rgn>
$server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup.ResourceGroupName
$logical_server = $server.ServerName
$resource_group = $resourceGroup.ResourceGroupName

# Specify your default resource group and Azure SQL Database logical server
az configure --defaults group=$resource_group sql-server=$logical_server

# Confirm the defaults are set
az configure --list-defaults

Parametrarna group och sql-server som returneras måste matcha namnet på din Microsoft Learn-resursgrupp och din logiska Azure SQL Database-server.

Identifiera den tid till vilken databasen ska återställas

Det första steget är att ta reda på hur länge databasen ska återställas. Du måste veta när den senaste ”bra” transaktionen utfördes innan den ”dåliga”. Du ska återställa till en tidpunkt innan den dåliga transaktionen men efter den senaste bra.

Ett sätt att fastställa borttagningstiden är att se efter när DROP-instruktionen utfördes, som du antecknade i föregående steg.

Ett annat sätt är att använda granskningsloggarna i Azure Portal. I den här övningen har du inte konfigurerat granskning till Log Analytics, men nu ska vi utforska vad du kan göra om du hade det. Du kan gå till din Azure SQL-databas i Azure Portal. I den vänstra rutan, under Säkerhet, kan du välja Granskning och sedan välja Visa granskningsloggar. Genom att sedan välja Log Analytics kommer du till en frågeredigerare som gör att du kan köra frågor mot loggar med hjälp av Kusto-frågespråk (KQL). SQL-proffs kan använda det här frågespråket till att enkelt köra frågor mot loggar.

Du kan sedan köra följande KQL-fråga:
```
search database_name_s == "AdventureWorks"
| where Category == 'SQLSecurityAuditEvents' and statement_s like 'DROP'
| project format_datetime(event_time_t, 'yyyy-MM-dd hh:mm:ss.fff'), ResourceGroup, server_instance_name_s, database_name_s,  statement_s, succeeded_s,client_ip_s, server_principal_name_s, application_name_s
| sort by event_time_t desc
```
Resultatet bör likna följande, men med andra värden för datum och tidpunkt.

Kommentar

Det kan ta 5 till 10 minuter innan loggarna visas här, så i den här övningen har vi utelämnat det. Du använder i stället den slutförandetid som du antecknade i föregående steg. (Du måste konvertera den till GMT.) I en verklig situation kommer du sannolikt inte att kunna komma till fönstret med slutförandetiden, så granskning kan vara till stor hjälp.
I det här exemplet kommer 2020-07-24 08:06:24.386 datum/tid från Log Analytics och 2020-07-24T13:06:24.386-07:00 från SSMS. Det format som krävs skiljer sig något åt. Använd följande exempel till att fastställa rätt format. Det kan vara bra att dra ifrån 0,001 sekunder så att du faktiskt får en tidpunkt innan felet inträffade:
- Log Analytics-format: 2020-07-24 08:06:24.386
- SSMS-format: 2020-07-24T13:06:24.386-07:00
- Format som krävs: 2020-07-24T20:06:24.385
Ange $before_error_time till det resulterande värdet och ersätt din tid för tiden i det här exemplet:
```
$before_error_time ="2020-07-24T20:06:24.385"
```

Återställa databasen och bekräfta data som saknas

I det här avsnittet ska du använda az cli db restore till att återställa databasen till en tidpunkt innan tabellen togs bort.

Kör följande skript i terminalen till höger i fönstret:
```
# Restore the database to a time before the database was deleted
az sql db restore --dest-name "AdventureWorks-copy" --name "AdventureWorks" --time $before_error_time --verbose
```
Återställningen tar cirka 5 till 10 minuter. När du kör en återställning distribuerar Azure en ny Azure SQL-databas på din logiska Azure SQL Database-server. Den nya databasen har samma konfigurationsalternativ som originalet. När Azure SQL-databasen har distribuerats återställer Azure databasen till den nya Azure SQL-databasen.
Du kan kontrollera statusen genom att uppdatera databasvyn i SSMS. Högerklicka på mappen Databaser och välj Uppdatera. När databasen har distribuerats ser du att återställningen pågår:

När du ser att återställningen pågår bör återställningen ta två till tre minuter till. Du ser när den är färdig eftersom kommandot slutförs. Dessutom ser du inte längre ”(Återställer...)” bredvid databaskopian när du startar en uppdatering.

Om du märker att återställningen tar längre tid än vad som anges ovan kan det bero på din Microsoft Learn-miljö. Det finns en gräns för antalet återställningsförfrågningar som kan bearbetas/skickas samtidigt för samma prenumeration. Om du vill lära dig mer om begränsningar och relaterad information om PITR medan du väntar kan du läsa Återställa en databas från en säkerhetskopia i Azure SQL Database.
Bekräfta nu att den nya databasen är i rätt tillstånd (innan olyckan inträffade). Högerklicka på den logiska servern i SSMS och välj sedan Uppdatera för att uppdatera anslutningen till den logiska Azure SQL Database-servern.
Högerklicka på den nya databasen (till exempel AdventureWorks-copy) och välj Ny fråga.
Använd den här frågan till att bekräfta att tabellen finns:
```
SELECT TOP 10 * from SalesLT.SalesOrderDetail
```
Du bör få ett resultat som liknar följande skärmbild. Det här resultatet bekräftar att databasen återställts till önskad tidpunkt.

Växla databaserna och rensa

Därefter byter du namn på den ursprungliga databasen till AdventureWorks-old så att du senare kan byta namn på den nya databasen så att den använder det ursprungliga databasnamnet. Så länge dina program använder logik för omförsök gör den här ändringen att du inte behöver ändra några anslutningssträngar.

Om databasen verkar vara otillgänglig (till exempel om du inte kan ansluta till databaserna i SSMS efter att ha uppdaterat anslutningen) kan det bero på att DNS-tabellen uppdateras. Databasen är alltså inte fysiskt otillgänglig, men kan ändå inte nås. Om du väntar en minut eller så bör du kunna återuppta normala aktiviteter.

Använd det här kommandot till att byta namn på databasen:

az sql db rename --name "AdventureWorks" --new-name "AdventureWorks-old"

Nu när det ursprungliga databasnamnet inte längre är upptaget kan du ge databaskopian det ursprungliga namnet, återigen via Azure Cloud Shell:
```
az sql db rename --name "AdventureWorks-copy" --new-name "AdventureWorks"
```

Du behöver inte den gamla databasen, så du kan ta bort den med az sql db delete:

az sql db delete --name "AdventureWorks-old" --yes
Write-Host "Database deleted"

Du kan bekräfta att den gamla databasen inte längre finns med det här kommandot:
```
az sql db list -o table
```

Nu har du sett hur du kan använda återställning till tidpunkt i Azure SQL Database. Återställning till tidpunkt är också tillgängligt i Azure SQL Managed Instance, men inte för hela instanser. Du kan använda nästan samma kommandon, förutom att du måste använda az sql midb i stället för az sql db.