Configuración de BorgBackup en un VPS

Configuración

La configuración de BorgBackup se reduce principalmente a la creación de scripts para la creación y el mantenimiento de copias de seguridad. Es importante definir correctamente qué respaldar, dónde y cómo gestionar las claves de cifrado. Utilizaremos variables de entorno para almacenar datos sensibles, como la contraseña del repositorio.

1. Configuración de variables de entorno para la contraseña de Borg

Para no tener que introducir la contraseña cada vez que se ejecuta el script, Borg puede tomarla de la variable de entorno BORG_PASSPHRASE. Esto es conveniente para la automatización, pero requiere precaución en su almacenamiento.

# En el servidor cliente
# Creamos un archivo para almacenar variables de entorno
sudo nano /etc/profile.d/borg_env.sh

Pegue el siguiente contenido, reemplazando SU_CONTRASEÑA_DEL_REPOSITORIO con su contraseña real:

#!/bin/bash
export BORG_PASSPHRASE="SU_CONTRASEÑA_DEL_REPOSITORIO"
export BORG_REPO="ssh://borguser@su_ip_o_dominio_del_repositorio:22/home/borguser/backups/my_server_repo"
export BORG_CACHE_DIR="/var/cache/borg" # Directorio para la caché de Borg

Guarde el archivo y hágalo ejecutable:

sudo chmod 600 /etc/profile.d/borg_env.sh # Establecer permisos de acceso
sudo chown root:root /etc/profile.d/borg_env.sh # Establecer propietario
# Para que las variables estén disponibles en la sesión actual (para verificación)
source /etc/profile.d/borg_env.sh

Importante: Asegúrese de que los permisos de acceso a este archivo estén restringidos para que solo root pueda leerlo. Para las tareas cron, las variables de entorno se cargarán automáticamente si el script se ejecuta con los permisos adecuados.

2. Creación de un script para copias de seguridad

Crearemos el script principal que realizará la copia de seguridad. Este script incluirá la creación del archivo, su verificación y la limpieza de copias de seguridad antiguas.

# En el servidor cliente
sudo mkdir -p /opt/backup_scripts # Creación de directorio para scripts
sudo nano /opt/backup_scripts/create_backup.sh

Contenido del script:

#!/bin/bash

# Carga de variables de entorno
source /etc/profile.d/borg_env.sh

# Directorios para la copia de seguridad
BACKUP_DIRS="/etc /var/www /home /var/lib/mysql_dumps" # Ejemplo: /var/lib/mysql_dumps debe crearse previamente con volcados de BD

# Nombre del archivo (con marca de tiempo)
ARCHIVE_NAME="{hostname}-$(date +%Y-%m-%d_%H-%M-%S)"

echo "--- Iniciando copia de seguridad en ${BORG_REPO}::${ARCHIVE_NAME} ---"

# Creación de la copia de seguridad
borg create --stats --progress \
    --compression zstd,5 \
    --exclude '/home//.cache' \
    --exclude '/var/cache/' \
    --exclude '/var/tmp/' \
    --exclude '/var/log/' \
    --exclude '/var/lib/mysql/.sock' \
    --exclude '/var/lib/mysql/mysql.sock' \
    --exclude '.log' \
    "${BORG_REPO}::${ARCHIVE_NAME}" ${BACKUP_DIRS} \
    2>&1 | tee /var/log/borg_backup.log # Redirección de la salida al archivo de registro

EXIT_STATUS=$?

if [ ${EXIT_STATUS} -eq 0 ]; then
    echo "--- Copia de seguridad completada con éxito ---"
elif [ ${EXIT_STATUS} -eq 1 ]; then
    echo "--- Copia de seguridad completada con advertencias (ver registro) ---"
else
    echo "--- Copia de seguridad completada con error (código ${EXIT_STATUS}, ver registro) ---"
fi

echo "--- Iniciando verificación del repositorio ---"
borg check --last 1 "${BORG_REPO}" # Verificación del último archivo

echo "--- Iniciando limpieza de copias de seguridad antiguas ---"
# Política de retención:
# 7 últimas copias de seguridad diarias
# 4 últimas copias de seguridad semanales
# 6 últimas copias de seguridad mensuales
borg prune --list --stats --show-rc \
    --keep-daily 7 --keep-weekly 4 --keep-monthly 6 "${BORG_REPO}" \
    2>&1 | tee -a /var/log/borg_backup.log # Añadir salida al mismo archivo de registro

PRUNE_EXIT_STATUS=$?

