La copia de seguridad de los datos disminuyó repentinamente, la restauración de los datos disminuidos es anormal y el sitio web no puede interactuar normalmente. Afortunadamente, el bucket de almacenamiento de Amazon S3 puede encontrar datos históricos, de lo contrario, las pérdidas serían inconmensurables.
1 me gusta
¿Hubo algún cambio de configuración en ese período de tiempo que pudiera haber afectado si las cargas se incluyeron en sus copias de seguridad?
2 Me gusta
Se ha realizado una actualización, se ha utilizado un tema, se han añadido complementos personalizados al tema (css personalizado), los usuarios pueden optar por desactivar la paleta de colores, se utilizan data.yml y web_only.yml. Después de restaurar los datos con 262 Mbyte, la copia de seguridad actual solo tiene 154 Mbyte, por lo que se estima que estos datos de copia de seguridad todavía tienen problemas.
1 me gusta
¿Cambiaste a una configuración de dos contenedores en ese momento, o siempre la estuviste usando?
1 me gusta
Lo he estado usando así, ¿cuáles podrían ser las razones?
1 me gusta
Intenté restaurar mi última copia de seguridad hace un par de días y la carga en mi panel fue rechazada. Por un segundo sentí que mi copia de seguridad se había perdido, así que intenté subirla de nuevo por FTP y, ¿adivina qué? ¡restaurada! pero esto sucedió lo mismo y me gustaría saber el motivo.
Me temo que estoy más familiarizado con la instalación estándar y no estoy seguro de si la configuración de dos contenedores tiene alguna peculiaridad que pueda ser relevante aquí.
Permítanme pasar esto a Installation y ver si podemos conseguir que algunas personas con más experiencia lo revisen. 
(@pfaffman 
)
1 me gusta
Anteriormente, utilicé la instalación estándar, pero la instalación estándar tiene un problema: cada vez que modifico app.yml, mi sitio web no puede accederse normalmente. Si uso data.yml o web_only.yml, puedo hacer modificaciones en web_only.yml sin afectar el acceso al sitio web. ¿La instalación estándar tiene una función similar y cómo se usa específicamente?
No. La única diferencia es que una reconstrucción reconstruye solo las partes de rails y nginx. La base de datos y redis permanecen iguales. Estos cambian raramente, por lo que no necesitan ser reconstruidos. Funciona exactamente igual. Lo entiendes perfectamente. (La única complicación es cuando hay una actualización de postgres o redis, lo cual ocurre una vez al año, aunque hubo algunas actualizaciones de base de datos que sucedieron debido a los requisitos del plugin de IA. Así que si no estuvieras usando el plugin de IA, estarías perfectamente bien, pero si lo estuvieras, obtendrías errores de base de datos confusos si no reconstruyeras también el contenedor de datos).
Mi suposición es que movieron los activos a s3 y, por lo tanto, las cargas locales no están incluidas. Esto es consistente con que dijeran que pudieron restaurar cosas de s3. O tal vez eliminaron algunas publicaciones que tenían cargas, por lo que esas cargas no se incluyeron en copias de seguridad posteriores.
Además, sonó un poco como si hubieran hecho una restauración y no hubieran esperado a que terminara por completo.
1 me gusta
Sí que usé un plugin de IA. ¿A qué debo prestar atención para que los datos de copia de seguridad se puedan utilizar? ¿Cómo debemos lidiar con este tipo de problema?
¿Significa que mientras data.yml no se reconstruya no hay problema, o es necesario usar app.yml, o este tipo de problema existe tanto en el plan web_only de data.yml como en el plan de app.yml?
Significa que mientras data.yml no se reconstruya no hay problema, o es necesario usar app.yml, o este tipo de problema existe tanto en el plan web_only de data.yml como en el plan de app.yml
El problema es que cuando hice la copia de seguridad, el contenedor construido por data.yml no era compatible, y la base de datos se actualizó. Si la reconstrucción de data.yml se actualiza, no habrá ningún problema, incluso si se realiza una actualización importante de la base de datos, y entonces no habrá ningún problema con la copia de seguridad y la restauración. ¿Cómo puedo saber que su base de datos ha sido modificada en gran medida?
El problema es que cuando hice la copia de seguridad, el contenedor construido por data.yml no era compatible, y la base de datos se actualizó. Si la reconstrucción de data.yml se actualiza, no habrá ningún problema, incluso si se realiza una actualización importante de la base de datos, y entonces no habrá ningún problema con la copia de seguridad y la restauración. ¿Cómo puedo saber que su base de datos ha sido modificada en gran medida?
@sober, como nota de proceso, es mucho más fácil para quienes leen/quieren ayudar si incluyes una traducción al inglés en tus publicaciones. ¿Podrías editar una? 
5 Me gusta
Ahora entiendo que el problema fue una gran actualización de la base de datos que causó problemas de copia de seguridad.
3 Me gusta
Cuando Discourse se actualiza, ¿cómo puedo asegurarme de que la versión actualizada sea una versión beta en lugar de una versión de desarrollo? Después de que la última copia de seguridad salió mal, tengo que preocuparme por las operaciones de actualización y restauración de copias de seguridad.
1 me gusta
¿Qué? Bueno, esperaré una confirmación porque no sé si romperá algo aquí.
Solo quiero actualizar beta2, no beta2-dev, porque me temo que dev es inestable, y la copia de seguridad de datos reciente no se puede restaurar normalmente, lo que casi causa pérdida de datos. Usé la copia de seguridad temprana para respaldar, pero los datos aún se perdieron durante un período de tiempo.
1 me gusta
No lo son, eso es solo un cambio reciente en el sistema de versiones. Técnicamente, ni siquiera deberías ver las etiquetas -dev.
3 Me gusta