Hyperbackup en Asustor

Creación de script para copia de seguridad completa en Asustor

Lo primero que tenemos que hacer es planificar lo que queremos hacer.

Os expongo lo que quiero hacer yo a falta de un programa como hyperbackup en un NAS de Synology que hace que tengas una copia exacta de tu NAS, por si ocurre alguna desgracia y tienes que rescatar un backup.

Creo, por lo que he podido investigar, que para Asustor no hay nada parecido, así que voy a crearmelo yo mismo.

Esta copia se hace en un disco duro externo. Este disco duro no puede estar siempre disponible porque en caso de ataque de ransomware, éste también sería encriptado ya que al tenerlo enchufado y montado, sería una unidad más disponible para sufrir el ataque. Así que me propongo lo siguiente:
1.- Creación de la tarea de copia de seguridad
2.- Montar el disco duro USB externo 5 minutos antes de iniciar la copia de seguridad
3-. Hacer un dump de las BBDD para que no haya problemas con estas en caso de tener que restaurarlas
4.-Automatizar la copia del archivo de configuración de portainer y pasarla al disco duro
5.-Hacer la copia programada de la configuración del NAS

Los enlaces a la documentación de ayuda que os comento en el video están aquí https://archivos.bilito.eu/s/k4OTU2O

1.- Creación de la tarea de copia de seguridad

Para ello desde el icono de copia de seguridad y restauración de nuestro panel en ADM programamos una tarea de copia donde vamos a definir la información a copiar y el dispositivo externo donde queremos hacer esa copia

Definiremos los días de repetición de esa copia y confirmaremos.

En mi caso configuro una copia de forma diaria a las 3 de la mañana.

2.-Montar el disco duro USB externo 5 minutos antes de iniciar la copia de seguridad

Tenía que hacer un script y me hacían falta dos datos, el primero el dispositivo en sí. En Unraid, gracias a sus registro público, podía ver todo lo que pasaba en el servidor, por ejemplo la ruta del disco si lo enchufaba a un puerto USB.
En Asustor y Synology es más difícil. Gracias a J F Caringi del grupo de Asustor, me comentó que ejecutará por terminal el comando dmesg que me mostró esto, al enchufar el disco duro.

asustor add disk dev sde
[359708.403564] BTRFS info (device sde1): flagging fs with big metadata feature
[359708.411045] BTRFS info (device sde1): disk space caching is enabled
[359708.417742] BTRFS info (device sde1): has skinny extents

Y el otro parámetro era la ruta de montaje. En mi caso se monta en /share/USB1

Para instalar nano en el Asustor, debemos hacer lo siguiente

Cree el archivo con el comando nano montar-disco.sh Cogí el código del script, cambiando esos parámetros y quedó así

#!/bin/bash

# Ruta del dispositivo USB (cambia "/dev/sdb1" por el dispositivo correcto)
USB_DEVICE="/dev/sde1" #en tu caso puede cambiar

# Ruta de montaje (puedes cambiarla según tus preferencias)
MOUNT_PATH="/share/USB1"

# Verifica si el dispositivo ya está montado
if grep -qs "$USB_DEVICE" /proc/mounts; then
    echo "El dispositivo ya está montado."
else
    # Crea el directorio de montaje si no existe
    mkdir -p "$MOUNT_PATH"

    # Monta el dispositivo USB
    mount "$USB_DEVICE" "$MOUNT_PATH"

    # Verifica si el montaje fue exitoso
    if [ $? -eq 0 ]; then
        echo "Dispositivo USB montado correctamente en $MOUNT_PATH"
    else
        echo "Error al montar el dispositivo USB."
        
    fi
fi

En Synology y su programador de tareas, le podemos decir que lo ejecute como root, en Asustor tenemos que ejecutarlo con sudo.

Al final, tras un reinicio del Asustor, me di cuenta que este script no valía porque cambiaba el identificador de la unidad.

Así que me dio por probar con el script que usaba en Synology.

echo 0 > /sys/bus/usb/devices/usb2/authorized
sleep 5
echo 1 > /sys/bus/usb/devices/usb2/authorized

Este script lo que hace es deshabilitar el USB correspondiente.

¿Por qué el 2 y no el 1?

Por ensayo y error. Al probar con el 1 se me desconectó el SAI que tengo enchufado al puerto trasero. Probé con el 2 y desconectó el USB delantero.

Como hay que habilitarlo a nivel root porque si no es así, no lo ejecuta, pues hay que cambiarle el propietario con el comando

sudo chown root:root montaje.sh

Luego le cambiaremos los permisos al archivo con el siguiente comando

sudo chmod 755 montaje.sh

Para hacer el desmontaje, simplemente cambié el orden del script para que hiciera lo inverso y seguí con el comando chown y los permisos chmod

Tendremos que crear la ejecución del script de forma periódica antes que se realice la copia de seguridad y la desconexión tras dicha copia.

Para ello, lo hacemos mediante el comando

sudo crontab -e

Y en esa página tendremos que editar ese archivo.

Al ser un archivo de sistema tendremos que editarlo a través de los comandos de VIM.

Una vez dentro del archivo

Pulsamos i para comenzar con el edición

En la primera línea escribimos

