Menu
Hacer un backup de cloud a Cloud con Microsoft Azure. AWERTY

Backup en Microsoft Azure: origen y destino en el cloud

, , , , , , , ,

En la actualidad, hacer un backup de datos en un entorno virtualizado no tiene por qué suponer un quebradero de cabeza para los técnicos o las empresas, siempre y cuando se trabaje con productos potentes como ARCServe Unified Data Protecion (UDP). Tampoco debería complicarse demasiado cuando lo que necesitamos es guardar datos en un destino cloud, como por ejemplo podríamos hacer con ARCServe Backup o ARCServe UDP.

Ahora bien, el reto que planteamos es este artículo es hacer backup en Microsoft Azure sin réplica fuera del cloud. Es decir, con origen y destino en Microsoft Azure.

Los datos técnicos de ARCServe UDP especifican que se puede configurar un destino cloud de Azure para las copias de datos en una sub tarea de un plan de copia. Pero podríamos ir un poco más allá y querer tener una copia (aunque sin deduplicación) de las máquinas en un destino de almacenamiento Azure, al mismo tiempo que hacemos el backup desde el propio entorno Azure.

En ese caso, el planteamiento quedaría resumido de la siguiente forma:

  • Una máquina Azure para que haga las copias (ARCServe UDP)
  • Mecanismos para que la máquina Azure solo se encienda para hacer el backup y posteriormente se apague sola.
  • Un almacenamiento Azure para que sea el destino de las copias de seguridad.

1. Máquina Azure para hacer las copias

El primer paso, está claro: contratar una máquina Azure. Podría perfectamente tratarse de una tipo D2 (dos cores, 7GB de RAM). Contratada y arrancada, realizaremos la instalación de ARCServe UDP.

2. Usar Runbooks para economizar el uso de la máquina

No nos interesa que una máquina cuya contratación se factura en base al uso esté permanentemente encendida, su coste se dispararía. Por lo tanto, lo recomendable es habilitar Runbooks para este equipo.

