Ejercicio: restauración a un momento dado

  • 10 minutos

En este ejercicio, aprenderá cómo se puede recuperar de un error común mediante la restauración a un momento dado (PITR). Este proceso es sencillo de realizar en el portal o mediante programación. En este ejercicio, aprenderá a hacerlo con la CLI de Azure.

Escenario: Uso de scripts para implementar Azure SQL Database

En el terminal de la derecha, verá Azure Cloud Shell, que es una manera de interactuar con Azure mediante un explorador. Antes de empezar los ejercicios, debe ejecuta un script para crear el entorno: una instancia de Azure SQL Database que contiene la base de datos AdventureWorks. En el script, habrá varias solicitudes de una contraseña y la dirección IP local.

Estos scripts deben tardar de tres a cinco minutos en completarse. Asegúrese de anotar la contraseña, el identificador único y la región, ya que no se volverán a mostrar.

  1. Para obtener la dirección IP necesaria, debe desconectarse de cualquier servicio de VPN y ejecutar (Invoke-WebRequest -Uri "https://ipinfo.io/ip").Content en una ventana de PowerShell local (no en este explorador). Anote la dirección IP resultante.

  2. Ejecute el script siguiente en Azure Cloud Shell en el lado derecho de esta página. Cuando se le solicite, escriba una contraseña compleja y una dirección IP pública.

    $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)"

  3. En un archivo de texto o una ubicación similar, genere y almacene la información que necesitará a lo largo del módulo; para ello, ejecute el script siguiente en Azure Cloud Shell. Probablemente tendrá que presionar Entrar después de pegar el código porque la última línea no se ejecutará de forma predeterminada.

    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

    Importante

    No olvide anotar la contraseña, el identificador único y la región. Necesitará esta información a lo largo del módulo.

  4. Ejecute el script siguiente para implementar una base de datos de Azure SQL y un servidor lógico con el ejemplo AdventureWorks. Este script también agrega la dirección IP como una regla de firewall, habilita Microsoft Defender for Cloud y crea una cuenta de almacenamiento para su uso en unidades futuras.

    # 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"

  5. En el equipo local, abra SSMS y cree una conexión con el servidor lógico. Como nombre del servidor, escriba el nombre del servidor lógico de Azure SQL Database. Si antes no ha guardado el nombre, es posible que tenga que consultar en Azure Portal para obtenerlo. Por ejemplo: aw-server<id._único>.base_de_datos.windows.net.

    Azure Portal

    1. Cuando esté en Azure Portal, puede escribir AdventureWorks en el cuadro de búsqueda para encontrar la base de datos y su servidor lógico asociado.

    2. En el cuadro Autenticación, escriba Autenticación de SQL Server. Escriba el inicio de sesión y la contraseña de administrador del servidor correspondiente (la que ha proporcionado durante la implementación en el ejercicio anterior).

    3. Active la casilla Recordar contraseña y, a continuación, seleccione Conectar.

    Screenshot that shows how to connect to SQL Database in SSMS.

    Nota:

    En función de la configuración local (por ejemplo, VPN), es posible que la dirección IP del cliente sea diferente a la que ha usado Azure Portal durante la implementación. Si es así, aparecerá un mensaje en el que se indica, "La dirección IP del cliente no tiene acceso al servidor. Inicie sesión en una cuenta de Azure y cree una regla de firewall para habilitar el acceso". Si recibe este mensaje, inicie sesión con la cuenta que usa para el espacio aislado y agregue una regla de firewall para la dirección IP del cliente. Puede completar estos pasos mediante el asistente emergente en SSMS.

Finalización de PITR

Antes de continuar, es importante comprender el proceso recomendado para realizar PITR:

  1. Una tabla o base de datos se elimina por accidente.
  2. Determine el momento al que tiene que volver. Debe ser antes de que se produjera el error.
  3. Complete PITR a través de PowerShell o Azure Portal para volver a este momento. Este proceso implementa una base de datos nueva y restaura una copia de la base de datos. Por ejemplo: AdventureWorks-copy.
  4. Confirme que la nueva base de datos (por ejemplo, AdventureWorks-copy) se encuentra en el estado correcto (como antes de que se produjera el accidente).
  5. Cambie el nombre de la base de datos original. Por ejemplo, cambie el nombre de AdventureWorks por AdventureWorks-old.
  6. Cambie el nombre de la base de datos nueva por el de la original. Por ejemplo, cambie el nombre de AdventureWorks-copy por AdventureWorks.
  7. Elimine la base de datos original. Por ejemplo: AdventureWorks-old.

