¿No es 1 copia de seguridad al día demasiado arriesgado? Si algo le sucede al servidor y la última copia de seguridad se realizó ayer, ¿qué hago? Los usuarios registrados entre ayer y hoy, ¿ya no están registrados? Creo que es mejor hacer copias de seguridad con más frecuencia, quizás cada hora. Pero en caso de que, ¿tienes que poner el sitio en modo de solo lectura antes de hacer una copia de seguridad? ¡Gracias de antemano!
3 Me gusta
+1 para esto, de nuevo. Discourse es el único sistema dinámico donde se puede automatizar la copia de seguridad de la base de datos solo una vez al día.
No espero que esto cambie en el núcleo en el corto plazo. He tenido conversaciones sobre cambiar el valor predeterminado a más de una vez por semana y eso no está sucediendo.
Creo que lo que podría ser bueno es un plugin que agregue una configuración del sitio para hacer copias de seguridad solo de la base de datos en un número de horas (no hay razón para mantener un montón de copias de subidas incompresibles en todas esas copias de seguridad completas). Si estás interesado, envíame un mensaje privado o pregunta en el mercado.
2 Me gusta
Si necesita una mejor recuperación ante desastres, le recomiendo seguir Ejecutar Discourse con un servidor PostgreSQL separado y ejecutar PostgreSQL por su cuenta, donde puede controlar la alta disponibilidad exacta que necesita, como réplicas de sincronización en vivo, recuperación ante punto en el tiempo y copias de seguridad más frecuentes.
3 Me gusta
¿Puedo preguntar el motivo de esta política, es por motivos técnicos o más por clase? Una diferencia de 24 horas entre copias de seguridad es un problema bastante crítico en foros con mucho tráfico. ¿O es algo que solo ofrecen a los clientes de pago?
1 me gusta
¿Correr Discourse con un servidor PostgreSQL separado reduce la velocidad al estar en un servidor diferente?
1 me gusta
Claro, esa es una solución. Una solución bastante rara entre las aplicaciones, sin embargo. En el mundo de PHP/MySQL, hacer una copia de seguridad de la base de datos usando cron sería muy fácil de hacer, pero de nuevo, en ese mundo, cada aplicación puede hacerlo por sí misma, con o sin algún plugin.
Sí, soy un poco más que un usuario final promedio 
pero tengo una comprensión muy superficial de cómo funcionan Docker, Rails, etc., y para mí, la situación en la que las tareas comunes son casi imposibles es realmente difícil de entender. Claro, quizás se deba a mis limitaciones, pero no soy el único que se pregunta esto.
Bueno. No obtendremos copias de seguridad de la base de datos fácilmente en el futuro cercano o mediano, eso lo entiendo.
1 me gusta
También puedes configurar copias de seguridad de PostgreSQL con cron. Nada diferente aquí.
No de ninguna manera relevante. Cada instancia de Discourse que alojamos, como esta aquí, utiliza una base de datos en un servidor dedicado.
2 Me gusta
Solo te hago dos preguntas para entender mejor.
- ¿La base de datos es lo único que necesitas para restaurar todo? La copia de seguridad que se realiza diariamente a través de la configuración, ¿es solo de la base de datos?
- ¿Debería el foro estar en modo de solo lectura al hacer la copia de seguridad de la base de datos? ¿O se puede hacer sin ningún problema, en cualquier momento?
¡Muchas gracias de antemano!
2 Me gusta
La configuración reside en la base de datos.
Técnicamente, también querrás hacer una copia de seguridad de la carpeta de subidas (uploads) y la definición del sitio app.yml. Sin embargo, eso generalmente se maneja teniendo el app.yml en control de versiones y las subidas en un servicio de almacenamiento de objetos.
No es necesario ponerlo en modo de solo lectura.
4 Me gusta
Entonces, asumiendo que tengo la base de datos en un servidor separado y hago copias de seguridad de esa base de datos cada hora. Si también hago una copia de seguridad, desde la configuración en el panel de administración, solo se incluirían en la copia de seguridad los archivos, incluido el archivo app.yml y la carpeta uploads, pero no la base de datos, ¿verdad? @Falco
1 me gusta
La copia de seguridad incluirá la base de datos y las subidas (si no están en S3). app.yml no está en la copia de seguridad, ya que Discourse no puede leerlo.
Lo que recomiendo para la mayoría de las personas es tener las copias de seguridad en S3 y app.yml en algún lugar al que puedas acceder en caso de emergencia. Luego, puedes crear un nuevo contenedor con app.yml y restaurarlo desde la línea de comandos. Pero si tienes los conocimientos técnicos para hacer copias de seguridad/restaurar postgres con otra herramienta, y las imágenes están en S3 (o tal vez las tienes respaldadas de alguna otra manera también), entonces puedes simplemente reconstruir el contenedor y volver a estar en funcionamiento.
O tal vez quieras tener varios servidores postgres replicados continuamente y luego organizar un cambio automático a la copia de seguridad si el principal falla.
Hay un millón de maneras de proporcionar copias de seguridad más frecuentes de las que ofrece Discourse. Si necesitas copias de seguridad más frecuentes, tendrás que hacerlo de otra manera.
2 Me gusta
Otro punto aquí es el riesgo y el mantenimiento: si utiliza la solución diaria lista para usar, es probable que sea una solución de respaldo más robusta y confiable que si procede a configurarla usted mismo. ¿Qué pasa si algo sale mal con su propia solución y solo se da cuenta cuando es demasiado tarde? Al menos con la solución estándar, tiene cientos de sitios probándola a diario.
Dado que no he tenido una sola experiencia de corrupción en varios sitios en 4 años, el riesgo de necesitar realmente la copia de seguridad en primer lugar también es bajo…
Quizás otros puedan mencionar mayores riesgos, pero probablemente el mayor riesgo sean los problemas debido a que el servidor se llena? ¿Así que vigile el espacio? ¿Configurar una alerta?
3 Me gusta
Entonces, por lo que entiendo, la mejor manera es mantener todo por separado.
Servidor principal para ejecutar Discourse. Luego un servidor para PostgreSQL y S3 (o cualquier otro servicio de almacenamiento de objetos) para las cargas.
El archivo app.yml me parece que no cambia a menudo, por lo que solo necesitas guardarlo una vez. O como mucho unas pocas veces durante el mes.
Esto te permite hacer copias de seguridad de tus archivos, incluso de una manera más organizada.
Si es así, encuentro que su decisión de no implementar copias de seguridad diarias múltiples en el núcleo tiene sentido. Por otro lado, aquellos que tienen necesidades complejas ciertamente harán configuraciones particulares como esa. Y al final, solo necesitas rehacer la instalación (con el app.yml guardado en algún lugar) y luego volver a conectarlo a la base de datos y al S3 para las cargas de datos. Las copias de seguridad están en esos 2 servidores por separado, por lo que es fácil de administrar para mí. Me parece una solución muy justa.
Gracias a todos por la explicación.
3 Me gusta
Hay otro hilo aquí: Configure automatic backups for Discourse - #113 by Tris20
@pfaffman hizo algunas recomendaciones allí con enlaces. Esto me llevó a la línea de comandos como una forma de programar copias de seguridad más frecuentes, lo que para mí es una solución bastante razonable:
Tenga en cuenta que con esta solución podría combinarlo todo en un script de Python para programar también una copia del archivo yaml, etc., al mismo tiempo.
2 Me gusta
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.