Los Runbooks sólo se pueden autorizar si se añade un certificado que subiremos a Ms Azure para dar nuestra conformidad de que se pongan en marcha de forma remota. Este certificado se puede crear desde cualquier máquina de dos formas:

  • Opción 1. Con selfcert.exe si se tiene un Office instalado. La ruta al ejecutable es
    C:\Program Files\Microsoft Office\Office (número de la versión\selfcert.exe.
    En el proceso deberemos darle el nombre ‘CertificateName’. Es importante seguir esta recomendación, hemos observado que con un nombre propio a veces ocasiona problemas.
  • Opción 2. Con Internet Information Server. Puedes leer el proceso aquí. De la misma forma que en la opción anterior, le daremos el nombre ‘CertificateName’.
    Cuando ya tengas el certificado creado, inclúyelo en Azure. En la parte de automatización, dirígete a ‘Activos’ e importa el certificado.

A continuación, se tiene que fabricar los Runbooks que nos permitirán tener en marcha la máquina sólo durante la ventana de backup. Este proceso se hace desde el portal de Azure, deberás crear dos procedimientos separado:  uno que la encienda y otro que la apague. En el apartado de ‘Automatización’, accede a Runbooks  y crea uno nuevo. Insisto: deberás hacer el proceso dos veces, una para el encendido y otra para el apagado. A continuación podrás ver qué código debe incluir cada uno.

Una vez dentro del Runbook, ve al apartado ‘Autor’ y añade el script que corresponda:
Runbook para iniciar la máquina
(copiar, respetar los saltos y cambiar el nombre del equipo)

[sourcecode language=»powershell»]
workflow IniciarVMs
{

Param
(
[parameter(Mandatory=$true)]
[String]
$VMName = » NOMBRE_DEL_EQUIPO_AZURE «,

[parameter(Mandatory=$true)]
[String]
$ServiceName = » NOMBRE_DEL_EQUIPO_AZURE »
)

Write-Output «inicio»;

$subscriptionName = Get-AutomationVariable -Name «SubscriptionName»
Write-Output $subscriptionName;
$subscriptionID = Get-AutomationVariable -Name «SubscriptionID»
Write-Output $subscriptionID;
$certificateName = «CertificateName»
Write-Output $certificateName
$certificate = Get-AutomationCertificate -Name $certificateName

Set-AzureSubscription -SubscriptionName $subscriptionName -SubscriptionId $subscriptionID -Certificate $certificate
Select-AzureSubscription $subscriptionName
Write-Output «Certificado OK»
Start-AzureVM -Name $VMName -ServiceName $ServiceName
Write-Output «Máquina arrancada!»
}
[/sourcecode]

Runbook para apagar la máquina
(copiar, respetar los saltos y cambiar el nombre del equipo)
[sourcecode language=»powershell»]
workflow ApagarVMs
{

Param
(
[parameter(Mandatory=$true)]
[String]
$VMName = «NOMBRE_DEL_EQUIPO_AZURE»,

[parameter(Mandatory=$true)]
[String]
$ServiceName = » NOMBRE_DEL_EQUIPO_AZURE »
)

Write-Output «inicio»;

$subscriptionName = Get-AutomationVariable -Name «SubscriptionName»
Write-Output $subscriptionName;
$subscriptionID = Get-AutomationVariable -Name «SubscriptionID»
Write-Output $subscriptionID;
$certificateName = «CertificateName»
Write-Output $certificateName
$certificate = Get-AutomationCertificate -Name $certificateName

Set-AzureSubscription -SubscriptionName $subscriptionName -SubscriptionId $subscriptionID -Certificate $certificate
Select-AzureSubscription $subscriptionName
Write-Output «Certificado OK»
Stop-AzureVM -Name $VMName -ServiceName $ServiceName -Force
Write-Output «Máquina detenida!»
}
[/sourcecode]

Los runbooks aún no están listos, aún hay que crear las variables ‘SubscriptionID’ y ‘SubscriptionName’. Ambas se configuran en el apartado de Automatización / Activos. De nuevo, habrá que crear dos tipos de variable en ambos.

  • Uno se llamará “SubscriptionName”, y en el valor, deberemos ponerle el nombre de la subscripción
  • El otro, será “SubscriptionID”, y en el valor, deberemos ponerle el ID de subscripción

Cuando los Runbooks estén operativos, tendrás que programarlos según la ventana de backup que se te plantee. Es decir, si el backup está previsto que arranque a las 22 h puedes programar el runbook de arranque para las 21:50h. Y si después de unos días de test detectas que las copias tienen una duración de cuatro horas, por ejemplo, podrás programar el runbook de apagado para las 2:10h.

3. Un almacenamiento para UDP

El paso siguiente será crear un almacenamiento donde podamos almacenar las copias de seguridad que hará ARCServe UDP. Para ello, crea un almacenamiento de Azure File. El servicio de Azure File todavía está en fase preview, pero es plenamente operativo. En esta web, puedes crear el almacenamiento, pero las operaciones las harás a través de Azure Power Shell. Este Power Shell que conecta con Azure, debe descargarse desde aquí.

Una vez lo tengas descargado e instalado, lanza estos comandos:
[sourcecode language=»powershell»]
PS C:\> Get-AzurePublishSettingsFile
PS C:\> Import-AzurePublishSettingsFile «RUTA_DONDE_HAYAMOS_DESCARGADO_LOS_SETTINGS-Y_EL_FICHERO»
PS C:\> Get-AzureStorageAccount
PS C:\> Get-AzureStorageKey -StorageAccountName NOMBRE_DEL_ALMACENAMIENTO_QUE_HEMOS_CREADO_PREVIAMENTE
(en este comando nos dará el par de claves de encriptación que debemos guardar)
PS C:\> New-AzureStorageContext -StorageAccountName NOMBRE_DEL_ALMACENAMIENTO_QUE_HEMOS_CREADO_PREVIAMENTE –CLAVE_PRIMARIA_DE_ENCRIPTACIÓN
PS C:\> New-AzureStorageShare NOMBRE_PARA_CARPETA_COMPARTIDA -Context $ctx
[/sourcecode]

Con estos comandos vía Azure Power Shell tendrás un almacenamiento Azure File a punto para ser usado desde tus máquinas Azure. En la máquina que hayas instalado ARCServe UDP, mapea el almacenamiento para que pueda ser el destino de las copias. Puedes hacerlo mediante NET USE como si mapearas una unidad de red cualquiera. La única diferencia es que la contraseña será la segunda clave de encriptación que antes hemos sacado con Power Shell:
net use z: \\solscifs.file.core.windows.net\backup /persistent:YES

El usuario de validación será el mismo usuario Administrador que hayas creado para el entorno Azure.

Dentro de ARCServe UDP puedes crear planes de copia (sin servidor RPS y por lo tanto sin deduplicación) que tengan como destino la unidad Z: que has mapeado en el servidor.

Related Posts