En este ejercicio, completará estos pasos.

Simulación de la eliminación de datos

En primer lugar, se confirmará que la tabla que se va a eliminar accidentalmente existe y que contiene datos. Ahora se verán algunos de los valores de SalesLT.OrderDetail.

  1. Vaya a SSMS y compruebe o actualice la conexión. Seleccione Archivo>Conectar Explorador de objetos y, después, seleccione el botón Opciones.

  2. Asegúrese de que la conexión que usa se conecta al servidor lógico, pero no a una base de datos concreta. (Por ejemplo, use <default> como se muestra en la captura de pantalla siguiente). Además, confirme que la pestaña Parámetros de conexión adicionales no contiene texto.

    Screenshot that shows the default connection.

  3. Expanda la carpeta Bases de datos y haga clic con el botón derecho en la base de datos AdventureWorks y seleccione Nueva consulta. Escriba la consulta siguiente y ejecútela seleccionando Ejecutar y, a continuación, revise los resultados:

    SELECT TOP 10 * from SalesLT.SalesOrderDetail

    Screenshot that shows the sales order detail table.

  4. Simule la pérdida de datos mediante la eliminación de una tabla de la base de datos.

    En la misma ventana de consulta, ejecute esta consulta y, a continuación, seleccione la pestaña Mensajes en la ventana Resultados y anote la hora de finalización:

    DROP TABLE SalesLT.SalesOrderDetail

    Importante

    Guarde la hora de finalización. Lo necesitará más adelante. Este es un ejemplo: Completion time: 2020-06-22T09:20:27.1859237-07:00.

  5. Por último, antes de iniciar los pasos para restaurar la base de datos, ejecute el código siguiente en Azure Cloud Shell en el lado derecho de esta página para configurar el entorno:

    $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

    Los parámetros group y sql-server devueltos deben coincidir con los nombres del grupo de recursos de Microsoft Learn y el servidor lógico de Azure SQL Database.

Identificación del momento dado al que se va a restaurar la base de datos

El primer paso consiste en determinar el momento al que se debe restaurar la base de datos. Debe saber cuándo se ha producido la última transacción "correcta" antes de la "incorrecta". Realizará la restauración antes de la transacción incorrecta, pero después de la última correcta.

  1. Una manera de determinar la hora de eliminación consiste en examinar la de la instrucción DROP, que ha anotado en el paso anterior.

    Una manera alternativa es usar los registros de auditoría en Azure Portal. En este ejercicio, no ha configurado la auditoría en Log Analytics, pero se explorará lo que podría hacer si lo hubiera hecho. En Azure Portal, vaya a la base de datos de Azure SQL. En el panel de la izquierda, en Seguridad, puede seleccionar Auditoría y después Ver registros de auditoría. Al seleccionar Log Analytics, se le dirigirá a un editor de consultas que le permite consultar los registros mediante el lenguaje de consulta Kusto (KQL). Los profesionales de SQL pueden usar este lenguaje para consultar registros con facilidad.

    A continuación, puede ejecutar la siguiente consulta KQL:

    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

    Los resultados deben ser similares a los siguientes, pero con otra fecha y otra hora.

    Screenshot that shows Log Analytics results.

    Nota:

    Los registros pueden tardar entre 5 y 10 minutos en aparecer aquí, así que, a efectos de este ejercicio, lo hemos omitido. En su lugar, usará la hora de finalización que anotó en el paso anterior. (Tendrá que convertirla a GMT). En una situación real, no es probable que pueda acceder a la ventana con el tiempo de finalización, por lo que la auditoría puede ser una gran ayuda.

  2. En este ejemplo, la fecha y hora es 2020-07-24 08:06:24.386 desde Log Analytics y 2020-07-24T13:06:24.386-07:00 desde SSMS. El formato requerido es ligeramente diferente. Use el ejemplo siguiente para determinar el formato correcto. Es posible que también quiera restar 0,001 segundos para asegurarse de que se restaure a un momento anterior al error:

    • Formato de Log Analytics: 2020-07-24 08:06:24.386
    • Formato de SSMS: 2020-07-24T13:06:24.386-07:00
    • Formato requerido: 2020-07-24T20:06:24.385

  3. Establezca $before_error_time en el valor resultante, sustituyendo el tiempo por la hora de este ejemplo:

    $before_error_time ="2020-07-24T20:06:24.385"

