En la última publicación, exploramos cómo mover parte de nuestras bases de datos a la nube creando un nuevo archivo en el servicio de almacenamiento de blobs de Azure, lo cual es genial, pero para ser honesto, este tipo de solución híbrida podría no darnos lo mejor de la nube.
Uno de los motivos utilizados por Microsoft para vender su nube es que afirman que mudarse a Azure facilitará la forma en que mantenemos nuestras bases de datos.
Y una de las cosas más importantes cuando trabajamos con bases de datos es siempre tener disponible una buena copia de seguridad en caso de que se necesite.
Una vez nuestras bases de datos hayan crecido hasta cierto punto, simples tareas de mantenimiento como realizar una copia de seguridad pueden ser un desafío, tomando varias horar para completar y probablemente para restaurar, lo que afectará nuestro RTO y por lo tanto comprometerá nuestros SLA.
Pero volviendo a Azure, ¿qué herramientas existen para permitirnos reducir este tiempo de recuperación desde copia de seguridad? Sí, era fácil, solo hace falta mirar el título de esta publicación … ‘backups de archivos instantáneos‘
Acabando el trabajo del último día
Una de las limitaciones de estas copias de seguridad de archivos instantáneos (y probablemente la más importante) es que todos nuestros archivos de bases de datos deben estar almacenados en la nube, de modo que podemos tomar mi publicación anterior como preparación para lo que viene ahora.
Para mover nuestros archivos a la nube, tenemos diferentes posibilidades, uno podría ser el enfoque típico en el que se nos permite pasar un tiempo inactivo.
Utilizando la misma base de datos de la última publicación, procederemos, pero primero recordemos que teníamos una base de datos con tres archivos en local y otro almacenado en el almacenamiento de blobs de Azure. Algo asi como esto.
Entonces los tres archivos restantes también tienen que ir a la nube.
USE [master] GO ALTER DATABASE [stretch_test] MODIFY FILE (NAME = N'st_primary', FILENAME = N'https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>/st_primary.mdf') GO ALTER DATABASE [stretch_test] MODIFY FILE (NAME = N'st_user_data', FILENAME = N'https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>/st_user_data.ndf') GO ALTER DATABASE [stretch_test] MODIFY FILE (NAME = N'st_Log', FILENAME = N'https://<mystorageaccountname>.blob.core.windows.net/<mystorageaccountcontainername>/st_log.ldf') GO
Una vez que hayamos modificado nuestra base de datos, podemos poner la base de datos OFFLINE.
USE master ALTER DATABASE stretch_test SET OFFLINE WITH ROLLBACK IMMEDIATE
Y luego movemos los archivos al almacenamiento de blobs de Azure. Esto se puede hacer utilizando la funcionalidad de carga integrada en el almacenamiento de blobs de Azure o utilizando powershell.
Cargar los archivos usando Azure Portal
Esto es muy intuitivo, pero por las dudas.
Deberá ir a ‘Todos los recursos → Su cuenta de almacenamiento → Blobs → Su contenedor → Cargar’
Luego encontrarás algo como esto, donde puedes navegar tus archivos para localizarlos y subirlos
**Importante para seleccionar ‘Página Blob’ si no que te pase esto**
Si se pasó esto, y has seleccionado ‘Block blob’, luego al tratar de poner la base de datos ONLINE, recibiréis este error.
La única solución alternativa que encontré es detener el servidor (ya que la base de datos tampoco quiere desconectarse) para liberar los archivos en Azure y luego eliminarlos y cargarlos de nuevo, esta vez con el tipo de blob correcto.
Cargar los archivos usando Powershell
Podemos usar Powershell para copiar los archivos en la nube usando este ejemplo.
# begin
# Update with the name of your subscription.
$SubscriptionName = "YourSubscription"
# Update with the name of your storage account.
$StorageAccountName = "yourstorageaccount"
# Choose your location, see Get-AzureRmLocation for choices
$Location = "YourLocation"
# Update with the name of your container.
$ContainerName = "YourContainer"
# All your database files to be moved to Azure.
$FilesToUpload = @("C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQL2016\MSSQL\DATA\move_to_az\move_to_az.mdf",
"C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQL2016\MSSQL\DATA\move_to_az\move_to_az_USER_DATA_1.ndf",
"C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQL2016\MSSQL\DATA\move_to_az\move_to_az_log.ldf")
# Update with the name of your resource group
$resourceGroupName= 'YourResourceGroup'
Login-AzureRmAccount
# set the tenant, subscription and environment for use in the rest of
Set-AzureRmContext -SubscriptionName $subscriptionName
# Get the access keys for the ARM storage account
$accountKeys = Get-AzureRmStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName
# Get account context using an ARM storage account
$storageContext = New-AzureStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys[0].Value
foreach ($FileToUpload in $FilesToUpload){
# Upload a blob into a container.
Set-AzureStorageBlobContent -Container $ContainerName -File $FileToUpload -Context $storageContext -BlobType Page # IMPORTANT!!!!
}
Eso moverá los archivos igual que la GUI, de nuevo recordaos el especificar el tipo de blob correcto para evitar problemas.
De vuelta a la vida
En este punto, somos buenos para traer nuestra base de datos ONLINE nuevamente sin problemas, así que vamos a hacerlo
USE master ALTER DATABASE stretch_test SET ONLINE WITH ROLLBACK IMMEDIATE
Exprimiendo la nube
Finalmente, con nuestra base de datos en línea y todos nuestros archivos en la nube, podemos aprovechar esta elegante función llamada ‘Copias de seguridad de archivo-instantánea’ que, de alguna manera, para aquellos con experiencia en entornos empresariales con infraestructura SAN puede sonar familiar.
Veo estas copias de seguridad de instantáneas de archivos como copias de seguridad de instantáneas SAN, por el hecho de que suceden de inmediato y no ocupan mucho espacio ya que están conectadas a los archivos originales, pero vamos a compararlas con copias de seguridad normales para ver si eso es cierto.
Con todo este movimiento de on-prem a la nube, casi olvido que nuestra base de datos está vacía 🙂 , así que primero vamos a poner algunos datos allí.
SELECT o1.* INTO dbo.some_data FROM sys.all_objects AS o1 WHERE 1=0 GO INSERT INTO dbo.some_data SELECT o1.* FROM sys.objects AS o1 CROSS JOIN sys.all_objects AS o2 GO 10
Me encanta este truco para crear copias rápidas de tablas y no preocuparme por programarlas, pero recordad que podrían ser diferente de las originales, ya que no se copian todas las propiedades.
Así que tenemos algunos datos, en mi caso unos 230MB así que tomemos una copia de seguridad SQL normales
USE master BACKUP DATABASE stretch_test TO URL = 'https://storageaccount.blob.core.windows.net/container/stretch_test_SQL_backup.bak' WITH COMPRESSION /* Processed 29800 pages for database 'stretch_test', file 'st_primary' on file 1. Processed 8 pages for database 'stretch_test', file 'st_user_data' on file 1. Processed 8 pages for database 'stretch_test', file 'st_stretch_data' on file 1. Processed 3 pages for database 'stretch_test', file 'st_Log' on file 1. BACKUP DATABASE successfully processed 29819 pages in 19.627 seconds (11.869 MB/sec). */
Observad que el rendimiento no es nada bueno, pero recordad que nuestros archivos están en la nube, el motor SQL en local y el destino de respaldo en la nube, por lo que dependemos totalmente de nuestra conexión a Internet a menos que queramos pagar un ExpressRoute.
Sobra decir que mover todos estos datos de la nube para adelante y atrás no es una gran idea, ¡advertidos estáis!
Ahora veamos con la nueva característica.
USE master BACKUP DATABASE stretch_test TO URL = 'https://storageaccount.blob.core.windows.net/container/stretch_test_FS_backup.bak' WITH FILE_SNAPSHOT /* Processed 0 pages for database 'stretch_test', file 'st_primary' on file 1. Processed 0 pages for database 'stretch_test', file 'st_user_data' on file 1. Processed 0 pages for database 'stretch_test', file 'st_stretch_data' on file 1. Processed 0 pages for database 'stretch_test', file 'st_Log' on file 1. BACKUP DATABASE successfully processed 0 pages in 0.494 seconds (0.000 MB/sec). */
Wow, ¿cómo es posible? menos de un segundo, y de acuerdo con esto, SQL Server en realidad no ha procesado nada, por lo que todo ha sucedido entre bambalinas en la nube.
Ahora, si vamos al Azure Portal para ver esos archivos, podemos ver que son diferentes.
La copia de seguridad regular tomó 3.5MB (gran hurra para compresión de copias de seguridad) pero la instantánea solo tomó 0.5MB y ese número es consistente independientemente del tamaño de la base de datos, por lo que siempre tomará medio megabyte, por lo que he visto.
Cómo los archivos de copia de seguridad son diferentes
Para responder a esa pregunta, echemos un vistazo más de cerca a la copia de seguridad de instantáneas de archivos para descubrir la diferencia.
USE master RESTORE FILELISTONLY FROM URL = 'https://storageaccount.blob.core.windows.net/container/stretch_test_FS_backup.bak'
Aha! Como sospechaba, no son más que instantáneas de almacenamiento, pero dado que están completamente integradas con SQL Server, el proceso para hacer Backup / Restores es el mismo que hemos hecho durante años. Hay más información y ejemplos de copias de seguridad de archivos_snapshots en Books Online y Channel9, por lo que le recomiendo que reviséis todo eso si esta funcionalidad es algo que planeais implementar
Conclusión
Existe una increíble variedad de nuevas funcionalidades, pero como siempre, no son gratuitas y hay muchos trucos que debemos saber antes de tomar decisiones tan importantes como trasladarnos a la nube.
Está bastante divertido jugar con la nube, por lo que os lo recomiendo a todos, incluso si no tienes ningún plan en un futuro cercano … nunca se sabe.
¡Gracias por leer y cualquier pregunta simplemente disparadla!
