IT001 – Copias de seguridad en servidores

1. Organización de servidores/servicios

Actualmente tenemos:

• Servidores en producción: Clouding
• Servidores en desarrollo: Ionos

Server web 1

2.1 Planteamiento previo

Para determinar la frecuencia adecuada para realizar la tarea programada (plesk/plugin) de backups sobre las estructuras (+BBDD [opcional]), se debe considerar varios factores importantes:

• Frecuencia de actualización del sitio
  • Sitios Estáticos: El site no cambia con frecuencia, un backup semanal o incluso mensual puede ser suficiente.
  • Sitios Dinámicos: El site se actualiza regularmente con contenido nuevo (blogs, noticias, funcionalidades), un backup diario es recomendable.
  • E-commerce o Sitios Críticos: Para sitios de comercio electrónico o aquellos donde los datos cambian constantemente (pedidos, usuarios), se pueden realizar backups horarios o al menos diarios.
• Volumen de datos
  • Alto volumen de datos: Si el site genera grandes volúmenes de datos (archivos subidos por usuarios, registros), es necesario realizar backups más frecuentes para no perder información.
  • Bajo volumen de datos: Menos cambios pueden permitir una menor frecuencia de backups.
• Requisitos de recuperación
  • Pérdida de datos crítica: Si la pérdida de datos puede ser catastrófica, aumenta la frecuencia de los backups.
  • Recuperación menos crítica: Si se puede tolerar algo de pérdida de datos, una menor frecuencia puede ser aceptable.
• Capacidad de almacenamiento
  • Espacio disponible: Es imprescindible contar con suficiente espacio para almacenar los backups. La compresión y la eliminación de backups antiguos pueden ayudar en el mantenimiento del mismo.

2.2 Situación actual

Los backups que se definen en este apartado son realizados por la propia plataforma/dominio sin usar el servicio de backup del servidor Clouding que se especifica en el apartado 5 de este artículo.

• Server Web 1
  • Dominio: okodia.com
    • Frecuencia de backup: Diario
    • Razón: Alto uso de disco y tráfico mensual indican un sitio con mucha actividad y cambios frecuentes.
  • Dominio: okomeds.com
    • Frecuencia de backup: Semanal
    • Razón: Uso moderado del disco y tráfico mensual moderado sugieren cambios regulares pero no diarios.
  • Dominio: oqodia.com
    • Frecuencia de backup: Mensual
    • Razón: Uso moderado del disco y tráfico mensual moderado.
  • Dominio: okosmetics.com
    • Frecuencia de backup: Semanal
    • Razón: Uso de disco y tráfico relativamente bajos.
  • Dominio: crm.okodia.com
    • Frecuencia de backup: Diaria
    • Razón: A pesar del uso de disco bajo, la naturaleza crítica de un CRM requiere backups más frecuentes.
  • Dominio: kelsen-hart.es
    • Frecuencia de backup: Semanal
    • Razón: Uso de disco moderado y tráfico bajo.
  • Dominio: okopedia.okodia.com
    • Frecuencia de backup: Diario
    • Razón: Uso y tráfico bajos, cambios esporádicos.
  • Dominio: okngo.org
    • Frecuencia de backup: Mensual
    • Razón: Uso y tráfico bajos, cambios esporádicos.
  • Dominio: gossassenegal.org
    • Frecuencia de backup: Mensual
    • Razón: Uso de disco moderado y tráfico bajo.
• Server Web 2
  • Dominio: iuratum.es
    • Frecuencia de backup: Diario
    • Razón: Alto uso de disco y tráfico mensual indican un sitio con mucha actividad y cambios frecuentes.
  • Dominio: envolvis.es
    • Frecuencia de backup: Diario
    • Razón: Alto tráfico mensual y uso de disco moderado indican mucha actividad y cambios frecuentes.
  • Dominio: shop.iuratum.es
    • Frecuencia de backup: Cada 4 horas
    • Razón: Alto uso de disco y tráfico mensual indican un sitio con mucha actividad y cambios frecuentes.

2.3 Metodología de backups

La metodología empleada para realizar los backups en servidores Linux se divide entre las plataformas WordPress (WP) y las que no lo son.