if [ ${PRUNE_EXIT_STATUS} -eq 0 ]; then
    echo "--- Limpieza completada con éxito ---"
else
    echo "--- Limpieza completada con error (código ${PRUNE_EXIT_STATUS}, ver registro) ---"
fi

echo "--- Mostrando lista de archivos ---"
borg list "${BORG_REPO}"

echo "--- Script de copia de seguridad finalizado ---"

Haga el script ejecutable:

sudo chmod +x /opt/backup_scripts/create_backup.sh # Hacer el script ejecutable

Explicaciones del script:

• source /etc/profile.d/borg_env.sh: Carga las variables BORG_PASSPHRASE y BORG_REPO.
• BACKUP_DIRS: Define qué directorios se respaldarán. Es importante que los volcados de bases de datos (por ejemplo, /var/lib/mysql_dumps) se hayan creado previamente.
• --compression zstd,5: Utiliza el algoritmo de compresión Zstandard con nivel 5 (un buen equilibrio entre velocidad y grado de compresión).
• --exclude: Excluye archivos temporales, cachés y registros que no son necesarios en las copias de seguridad.
• borg check: Verifica la integridad del repositorio. Este es un paso crítico para asegurar la capacidad de recuperación.
• borg prune: Elimina archivos antiguos según la política definida (7 diarios, 4 semanales, 6 mensuales). Esto ayuda a ahorrar espacio y mantener el orden.

3. Volcados de bases de datos (MySQL/PostgreSQL)

Antes de ejecutar BorgBackup, si utiliza bases de datos, es necesario crear sus volcados. Por ejemplo, para MySQL:

# En el servidor cliente
sudo mkdir -p /var/lib/mysql_dumps # Creación de directorio para volcados
sudo chown mysql:mysql /var/lib/mysql_dumps # Establecer propietario (o su usuario, si el volcado se hará desde él)
# Creación de volcado de todas las bases de datos
sudo mysqldump --all-databases --single-transaction --flush-logs --master-data \
    -u root -p'SU_CONTRASEÑA_MYSQL' > /var/lib/mysql_dumps/all_databases_$(date +%Y%m%d%H%M%S).sql # Volcado de todas las BD
# O para una base de datos específica
# sudo mysqldump -u root -p'SU_CONTRASEÑA_MYSQL' YOUR_DATABASE > /var/lib/mysql_dumps/your_database_$(date +%Y%m%d%H%M%S).sql

Este paso debe añadirse a su script create_backup.sh antes del comando borg create, para que Borg respalde los volcados ya preparados. O cree un script separado para el volcado que se ejecutará antes de la copia de seguridad principal.

4. Verificación de la funcionalidad

Ejecute el script manualmente para asegurarse de que todo funciona:

sudo /opt/backup_scripts/create_backup.sh # Ejecución del script

Verifique la salida en la consola y el archivo de registro /var/log/borg_backup.log en busca de errores. Después de una ejecución exitosa, puede verificar la lista de archivos en el repositorio:

borg list "${BORG_REPO}" # Verificación de la lista de archivos

Debería ver el nombre del archivo que generó.

Copias de seguridad y mantenimiento

Una vez que BorgBackup está configurado y probado, es necesario automatizar el proceso y definir una estrategia de mantenimiento.

1. Qué respaldar

La elección de los datos a respaldar depende de su servicio, pero generalmente incluye:

• Archivos de configuración: /etc/ (especialmente /etc/nginx/, /etc/apache2/, /etc/php/, /etc/mysql/, /etc/ssh/, /etc/fail2ban/ etc.).
• Datos de servidores web: /var/www/ o /opt/www/ (archivos de sitios web, estáticos, medios).
• Directorios de inicio de usuarios: /home/ (si los usuarios almacenan datos importantes allí).
• Bases de datos: Volcados de bases de datos (MySQL, PostgreSQL, MongoDB, etc.), que deben crearse antes de ejecutar Borg. Por ejemplo, en /var/lib/mysql_dumps/.
• Aplicaciones: Si instaló algo fuera del gestor de paquetes (por ejemplo, en /opt/), inclúyalo.

Qué no respaldar: Archivos temporales (/tmp, /var/tmp), cachés (/var/cache), registros (/var/log), archivos del sistema operativo (excepto /etc), que son fáciles de restaurar reinstalando paquetes.

2. Automatización de copias de seguridad con cron

Para la ejecución regular del script de copia de seguridad, use cron.