55 2 * * * sudo sh /RUTADONDEHAYASCREADOELSCRIPT/montaje.sh

0 5 * * * sudo sh /RUTADONDEHAYASCREADOELSCRIPT/desmontaje.sh

Pulsaremos la tecla ESC para salir del modo de edición y para guardar el archivo escribiremos :wq

Ya estarán los cambios guardados

3-. Hacer un dump de las BBDD para que no haya problemas con estas en caso de tener que restaurarlas

Seguía pensando en que información tenía que pasar a la copia de seguridad, así que me acordé que con las BBDD no bastaba con copiar su carpeta de docker.

Puede ser que sí, pero muchas veces da fallo.

Así que preguntando a Joan Romero https://hdsplus.co primero y a JF Caringi después, tenía los comandos para hacer un dump de una BBDD sql o mariadb

El comando genérico es el siguiente (tiene que ir en una sola línea de código)

docker exec NOMBREDELCONTENEDOR /usr/bin/mysqldump --all-databases --single-transaction -uTUUSUARIO -pTUPASSWORD NOMBREDELABBDD | gzip > /RUTADELACARPETAPARAGUARDAR/backup-$(date +\%Y\%m\%d).sql.gz

Estos datos los obtendremos de los parámetros MYSQL_USER, MYSQL_PASSWORD y MYSQL_DATABASE respectivamente que usamos al configurar el contenedor en portainer por ejemplo.

Yo en mi caso las guardo en una carpeta del volumen 2 y quedaría la siguiente ruta /volume2/Backup-equipos/back
ups-bbdd/ghost/backup-$(date +%Y%m%d).sql.gz

Esto hace que me quede el archivo así

Creo un dump para cada BBDD que tengo en mi servidor y lo añado a que lo haga en el script al montar el disco.

4.-Automatizar la copia del archivo de configuración de portainer y pasarla al disco duro

Si usas portainer como yo para la gestión de tus contenedores tendrás que guardar una configuración del portainer para que no perder los stacks con las rutas de cada contenedor y tener que configurarlo a mano en caso de recuperación de desastre.

Está copia la hacemos de forma manual desde Portainer/Settings y bajamos hacia abajo del todo y pulsaremos en Download Backup File y nos bajara el archivo con esa configuración, pero eso es un proceso manual y lo queremos tener automatizado.

Lo haremos mediante el Docker savagesoftware/portainer-backup:latest

Os dejo el docker-compose por aqui

version: '3.3'
services:
    portainer-backup:
        stdin_open: true
        tty: true
        container_name: portainer-backup
        restart: always
        volumes:
            - /TURUTADONDEQUIEREGUARDARLACOPIADESEGURIDAD:/backup #Ruta donde queréis que se guarde la copia
        environment:
            - PORTAINER_BACKUP_URL=http://iplocal:9000 # En caso de estar por proxy inverso poner la dirección https://tuportainer.com
            - PORTAINER_BACKUP_TOKEN=xxxxxxxxxxxxx  # El token que hemos generado explicado en el video
            - PORTAINER_BACKUP_OVERWRITE=true
            - PORTAINER_BACKUP_SCHEDULE=0  0  */2  *  *  * # La hora a la que quieres que se ejecute el backup, en este caso cada dos horas
            - TZ=Europe/Madrid # Tu zona horaria
        image: savagesoftware/portainer-backup:latest
        command:
            - schedule

Para sacar el PORTAINER ACCESS TOKEN que necesitamos, en nuestro portainer, nos vamos al icono de nuestro usuario arriba a la derecha y pulsamos en el icono.

Se nos abrirá un menú y pulsamos en MY ACCOUNT y nos vamos al apartado ACCESS TOKEN y creamos un nuevo token

Lo copiamos y lo pegamos en nuestro docker-compose

La hora se hace mediante la programación en el archivo con interno. Podéis ver varios ejemplos de configuración horaria mediante cron en este enlace https://crontab.guru/examples.html

5.-Hacer la copia programada de la configuración del NAS

Sólo nos falta sacar un archivo que nos guarde una configuración de nuestro sistema.

En ADM tenemos que irnos a COPIA DE SEGURIDAD Y RESTAURACIÓN como antes y esta vez nos iremos al último apartado que se llama CONFIGURACIÓN DEL SISTEMA

Vamos a elegir EXPORTACION PROGRAMADA y lo configuramos de tal forma que haga una copia diaria de la configuración, en el disco USB donde haremos todo el proceso de copia de datos, de forma diaria a las 4:55 de la mañana.

Y con todo esto nos debería quedar un sistema similar a Hyperbackup en Synology, ¿nos funcionará? Lo vemos en el siguiente video

Mi nombre es David Rodríguez, apasionado por un millón de cosas que lleven placas y chips dentro. Puedes encontrarme como @_Bilito en twitter y en grupo de Telegram de Synology NAS https://t.me/synologyNAS Tengo un canal de youtube que complementa al blog https://www.youtube.com/@_Bilito y que me harías un gran favor si te subscribes. También colaboro en podcast como Bateria 2x100 https://pod.link/1115144939 y además hemos comenzado otra aventura en otro podcast Detras del Mostrador https://pod.link/1657695301