Hola a todos, recientemente en uno de nuestros clientes, hemos tenido que realizar un backup y posterior restore en SQL Server. A diferencia de un backup «clásico», a unidad de red, o a disco, hemos realizado el backup a una URL de Azure. Aunque el proceso es similar a un backup «clásico», hay ciertas peculiaridades que os vamos a contar.
¿Por qué hacer un backup a una URL de Azure?
En primer lugar, os vamos a contar el por qué. ¿Por qué hicimos un backup a una URL de Azure pudiendo hacer un backup tradicional? Existen tres motivos para ello:
- El espacio del backup no ocupa espacio en disco
- Para comparar tiempos entre un backup tradicional y un backup a Azure
- Para valorar si es la mejor opción de cara a la migración
El objetivo era mover las bases de datos de un servidor a otro para una subida versión de SQL Server. Teníamos esta opción disponible y decidimos probarla.
Primer problema
Lo primero que hay que tener en cuenta, es que necesitamos, además de la URL de Azure Blob Storage, un shared access signature (SAS). Esto realmente es un token que debe generarse desde Azure Blob Storage, en el container que queremos usar:
Para crearlo necesitamos la IP desde donde vamos a hacer los backups, para que solo se permitan conexiones desde la misma y una duración. Esto último es importante ya que si se pone una duración de un año por ejemplo, y hacemos un backup a esa URL de forma habitual, pasado 1 año empezarán a fallar, ya que habrá caducado el token.
En este caso, necesitamos acceso a la ruta del container para enviar ahí los backups. La segunda parte, lo que va detrás del signo de interrogación es el token, que nos lo pedirá para acceder.
Una vez que tenemos estos datos, si todo es correcto, nos creará una credencial (credential) en SQL Server para no tener que indicar el token en cada backup.
Hecho esto, ya podemos realizar un backup y un restore. El procedimiento sería el siguiente:
En el servidor origen, realizamos el backup:
BACKUP DATABASE [test_gpsos] TO URL = N'https://nombre_blob_storage.blob.core.windows.net/backup/nombre_fichero_de_backup.bak'
WITH COPY_ONLY, INIT, FORMAT, STATS = 10
GO
Al ser para una migración le ponemos la siguientes opciones, en un backup diario habitual cambiaría. Con COPY_ONLY no interferimos en los backups de log actuales, y con format, si el fichero existe en destino lo reemplaza. Como solo queremos tener una copia, la más actualizada, le indicamos este parámetro.
En el nuevo servidor, restauramos:
USE [master]
RESTORE DATABASE [test_gpsos_restored] FROM
URL = N'https://nombre_blob_storage.blob.core.windows.net/backup/nombre_fichero_de_backup.bak' WITH RESTORE, REPLACE, STATS = 5
GO
En este caso, hemos cambiado el nombre de la BBDD, pero podría mantenerse el mismo.
Conclusión
En este caso, tras realizar las pruebas, vimos que el proceso entero de backup / restore, se realizaba más rápido de manera local, pero puede ser una muy buena opción este método para un backup diario, o mantener ambas.
Si tu también estás pensando en subir de versión de SQL Server, podemos ayudarte, con nuestro servicio de soporte y mantenimiento SQL Server. Nuestros expertos DBAs con varias migraciones a sus espaldas, podrán ayudarte.
Si además quieres asegurarte de que no haya sorpresas, puedes usar nuestra herramienta Query Performance, para comparar el rendimiento de las queries en un entorno y otro, o si a raíz del cambio, hay que modificar alguna query porque tiene error.
No dejes una migración de SQL Server a la improvisación, confía en los expertos en bases de datos. Contacta con nosotros.
¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle. Más información en su página de LinkedIn.
Sígue a GPS en LinkedIn