He propuesto una arquitectura llamada “limpia” para el nuevo servicio. Pero “limpio” no siempre significa “simple”.up/backup-config
restic --cache-dir=/var/restic
backup
/etc
/root
/var/discourse
/opt/backup
–exclude /var/discourse/shared/data/postgres_data
restic --cache-dir=/var/restic forget
–prune --keep-hourly 24 --keep-daily 7 --keep-monthly 3
EOF
chmod +x backup
Estos detalles variarán según el destino de restic. No todos utilizan variables de entorno de AWS, así que lee la documentación de restic.
```shell
# cat > backup-config <<EOF
### Estos detalles dependen del destino de restic que configures, así que cámbialos
export AWS_ACCESS_KEY_ID=tu-clave-aquí
export AWS_SECRET_ACCESS_KEY=igual
export RESTIC_PASSWORD_FILE=/root/restic-password
export RESTIC_REPOSITORY=consulta-la-documentación-de-restic
EOF
# {$EDITOR:-nano} /root/restic-password
Necesitarás guardar una copia de lo que pongas en /root/restic-password, ¡o no podrás leer las copias de seguridad! Usa tu bóveda de contraseñas.
Por último, crea algunos servicios, inicializa el repositorio de restic y establece un temporizador para que comiencen las copias de seguridad.
# cat > /etc/systemd/system/backup.service <<EOF
[Unit]
Description=Realizar copia de seguridad en destino remoto
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
StandardOutput=file:/var/log/backup.out
StandardError=file:/var/log/backup.err
WorkingDirectory=/var/discourse
ExecStart=/opt/backup/backup
[Install]
WantedBy=multi-user.target
EOF
# cat > /etc/systemd/system/backup.timer <<EOF
[Unit]
Description=Copias de seguridad del sistema periódicas
[Timer]
Persistent=true
OnCalendar=00/4:30:00
Unit=backup.service
[Install]
WantedBy=timers.target
EOF
# systemctl daemon-reload
# . /opt/backup/backup-config
# restic init
# /opt/backup/backup
# systemctl enable backup.timer
Después de este proceso, deberías poder ver que has creado tu copia de seguridad inicial.
# restic snapshots
He utilizado con éxito copias de seguridad de restic realizadas de esta manera para mover un servidor Discourse de un sistema a otro utilizando el comando restic restore.
Copias de seguridad de imágenes minio en streaming
Como alternativa a Restic, mientras que las copias de seguridad de la base de datos se pueden almacenar en S3, no hay una copia de seguridad de imágenes S3 separada de la entrega de imágenes desde S3. Una alternativa es usar minio-client para copiar imágenes a cualquier almacenamiento similar a S3. Esto puede ser muchos destinos similares a S3, incluyendo S3 y minio, pero no DigitalOcean Spaces porque está construido sobre el sistema de archivos Ceph, que no implementa la API ListObjectsV2 de la misma manera que S3.
En S3, crea un bucket que bloquee el acceso público (Permisos → Bloquear acceso público es la forma fácil de hacerlo correctamente en AWS).
Instala minio-client (mc) de alguna manera. Aquí hay una forma.
curl https://dl.min.io/client/mc/release/linux-amd64/mc > /usr/local/bin/mc && chmod +x /usr/local/bin/mc
Configura minio-client con un alias llamado backup usando un comando como este:
# mc alias set backup https://s3.amazonaws.com ACCESSKEY SECRETKEY --api S3v4
# mc mirror /var/discourse/shared/standalone/uploads backup/UPLOADS-BACKUP-BUCKET
Luego crea un servicio /etc/systemd/system/backup-uploads.service como este
[Unit]
Description=Sincronización de copia de seguridad remota casi en tiempo real de cargas de Discourse
After=network.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=600
User=root
ExecStart=/usr/local/bin/mc mirror --overwrite -a --watch /var/discourse/shared/app/uploads backup/UPLOADS-BACKUP-BUCKET
[Install]
WantedBy=multi-user.target
Ten en cuenta que UPLOADS-BACKUP-BUCKET aquí debe ser un bucket diferente al s3_backup_bucket en el que configuras Discourse para cargar copias de seguridad de la base de datos. Además, ten en cuenta que la ruta será /var/discourse/shared/web_only/uploads si usas el despliegue estándar de múltiples contenedores.
# systemctl enable backup-uploads
# systemctl start backup-uploads
# journalctl -fu backup-uploads
Sube una imagen de prueba y asegúrate de ver líneas para la copia de seguridad exitosa de las imágenes originales y optimizadas. Control-C saldrá del modo de seguimiento en journalctl.
Recuperación
Hasta la fecha, nunca he tenido que probar este plan. Este resumen podría omitir algo.
- Restaurar todos los archivos respaldados en general
- Iniciar nginx (ahora se mostrará tu página de mantenimiento)
- Realizar un despliegue normal de Discourse usando los archivos restaurados en /var/discourse/containers
- Instalar minio-client en /usr/local/bin/mc si no lo restauraste desde las copias de seguridad
- Si no respaldaste
/root/mc, configura el alias de copia de seguridad# mc alias set backup https://s3.amazonaws.com ACCESSKEY SECRETKEY --api S3v4 # mc cp backup/UPLOADS-BACKUP-BUCKET /var/discourse/shared/app/uploads- Restaurar la copia de seguridad de la base de datos más reciente; recomiendo que consultes Restore a backup from the command line
- Solo después de confirmar que el sitio está operativo, reconfigura la copia de seguridad de las cargas en S3 como se documenta arriba.
Copias de seguridad de postgresql en streaming
En el futuro, puedo crear, probar y proporcionar una configuración para habilitar el uso de archivado WAL continuo para transmitir copias de seguridad de Postgres casi instantáneas con minio-client usando el archive-command en postgresql, similar a las copias de seguridad de cargas en streaming.
Monitoreo de rendimiento
Hay al menos dos enfoques para el monitoreo de rendimiento.
Contenedor Prometheus
Configura prometheus, poniendo los registros de prometheus en /var/discourse/shared/prometheus si lo ejecutas en el mismo sistema. Los archivos de Prometheus pueden crecer mucho, y no quieres que llenen el sistema de archivos raíz; también probablemente quieras llevarlos contigo si te mudas a un sistema de host más nuevo (ya sea actualizando a una VM más grande o a una VM con una instalación de sistema operativo más nueva).
Si despliegas prometheus en el sistema de Discourse (o en cualquier otro lugar en internet público), configura la seguridad delante de él. Instalado de esa manera, una opción sería la configuración de nginx como esta:
location /prometheus/ {
auth_basic "Prometheus";
auth_basic_user_file /etc/nginx/prometheus-htpasswd;
proxy_pass http://localhost:9090/;
}
Sysstat
Si Prometheus es demasiado, considera usar sysstat en su lugar.
dnf install sysstat(oapt install sysstaten debian y derivados)systemctl enable --now sysstatsystemctl enable --now sysstat-collect.timersystemctl enable --now sysstat-summary.timersystemctl edit sysstat-collect.timery cambiaOnCalendar=*:00/10aOnCalendar=*:00/2- Si existe /etc/default/sysstat, cambia
falseatrue
Después de esto, el comando sar puede decirte si te estás quedando sin recursos de vez en cuando.
Otros Recursos
Aquí hay una discusión complementaria (y más compacta) sobre el uso de Discourse internamente como forma principal de comunicación interna.
Realicé el cambio de configuración antes de agregar Prometheus (que usa más memoria), así que antes de modificar eso, probablemente moveré Prometheus fuera de esa instancia del servidor.