2.3.1 Plataformas WordPress

Se realiza copia de las plataformas con mayor carga/visitas mensuales. En este tipo de plataformas se hace uso de la herramienta Duplicator que realizará, los días indicados en el apartado 2.2 Situación actual, tres tipos de backup:

• BackUp completo con BBDD
• BackUp sin BBDD
• BackUp solo BBDD

Nota: los desarrolladores de Duplicator tienen previsto actualizar el plugin, lo que hará que, una vez a la semana, se haga un backup recovery que usa una url para restaurar el site al completo al punto en el que se realizó.

Estos backups se almacenan en el servidor Dropbox. Las imágenes en Dropbox tendrán tres días de antigüedad como máximo, los nuevos backups sobreescriben a los más antiguos.

Se añaden capturas de pantalla del contenedor Dropbox. La primera captura muestra una parte del listado de sites que han realizado backup. La segunda captura muestra un ejemplo de lo que almancena de un site de ejemplo.

2.3.2 Plataformas NO WordPress

Teniendo tres plataformas que atender (CRM, Shop Iuratum, Envolvis), los respaldos de estas se realizarán mediante tarea programada siguiendo las pautas indicadas en el apartado 2.2 Situación actual, realizando una copia de todos los archivos y estructura según plataforma, a:

• crm.okodia.com -> backup.okodia.com -> Tarea Programada en PLESK, volcado a carpeta CRMBackup de Dropbox
• shop.iuratum.es -> backup.iuratum.es -> Tarea Programada en Cron directamente por SSH, volcado a carpeta IuratumBackup de DROPBOX

De la misma manera se realizará una copia de la BBDD correspondiente que será almacenada en Dropbox y en el propio servidor guardando como máximo 4 copias de seguridad por site.

• envolvis.es -> Tarea Programada en PLESK
• crm.okodia.com -> realizada por .sh en /usr/local/bin/backup_crmbbdd.sh + cron Plesk
• shop.iuratum.es -> Tarea Programada en PLESK

3. Procedimiento de actuación ante cambios que deban realizarse en los servidores

3.1 Procedimiento común obligatorio a todas las plataformas

• Es obligatorio realizar snapshot de servidor antes de realizar modificaciones en PROD, o de implementar nuevas funcionalidades desde DEV a PROD.
• Nunca se publicarán cambios en viernes o visperas de festivo.
• Se limpiarán los snapshots antiguos, los que tengán más de 2 semanas cuando se haya confirmado que los cambios actuales funcionan correctamente.

3.2 Plataformas WordPress

• Si se puede revertir la acción que produjo la desconfiguración/malfunción: se procederá a realizar el ‘undo’ de la operación, es decir revetir lo realizado.
• Si no se puede/conoce cómo revertir la desconfiguración/malfunción y se tiene acceso al back (dominio/wp-admin):
  • Se usará la herramienta Duplicator (plugin de wordpress) de tal manera que:
    • si no tiene que ver con la base de datos: se usará el paquete sin bbdd.
    • si tiene que ver con la bbdd: se puede restaurar paquete que contenga también la bbdd.
• Si no se puede/conoce cómo revertir la desconfiguración/malfunción y se tiene acceso a FTP/SSH:
  • accederemos a las carpetas mencionadas anteriormente y se realizaría una copia del directorio de backup al directorio de PROD, si fuera necesario incluyendo backup bbdd.
• Si no se puede/conoce cómo revertir la desconfiguración/malfunción y no se tiene acceso al back (dominio/wp-admin): tenemos dos opciones:
  • usar el link recovery (cuando estuviera disponible)
  • montar un WordPress en el espacio del dominio/subdominio correspondiente de la version que correspondiera al site (relación de versiones de WP y Duplicator en el apartado 4. Levantar sites WordPress mediante FTP).
• Si todo fallara se puede usar el snapshot de la máquina creado, revisando las posibles pérdidas de registros. Ver apartado 5. Recuperar copias de seguridad en Clouding.
• Al publicar se realizará testeo standard web:
  • Se probará la navegación por la web.
  • Se chequeará que llegan los correos de los formularios de presupuestos.

3.3 Plataformas NO WordPress

CRM, Envolvis, Iuratum

