Copia de seguridad y restauración de WordPress

Introducción

Este documento describe cómo utilizar CloudCenter para migrar una aplicación para realizar una copia de seguridad y restaurar el contenido en un depósito Amazon S3.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Linux
• CloudCenter
• Amazon S3 

Componentes Utilizados

La información de este documento se basa en CloudCenter v4.8.1.1.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Antecedentes

Este documento asume que CloudCenter ya está instalado y funciona correctamente. Además, WordPress ya se ha modelado y se ha confirmado que funciona correctamente. Este proceso solo se ha probado con el uso de un depósito S3 como repositorio y migra de una implementación a otra entre nubes públicas, aunque debe funcionar entre nubes públicas y privadas siempre y cuando se confirme la conectividad con el depósito S3 en la nube de destino. Este procedimiento sólo debe hacerse para una prueba de concepto. No utiliza las prácticas recomendadas, ya que las claves secretas están codificadas en el script para facilitar su uso. Los scripts especificados fueron escritos para CentOS con el uso de un servidor web Apache.

Recopilar información necesaria

CloudCenter utiliza algunos scripts para poder realizar copias de seguridad y restaurar los datos en la VM correcta, para poder rellenar los scripts es necesario recopilar de antemano alguna información.

• Nombre de la cubeta Amazon S3
• Trayectoria dentro de la cubeta donde se almacenan los datos de backup
• Clave Amazon S3
• Clave secreta Amazon S3

Nota: La cubeta S3 debe agregarse también como repositorio en CloudCenter.

Guiones de descarga y actualización

• Se necesitan cuatro secuencias de comandos para controlar la migración de WordPress. Dos scripts de copia de seguridad, uno para la base de datos y otro para el servidor web, y dos scripts de restauración. 
• Descargue BackupRestore.zip y extráigalo de RestoreServer.sh, RestoreDB.sh, BackupDB.sh y BackupServer.sh.
• Desde dentro de cada uno, actualice el Bucket, Path, S3 Key, S3 Secret.
• El script de respaldo para el servidor web comprime el /var/www/directory en un archivo llamado server.zip que se almacena en el directorio /tmp. Luego carga server.zip en el Bucket S3 con las credenciales especificadas.
• El script de restauración para el servidor web, descarga el archivo server.zip y lo descomprime en el directorio /var/www/. Ninguno de estos scripts realiza ninguna verificación de errores, ni verifican el SO instalado, esto puede causar problemas si WordPress se instaló en un sistema operativo diferente o con un servidor web diferente, excepto Apache.
• La secuencia de comandos de copia de seguridad para la base de datos realiza un vaciado de la base de datos y la comprime antes de que se cargue en el depósito S3.
• La secuencia de comandos de restauración para la base de datos crea la base de datos y, a continuación, utiliza el vaciado de la base de datos que descargó desde el bloque de servidores S3 para volver a crear la base de datos.

Nota: Estos scripts tienen la clave S3 y el secreto almacenados en texto sin formato, no se recomienda y sólo se debe utilizar como prueba de concepto o en el momento de la prueba inicial.

Después de actualizar todos los campos, cargue los scripts en un repositorio de CloudCenter para que se pueda hacer referencia a ellos en un perfil de aplicación.

Actualizar perfil de WordPress

Se necesitan algunas actualizaciones del perfil para hacer uso de estos nuevos scripts.

En WebServer, seleccione Migration y agregue una ruta de acceso a BackupServer.sh en Backup Script, también haga referencia a la Ubicación de Copia de Seguridad en la Ubicación de Copia de Seguridad y, finalmente, agregue la ruta de acceso a RestoreServer.sh en Restore Script como se muestra en la imagen.

RestoreServer.sh necesita permiso para poder descomprimir los archivos en /var/www/ que cliqruser no tiene permiso para hacer.  En Inicialización y limpieza de nodos, agregue unzip a la lista de comandos de Sudo. Esto le da al script el permiso para ejecutar unzip como root como se muestra en la imagen.

El nivel de base de datos necesita cambios similares a los de WebServer, a saber, el script de copia de seguridad, la ubicación de copia de seguridad y la secuencia de comandos de restauración como se muestra en la imagen.

Una vez realizados estos cambios, simplemente guarde el perfil de la aplicación.

Ahora, una nueva implementación debe poder migrarse de un nodo a otro.