Restauración de la base de datos y confirmación de los datos que faltan

En esta sección, usará az cli db restore para restaurar la base de datos a un momento anterior a la eliminación de la tabla.

  1. Ejecute el script siguiente en el terminal del lado derecho de esta ventana:

    # 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

    La restauración tardará entre 5 y 10 minutos. Al ejecutar una restauración, Azure implementa una nueva base de datos de Azure SQL en el servidor lógico de Azure SQL Database. La base de datos nueva tiene las mismas opciones de configuración que la original. Una vez que se ha implementado la base de datos de Azure SQL, Azure la restaura en la nueva base de datos de Azure SQL.

  2. Puede comprobar el estado si actualiza la vista de las bases de datos en SSMS. Haga clic con el botón derecho en la carpeta Bases de datos y seleccione Actualizar. Una vez que se haya implementado la base de datos, verá que la restauración está en curso:

    Screenshot that shows a database restoring in SSMS.

    Después de ver que la restauración está en curso, la restauración debe tardar entre dos y tres minutos más. Sabrá que ha terminado porque el comando se completará. Además, ya no verá "(Restaurando...)" junto a la base de datos de copia cuando inicie una actualización.

    Si observa que la restauración tarda más de lo que se ha descrito antes, es posible que se deba al entorno de Microsoft Learn. Hay un número limitado de solicitudes de restauración que se pueden procesar o enviar a la vez para una misma suscripción. Si quiere obtener más información sobre los límites y los detalles relacionados sobre PITR mientras espera, consulte Restauración de una base de datos a partir de una copia de seguridad en Azure SQL Database.

  3. Ahora confirmará que la nueva base de datos se encuentra en el estado correcto (como antes de que se produjera el accidente). Haga clic con el botón derecho en el servidor lógico en SSMS y, después, seleccione Actualizar para actualizar la conexión al servidor lógico de Azure SQL Database.

  4. Haga clic con el botón derecho en la base de datos nueva (por ejemplo, AdventureWorks-copy) y seleccione Nueva consulta.

    Screenshot that shows how to create a query.

  5. Use esta consulta para confirmar que la tabla existe:

    SELECT TOP 10 * from SalesLT.SalesOrderDetail

    Debe obtener resultados similares a los que se muestran en la captura de pantalla siguiente. Este resultado confirma que la base de datos se ha restaurado al punto deseado.

    Screenshot that shows the sales order detail table.

Intercambio de bases de datos y limpieza

A continuación, cambiará el nombre de la base de datos original a AdventureWorks-old para que más tarde pueda cambiar el nombre de la nueva base de datos para usar el de la original. Mientras que las aplicaciones usen lógica de reintento, este cambio hará que no sea necesario modificar ninguna cadena de conexión.

Si, en algún momento, la base de datos parece no disponible (por ejemplo, no se puede conectar a las bases de datos en SSMS si actualiza la conexión), es posible que se deba a actualizaciones de la tabla DNS. Por tanto, aunque la base de datos no esté disponible físicamente, es irresoluble. Si espera un minuto aproximadamente, debería poder reanudar las actividades normales.

  1. Use este comando para cambiar el nombre de la base de datos:

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

  2. Ahora que el nombre de la base de datos original ya no está en uso, puede cambiar el nombre de la base de datos de copia al de la original, de nuevo mediante Azure Cloud Shell:

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

  3. No necesita la base de datos antigua, por lo que puede eliminarla mediante az sql db delete:

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

  4. Puede confirmar que la base de datos antigua ya no existe mediante este comando:

    az sql db list -o table

Ya ha visto cómo puede usar PITR en Azure SQL Database. PITR también está disponible en Azure SQL Managed Instance para bases de datos, pero no para una instancia completa. Puede usar casi los mismos comandos, salvo que tendrá que utilizar az sql midb en lugar de az sql db.