• Si se puede revertir la acción que produjo la desconfiguración/malfunción: se procederá a realizar el ‘undo’ de la operación, es decir revetir lo realizado.
• Si no se puede/conoce cómo revertir la desconfiguración/malfunción y se tiene acceso a FTP/SSH:
  • accederemos a las carpetas mencionadas en el apartado 2.3.2 y se realizaría una copia del directorio de backup al directorio de PROD, si fuera necesario incluyendo backup bbdd.
• Si todo fallara se puede usar el snapshot creado, revisando las posibles pérdidas de registros. Ver apartado 5. Recuperar copias de seguridad en Clouding.
• Al publicar se realizará testeo específico para la plataforma que corresponda.

3.4 Servidor Nextcloud

• Los despliegues deberán ser acordados con el responsable de Okodia.
• Al publicar, se realizará testeo específico:
  • Se probarán los directorios compartidos con usuarios y grupos.
  • Se pedirá a la persona responsable de Okodia, que haga un checkeo en 2 usuarios reales.

3.5 Servidores Windows

3.5.1 GroupShare

• Los despliegues deberán ser acordados con el responsable de Okodia.
• Al publicar se necesitará la supervisión del personal del grupo Okodia para validar que todo está correcto.

3.5.2 Plunet

• Los despliegues deberán ser acordados con el responsable de Okodia.
• Al publicar se necesitará la supervisión del personal del grupo Okodia para validar que todo está correcto.

3.6 Servidor AIDOKO

Volcado en Dropbox > plesk-backup > aidoko-server-backup

4. Levantar sites WordPress mediante FTP

• okodia.com -> Revisar archivo > wp-includes > versión.php
• okomeds.com -> WordPress 6.2.2
• iuratum.es -> WordPress 6.2.5
• okosmetics.com ->WordPress 6.2.5
• kelsen-hart.es -> WordPress 6.2.5
• oqodia.com -> WordPress 6.2.2
• okngo.org -> WordPress 6.2.5
• okopedia.okodia.com -> WordPress 6.4.2
• crm.okodia.com/wpmodules/incidencias -> WordPress 6.0
• crm.okodia.com/wpmodules/okorrecetas/ -> WordPress 6.0.1
• crm.okodia.com/wpmodules/buddypress -> WordPress 6.0.2
• crm.okodia.com/wpmodules/lms -> WordPress 6.0.2

Descarga: https://es.wordpress.org/download/releases/

Debe utilizarse como bbdd la misma que usa el site que queramos recuperar con sus credenciales de acceso.

Una vez que funcione el WordPress provisional en el (sub)dominio correspondiente instalaremos el plugin Duplicator y usaremos la clave de Licencia para habilitar las funciones Pro mediante el backend (Dashboard):

Descarga y Licencia: https://duplicator.com/my-account/licenses/

Se procederá a importar el paquete a recuperar y realizar la acción. El site debería quedarse en el punto en el que se creó el paquete de restauración.

4.1 Cómo realizar la restauración usando Duplicator

Accedemos a la herramienta a través del panel de Administrador:

Seleccionamos el paquete a restaurar:

Hacemos click en “Restore”:

Hacemos click en el check “I have read and accept…” se activará el botón “Restore Backup”:

Hacemos click en él y esperamos a que termine la restauración.

4.2 Restauración usando link de recuperación de Duplicator

Nota: esta función todavía no está disponible. Solamente está disponible para los backups no programados.

Copiaremos la url de recuperación en la ventana de dirección del navegador correspondiente y seguiremos los pasos hasta concluir.

4.3 Restauración de backups en Dropbox

Para restaurar crm.okodia.com|shop.iuratum.es|aidoko basta con acceder a Dropbox descargar el servidor/carpeta a restaurar y volcar en el servidor de producción correspondiente.

5. Recuperar copias de seguridad en Clouding

• Es obligatorio realizar snapshot de la máquina antes de recuperar cualquier backup.

• Puesto que implica restaurar toda la máquina, la acción de recuperar el servidor vía Clouding en producción SOLO se realizará cuando el resto de actuaciones comentadas anteriormente no sean efectivas.

5.1 Recuperar Snapshot