# En el servidor cliente
sudo crontab -e # Apertura del archivo crontab para root (o sudo crontab -e -u sysadmin para el usuario sysadmin)

Agregue la siguiente línea para una copia de seguridad diaria a las 03:00 de la madrugada:

0 3    /opt/backup_scripts/create_backup.sh > /dev/null 2>&1 # Copia de seguridad diaria a las 03:00

# En crontab -e
BORG_PASSPHRASE="SU_CONTRASEÑA_DEL_REPOSITORIO"
BORG_REPO="ssh://borguser@su_ip_o_dominio_del_repositorio:22/home/borguser/backups/my_server_repo"
BORG_CACHE_DIR="/var/cache/borg"

0 3    /opt/backup_scripts/create_backup.sh > /dev/null 2>&1

3. Dónde almacenar las copias de seguridad (S3 externo / VPS separado)

En nuestro caso, las copias de seguridad se almacenan en un VPS separado que actúa como repositorio Borg. Esto ya es mucho mejor que almacenar las copias de seguridad en el mismo servidor que los datos originales.

Para máxima fiabilidad, se puede considerar:

• Almacenamiento de objetos compatible con S3 externo: BorgBackup no es compatible directamente con S3, pero puede usar rclone para sincronizar el repositorio Borg con un almacenamiento compatible con S3 después de crear las copias de seguridad. Esto añade otro nivel de redundancia y distribución geográfica.
• Segundo VPS remoto: Crear un segundo repositorio Borg en otro VPS (posiblemente en otro centro de datos o región) y enviar las copias de seguridad allí también.

Recuerde la regla 3-2-1: 3 copias de datos, en 2 medios diferentes, 1 de las cuales está fuera de la oficina/sitio.

4. Recuperación de datos

La recuperación de datos es el aspecto más importante de cualquier sistema de copia de seguridad. BorgBackup lo hace relativamente sencillo.

Lista de archivos:

borg list "${BORG_REPO}" # Mostrar todos los archivos en el repositorio

Ver contenido del archivo:

borg list "${BORG_REPO}::ARCHIVE_NAME" # Mostrar el contenido de un archivo específico (reemplace ARCHIVE_NAME)

Restaurar archivo completo:

borg extract "${BORG_REPO}::ARCHIVE_NAME" --paths /path/to/restore/to # Restaurar todo el archivo en el directorio especificado

Restaurar archivos/directorios específicos:

borg extract "${BORG_REPO}::ARCHIVE_NAME" path/to/file_or_dir --paths /path/to/restore/to # Restaurar un archivo o directorio específico

Siempre restaure los datos en un directorio nuevo o temporal para evitar sobrescribir archivos existentes y asegurarse de la correcta recuperación.

5. Actualizaciones: rolling vs. ventana de mantenimiento

La actualización de BorgBackup y del sistema operativo debe realizarse regularmente.

• Actualizaciones continuas (rolling updates): Para componentes no críticos y parches menores del SO, las actualizaciones se pueden aplicar regularmente, sin detener los servicios.
• Ventana de mantenimiento: Para actualizaciones importantes de BorgBackup o del SO, así como para la actualización del kernel, se recomienda planificar una "ventana de mantenimiento". Este es un período en el que puede detener los servicios, tomar una instantánea del VPS (si su proveedor lo permite), realizar la actualización y probar el sistema a fondo.

Siempre verifique la compatibilidad de las versiones de BorgBackup al actualizar. Aunque Borg suele ser muy estable, las versiones principales pueden incluir cambios que requieren atención.

sudo apt update && sudo apt upgrade -y # Actualización regular del sistema

Después de actualizar el SO y BorgBackup, siempre verifique la funcionalidad del script de copia de seguridad y la capacidad de recuperar datos.

Solución de problemas + Preguntas frecuentes

¿Qué hacer si BorgBackup muestra el error "Remote: Host key verification failed"?

Este error significa que el cliente SSH no puede verificar la autenticidad del servidor remoto. Con mayor frecuencia, esto ocurre al conectarse por primera vez a un nuevo servidor si no ha confirmado la huella digital de la clave, o si la dirección IP del servidor ha cambiado y la clave antigua permanece en ~/.ssh/known_hosts. Para resolver el problema, elimine la línea correspondiente del archivo ~/.ssh/known_hosts en el servidor cliente (o de /root/.ssh/known_hosts si el script se ejecuta como root) e intente conectarse de nuevo, confirmando la nueva huella digital.

