No estoy seguro si responder aquí o si se justifica una nueva publicación: Solicitud de función: programaciones separadas para ‘incluir archivos adjuntos’ y ‘no incluir archivos adjuntos’.
Realmente me encantaría tener copias de seguridad pequeñas diarias, posiblemente incluso varias veces al día, ya que esa base de datos es pequeña. No me devastaría perder una semana de archivos adjuntos, ya que son mucho más limitados y, por lo general, las personas pueden encontrar su origen nuevamente. Esto podría aumentar el factor de seguridad sin abrumar el almacenamiento.
No he mirado el código fuente, pero probablemente sería una revisión importante, ya que las restauraciones tendrían que ser entidades separadas, o al menos la capacidad de tener diferentes puntos de restauración para las 2 fuentes.
Bastante razonable. Tan pronto como empiezo a considerar herramientas externas, pienso en “formas externas de estropearlo de verdad”, ya que normalmente son capaces de causar más estragos que la consola de administración integrada a prueba de tontos (más o menos).
La última vez que yo, y otros, preguntamos lo mismo, las respuestas fueron las mismas que antes:
una copia de seguridad diaria es suficiente
usar herramientas externas, como scripts y cron
Bueno, una copia de seguridad diaria de la base de datos no es suficiente, cada hora podría ser cercana.
Cualquier herramienta externa puede hacer el trabajo, eso es cierto. Pero todas las demás aplicaciones ofrecen copias de seguridad decentes de forma nativa, pero no Discourse.
Realmente me gustaría saber si la razón de eso es
“simplemente no queremos, por eso nadie más lo necesita”
es técnicamente muy difícil y/o caro
Bueno, y siempre hay una tercera opción: Marketplace
Si quieres muchas copias de seguridad con WordPress (una plataforma web popular) necesitas usar un plugin de copias de seguridad que cuesta dinero, así que quizás no todas las demás aplicaciones lo hacen de forma nativa. Al menos eso es lo que estoy haciendo, aunque hace mucho tiempo que tomé esa decisión, así que quizás fue una mala decisión.
La razón es que tener muchas copias de seguridad es una forma de llenar tu disco, que es una de las razones más comunes por las que un sitio autoalojado falla (lo que creo que lo pone en la categoría de “costoso”). Así que la idea es que si tienes suficientes habilidades para gestionar un montón de copias de seguridad y gestionar tu espacio en disco, entonces probablemente puedas resolver esto de muchas maneras. Y si quieres copias de seguridad cada hora, entonces necesitas que sean copias de seguridad solo de la base de datos en lugar de docenas o cientos de copias de tus subidas.
Así que las copias de seguridad cada hora solo tienen sentido si tienes subidas en S3 para que puedas hacer copias de seguridad solo de la base de datos, y probablemente enviarlas a S3 para que no te preocupes por tu disco local. Y entonces ese es un número bastante pequeño de sitios autoalojados que quieren eso.
Si tienes todo eso implementado, entonces un plugin que hiciera copias de seguridad horarias solo de la base de datos no llevaría más de una o dos horas de trabajo, o quizás 2-10 si no sabes cómo hacer un plugin y tienes que averiguar cómo hacer un trabajo horario.
Eso es cierto. WordPress en sí mismo no puede hacer mucho. Por eso hay tantos plugins, buenos y malos.
Eso no es cierto. Solo los extras cuestan, no la copia de seguridad en sí.
Por supuesto, no tiene sentido hacer copias de seguridad de archivos o del sistema en sí, tan a menudo. La base de datos en sí es un juego de pelota totalmente diferente. Debería hacerse al menos cada 15 minutos si hay más tráfico.
La pregunta es muy fácil: ¿cuánto contenido puedes perder?
Si la pérdida máxima de datos que puedes permitirte es tan pequeña, podrías considerar usar una solución de replicación de Postgres en lugar de hacer copias de seguridad con tanta frecuencia.
¿Hay otros datos de los que no soy consciente? ¿O usas datos en un sentido más amplio, incluyendo todos los archivos; del sistema, de Docker/Discourse/etc., subidos?
Esos archivos se pueden recuperar fácilmente o con pequeños costos; bueno, excepto los subidos, pero para eso tenemos S3 .
Entonces es mayormente pequeño en tamaño, pero es el más grande si pensamos en el foro en sí. Pero por alguna razón hemos vuelto a esto:
Realmente me gustaría saber si el problema principal aquí es técnico o mental. ¿O es esto en realidad parte del modelo de negocio y si la copia de seguridad es fácil y funciona, el hosting perderá un argumento de venta —y no sé si existe tal argumento de venta en absoluto. Solo estoy tratando de entender por qué una mejor copia de seguridad es una cuestión tan importante, incluso si ya se ha solicitado antes.
No hay necesidad de sospechar que hay una estrategia o un plan malvado detrás de esto. No creo que haya mucho interés en copias de seguridad más frecuentes. Si lo hubiera, alguien habría escrito un plugin para ello. Eso sería unas pocas horas de trabajo. No veo el Marketplace inundado de solicitudes para ello.
Creo que se reduce a:
para foros pequeños, de todos modos no perderás muchos datos porque no hay mucho nuevo en un día, por lo que las copias de seguridad más frecuentes no valen la pena el esfuerzo
para foros más grandes, las copias de seguridad más frecuentes consumirán rendimiento y almacenamiento
para foros realmente grandes, querrás buscar diferentes soluciones (como la replicación a un servidor de base de datos de espera activa)
No olvides que las probabilidades de necesitar una copia de seguridad también son muy pequeñas. En la historia de Communiteq (más de 8 años), solo hemos necesitado restaurar una copia de seguridad una vez, y eso fue solo porque fuimos impacientes y no quisimos esperar unas horas para la recuperación del sistema de archivos.
*) (excluyendo restauraciones a petición del cliente donde solo querían revertir cambios, principalmente en foros no de producción, y excluyendo nuestra prueba de restauración mensual)
Entonces, si busco aquí, no encuentro ningún tema en el que Discourse se haya bloqueado por alguna razón y la única solución haya sido restaurar desde una copia de seguridad.
Pero es bueno saber que Discourse es tan sólido que no necesita copias de seguridad actualizadas. Bueno, sabemos que eso no es totalmente cierto.
Entonces, el círculo se cierra y volvemos a donde empecé:
Y la tercera opción. Mientras de facto estoy probando Discourse, aquí y por mi cuenta, no estoy dispuesto a pagar por una funcionalidad tan básica.
Bueno, estamos hablando aquí sin ningún comentario del equipo. De nuevo
Esta es la forma. Siga Ejecutar Discourse con un servidor PostgreSQL separado para ejecutar su propia instancia de PostgreSQL y gestionar las copias de seguridad y la alta disponibilidad según le convenga si la copia de seguridad diaria no es suficiente para su caso de uso.
Estoy pensando en $250-500, dependiendo de qué tan configurable sea y cuánto trabajo se necesite en el front-end. Sin embargo, en realidad no he mirado lo que tomaría. @RGJ podría hacerlo por menos; a menudo me ha sorprendido con la rapidez con la que puede hacer las cosas.
EDITAR: OH, este tema está cerrado. Si estás interesado, puedes contactarme o publicar en Marketplace.
.
