Hola, estoy buscando una manera de realizar copias de seguridad automatizadas de mi nuevo foro Discourse (configurado en un droplet de Digital Ocean) hacia el dispositivo NAS de mi red doméstica. ¿Cómo se puede lograr esto?
No soy programador y no sabría por dónde empezar para crear un plugin con este propósito.
La forma más sencilla es ejecutar algún tipo de tarea automatizada (tarea cron). Dependiendo del NAS que tengas, puedes ejecutar comandos básicos de Linux, como rsync.
Necesitas una forma de conectar el NAS y el Droplet. Una vez que encuentres esa forma, creo que usar un plugin sería excesivo, por ejemplo. Solo necesitas algo como el código de abajo, para ejecutarlo en tu NAS dentro de una tarea cron
rsync -avz --progress -e "ssh -i ~/.ssh/id-rsa" example.com:/var/discourse/shared/standalone/backups /folder/in/the/nas
La capacidad de ejecutar algo así dependerá, como mencioné anteriormente, del tipo de NAS que tengas.
Gracias, Mario. Tengo un antiguo Netgear ReadyNAS Ultra 6 ejecutando OS6, que creo que podría soportar este enfoque (lo investigaré).
Supongo que parte del problema para mí es identificar qué archivos o carpetas respaldar; ¿presumo que solo la base de datos? (¿y presumo que todas las imágenes adjuntas, etc., estarán incrustadas en ella?)
¿Qué ruta usaría para encontrar la base de datos? ¿Acaso la base de datos se almacena como un archivo dentro del directorio de Discourse? He echado un vistazo en /var/discourse y no he visto nada que pareciera un archivo de base de datos, al menos para mi ojo inexperto.
Deseas activar las copias de seguridad diarias y obtener
/var/discourse/shared/standalone/backups/default
Gracias, Jay: parece que esa es la solución.
¿Es razonable asumir que, si he activado la opción ‘incluir archivos adjuntos con las copias de seguridad’, no hay nada más que necesite respaldar, en caso de que en algún momento deba empezar de cero en otro servidor?
(asegurando que los plugins de terceros que he estado utilizando no dejarán de estar disponibles para su descarga de repente)
Además, ¿hay alguna forma de limpiar automáticamente el directorio de copias de seguridad diarias para que, por ejemplo, no se conserven más de los últimos 7 días de copias de seguridad diarias en el servidor?
Sí, hay configuraciones en el Panel de Administración; no recuerdo los nombres en este momento. El script que te envié anteriormente ya utiliza la ruta predeterminada donde se almacenan las copias de seguridad.
Pero, con rsync en el NAS y ese comando, puedes configurarlo para que también elimine las copias de seguridad antiguas del NAS. Ya tienes todo listo.
Gracias, Mariano.
En el foro de ReadyNAS hubo una sugerencia de que usar chron en ReadyNAS es posible, pero no ideal, y que los ‘timers de systemd’ integrados son mejores. No estoy seguro de si eso permite algo tan sofisticado como limpiezas de directorios remotos.
Actualmente estoy luchando con errores de ‘Permiso denegado (publickey)’ cada vez que intento conectarme desde ReadyNAS a mi servidor Discourse, aunque he añadido la clave pública de ReadyNAS a la lista de usuarios SSH en Digital Ocean.
Informaré por aquí si logro algún avance, para cualquiera que esté intentando esto.
La limpieza la realiza directamente Discourse en el droplet, pero rsync tiene un montón de opciones, por lo que puedes personalizar el proceso de copia de las copias de seguridad a tu gusto.
Asegúrate de reiniciar el servidor SSH; a veces, esto soluciona algunos problemas de claves públicas.
Gracias, Mariano.
Acabo de reiniciar el servidor y sigo obteniendo:
Permiso denegado (publickey).
rsync: conexión cerrada inesperadamente (0 bytes recibidos hasta ahora) [Receiver]
rsync error: error inexplicable (código 255) en io.c(235) [Receiver=3.1.3]
Sin duda, el problema es mío, tratando de iniciar sesión con el usuario incorrecto o algo así; aunque he intentado iniciar sesión desde ReadyNAS usando el nombre que le di a esa clave pública al agregarla a Digital Ocean, así como ‘root’. Ninguno de los dos parece funcionar.
¿Ya has iniciado sesión en el servidor con una clave? Por ejemplo, cuando instalaste Discourse o reconstruiste la aplicación.
Es posible (aunque no debería serlo) que la autenticación pública en el servidor SSH esté deshabilitada, o quizás el NAS esté usando la clave incorrecta para iniciar sesión.
Recuerda cambiar al nombre y la ruta de la clave correcta en esta parte del comando: "ssh -i ~/.ssh/id-rsa"
*** EDICIÓN ***
Gracias, Mariano. Al final lo logré.
En resumen, para cualquier otra persona que esté intentando esto:
Habilita SSH en ReadyNAS ReadyNAS OS 6: SSH access support and configuration guides - NETGEAR Support
Usa PuTTY para acceder al servidor de Digital Ocean y escribe:
nano /root/.ssh/authorized_keys
En el editor, copia y pega el texto de la clave pública utilizada por ReadyNAS, agregándolo al final del archivo /root/.ssh/authorized_keys (ten cuidado de no sobrescribir ninguna clave que ya esté presente).
En la configuración del diálogo de respaldo de ReadyNAS, utilicé:
Nombre: Respaldar vía Rsync sobre SSH remoto (selección en menú desplegable)
Host: miDominio.com (o la dirección IP del servidor)
Puerto: 22
Ruta: /var/discourse/shared/standalone/backups/default
Usuario: root
(Ten en cuenta que si seguiste correctamente las instrucciones para configurar ReadyNAS para el acceso SSH, no se asociará ninguna frase de contraseña a su par de claves pública/privada SSH. Esto es bastante importante, ya que el diálogo de respaldo de ReadyNAS no permite ingresar una frase de contraseña).
Al principio, este proceso no funcionó completamente para mí: usar el botón ‘Probar’ en el diálogo de respaldo de ReadyNAS con esta configuración sí resultó en una conexión exitosa, pero al iniciar un respaldo se generó el error ‘Cuota de disco excedida (122)’.
Pero luego, un par de horas después, sin ninguna intervención obvia adicional por mi parte, cuando el proceso de respaldo se inició nuevamente en su hora designada automáticamente, esta vez simplemente funcionó como debería.
Posiblemente mis esfuerzos anteriores para lograr una conexión y probar con diferentes configuraciones tuvieran algún efecto residual que impedía el proceso, o quizás el hecho de estar simultáneamente conectado al servidor desde mi PC como root mediante PuTTY al mismo tiempo que como root mediante FileZilla (ambos usando la clave predeterminada para root) y luego intentar iniciar sesión como root desde la utilidad de respaldo del dispositivo ReadyNAS (usando la clave pública de ReadyNAS que se había agregado a root) fue problemático.