¿Cómo resolver el problema de falta de espacio en el disco del repositorio?

Si el servidor del repositorio se queda sin espacio, lo primero es verificar cómo funciona el comando borg prune. Es posible que la política de retención sea demasiado liberal y esté almacenando demasiados archivos antiguos. Reduzca la cantidad de copias de seguridad diarias, semanales o mensuales que se guardan. También verifique si hay otros archivos grandes en el disco que no estén relacionados con Borg. Si el problema persiste, quizás sea hora de aumentar el tamaño del disco en el VPS del repositorio o considerar la transición a un servidor dedicado con mayor almacenamiento.

¿Qué configuración mínima de VPS es adecuada para un repositorio BorgBackup?

Para un proyecto pequeño con un volumen de datos de hasta 100-200 GB y uno o dos clientes, un VPS con 1 vCPU, 2 GB de RAM y 200 GB de disco SSD/NVMe será mínimamente adecuado. Es importante que el disco sea lo suficientemente rápido para las operaciones de Borg (SSD/NVMe es preferible). Si la cantidad de datos o clientes crece, se deben escalar los recursos, especialmente la RAM y el espacio en disco.

¿Qué elegir — VPS o dedicado para esta tarea?

La elección entre un VPS y un servidor dedicado depende de la escala de sus necesidades. Un VPS es ideal para la mayoría de los proyectos pequeños y medianos, ofreciendo flexibilidad y rentabilidad. Es adecuado si realiza copias de seguridad de varios cientos de gigabytes de datos con una frecuencia moderada. Un servidor dedicado es necesario si el volumen de datos se mide en terabytes, se requiere el máximo rendimiento del subsistema de disco, o si actúa como proveedor de copias de seguridad para muchos clientes. Un servidor dedicado garantiza recursos y la ausencia total de "vecinos", lo cual es crítico para el rendimiento bajo alta carga.

¿Qué hacer si olvidó la contraseña del repositorio Borg?

Si olvidó la contraseña del repositorio Borg, lamentablemente será imposible recuperar los datos de él. El cifrado de Borg es muy robusto y sin la contraseña el acceso a los datos es imposible. Esto subraya la importancia crítica de almacenar la contraseña de forma segura. Siempre use un gestor de contraseñas u otro almacenamiento seguro para datos tan críticos.

¿Cómo verificar la integridad de las copias de seguridad?

La verificación regular de la integridad de las copias de seguridad es una parte obligatoria del mantenimiento. Para ello se utiliza el comando borg check. Puede agregarlo a su script de copia de seguridad, como lo hicimos nosotros, o ejecutarlo por separado. El comando borg check --repository-only verifica solo el repositorio, mientras que borg check --archives-only verifica los archivos. Una verificación completa con borg check puede llevar mucho tiempo para repositorios grandes, pero garantiza que los datos no estén dañados.

¿Se pueden respaldar varios servidores en un solo repositorio?

Sí, BorgBackup es excelente para respaldar múltiples servidores en un único repositorio central. Para cada servidor cliente, basta con crear su propio conjunto de claves SSH y configurarlas en el authorized_keys del usuario borguser en el servidor del repositorio, utilizando la opción command="borg serve --restrict-to-path /home/borguser/backups/SERVER_NAME" para aislar a cada cliente en su propio subdirectorio del repositorio. Esto aumenta la seguridad y permite gestionar fácilmente las copias de seguridad de diferentes fuentes.

Conclusiones y próximos pasos

Hemos configurado BorgBackup con éxito en su VPS para crear copias de seguridad cifradas y deduplicadas. Ahora sus datos críticos están protegidos contra pérdidas, y el proceso de copia de seguridad está completamente automatizado. Usted tiene control total sobre sus datos, su seguridad y el costo de almacenamiento.

Los siguientes pasos para mejorar aún más su sistema de copia de seguridad pueden incluir:

• Configuración de monitoreo: Integre los registros de BorgBackup con un sistema de monitoreo (por ejemplo, Prometheus, Grafana, pila ELK) para rastrear el éxito de las copias de seguridad y las advertencias de errores.
• Redundancia adicional: Considere la posibilidad de crear copias de su repositorio Borg en otro almacenamiento remoto (por ejemplo, compatible con S3 o un segundo VPS) para implementar la regla 3-2-1.
• Pruebas de recuperación regulares: Pruebe periódicamente el proceso de recuperación de datos para asegurarse de que las copias de seguridad estén actualizadas y sean funcionales. Esto le dará confianza en una situación crítica.