I have a backup server that coordinates backups across many servers. I want my backup server to grab Discourse backups from my forum’s server.
I gave some thought to how I’d allow the backup server to access the backup files on the forum’s server. The best way I could come up with is allowing remote access as the www-data user (who owns Discourse’s backups).
I didn’t want to allow the backup server to shell into the forum’s server as root (for standard sysadmin reasons). I also wanted to avoid doing anything that I thought could cause Discourse to choke during backups or restores. I also wanted to avoid hosting another service on forum server.
Anyways, here’s how I did it.
Allow remote access as the www-data user
Edit /etc/passwd and replace www-data’s shell with /bin/bash rather than /usr/sbin/nologin.
Edit /etc/passwd again and replace www-data’s home directory with /home/www-data rather than /var/www (optional, but appealing to me).
Add the backup server’s SSH key to /home/www-data/.ssh/authorized_keys.
rsync
Finally, on the backup server, I added an hourly cron command that ran the following script:
#!/usr/bin/env bash
set -xe
HOST="$1"
DIR="$2"
if [ -z "$HOST" ] || [ ! -d "$DIR" ]; then
echo "$0 HOST DIR"
exit 1
fi
# --ignore-existing will have rsync ignore any backups that have already been
# copied.
# --delay-updates ensures that only complete backups ever make it into $DIR. If
# this isn't specified, partial backups could end up in $DIR, and because
# --ignore-existing won't perform any kind of equality check, the problem will
# not be corrected or detected.
rsync --ignore-existing --delay-updates "$HOST:/var/discourse/shared/standalone/backups/default/*" "$DIR"
Hopefully this proves useful to someone out there.
¡¡Guau!!
Aunque agradecería mucho más si explicara los pasos que se indican a continuación con un poco más de detalle para que los usuarios novatos como yo no pudieran hacer nada mal (y también tuvieran una idea de lo que hace cada paso).
Permite que el usuario www-data inicie sesión correctamente. Esto cambia el “shell de inicio de sesión”, que es una buena palabra clave para buscar y aprender más.
Sí. Las claves privadas (básicamente) nunca deben copiarse/compartirse en ningún lugar fuera de su máquina host.
Dado que eres un buscador un poco nuevo, ¿podría haber una forma sencilla de transferir nuestras copias de seguridad del servidor local a diferentes buckets S3, como Google S3, iDrive S3, a través de trabajos cron?
(Sé que podemos configurarlo directamente para el bucket S3 de AWS usando su clave y secreto).
Si configura copias de seguridad de S3, se cargan automáticamente en S3, aunque tienen todas las cargas o ninguna, por lo que a menos que tenga cargas en S3, tiene varias copias de todas las cargas en los archivos de copia de seguridad.
Eso ya lo sé y hasta ahora, desde que empecé hace 6 años, he estado usando esta misma configuración (de subir todos los medios y copias de seguridad a un bucket de AWS).
Pero estaba preguntando lo anterior por un problema de tipo diferente al que me enfrento.
Ahora, he configurado para crear copias de seguridad (que incluyen medios ‘Cargas’) en un servidor local de Ubuntu. Pero (como se discute en otro hilo), no puedo restaurar desde esas copias de seguridad (de 1 GB). Algo falta/está dando problemas. Así que estaba pensando en usar un bucket de Google y deshacerme de AWS por completo.
No veo la diferencia entre AWS S3 y los de Google. ¿Pero tal vez https://restic.net/ te ayude? Es un programa de copias de seguridad que puede hacer copias de seguridad en cubos s3.
No estoy seguro de cuál es tu problema de restauración.
Para cualquiera que llegue a este hilo como yo, me gustaría explicar un poco más esta primera publicación del tema.
Este es un script de bash, que se puede pegar ‘tal cual’ en un archivo con cualquier nombre, pero que tenga la extensión .sh
La primera línea del script simplemente establece el entorno para que se ejecute el script, en cuanto a qué shell o entorno se debe usar: #!/usr/bin/env bash: Esto le dice al sistema que use el intérprete bash encontrado a través del comando env.
Indicadores (set -xe):
-x: Habilita la depuración, lo que significa que cada comando y sus argumentos se imprimirán en la terminal antes de ejecutarse. Esto es útil para depurar el script.
-e: Hace que el script salga inmediatamente si algún comando devuelve un estado distinto de cero (lo que indica un error). Esto es útil para evitar que el script continúe después de un fallo.
Y en el siguiente paso importante, Variables (HOST="$1" DIR="$2"):
HOST="$1": Asigna el primer argumento pasado al script ($1) a la variable HOST. Es decir, cuando se ejecute este script, exigirá alguna entrada del usuario, y cualquier primera entrada ($1) que ingrese el usuario, se pasará/considerará como el valor ‘Host’ (desde donde quizás se copiarán los datos).
DIR="$2": Asigna el segundo argumento pasado al script ($2) a la variable DIR. Es decir, cualquier (ruta de directorio) que el usuario ingrese después de ingresar el primer valor, (llamado ‘$2’) será tomado por el script como ‘Dir- directorio de destino’.
Si alguien está interesado, también puedo explicar los 2 pasos restantes, pero basta decir que el siguiente paso simplemente verifica que el usuario proporcione los valores correctos de host y directorio de destino cuando se le solicite. De lo contrario (el último paso) devolvería 1 como salida de error.
Lo principal que reiteraría es que este es un script que, cuando se ejecuta, le pedirá al usuario el host (desde dónde se copiarán los datos) y el directorio de destino (dónde se pegarán los datos). Y usted incluiría la ruta a este archivo en su archivo de cron, que podría ejecutar este archivo de script tantas veces al día como lo configure en el archivo de cron.
Pero lo que no he logrado entender es ¿dónde están los comandos reales de copiar y pegar (o de copia de seguridad)? ¿Cómo ocurrirá la sincronización real?