Tengo una triste historia hoy. Perdí todos los cambios que hice en la base de datos desde el sábado.
Usamos mongodb (3.4.1) y, en este caso particular, se ejecutaba dentro de su contenedor docker oficial con volumen asignado.
El contenedor se creó con docker-compose, docker-compose.yml se ve así:
version: "2" services: database: image: mongo:3.4.1 restart: always container_name: cvs-db volumes: - ~/data/db:/data/db ports: - "27017:27017" ~/data/db es solo una carpeta normal creada hace mucho tiempo.
Después de reiniciar el contenedor (con docker-compose up -d ), los datos volvieron al estado que tenían hace dos días. Incluso las eliminaciones desaparecieron.
Limpiamos todas las colecciones ayer y comenzamos a llenarlas con datos reales y ahora contiene todos los datos de prueba que eliminamos recientemente.
Entonces, mis preguntas son: 1) ¿cómo proteger los datos de mongodb de tales desastres? 2) ¿alguien puede decir las condiciones exactas que pueden conducir a estos resultados? 3) ¿Cómo restauro los datos?
EDITAR: después de algunas investigaciones, creo que fue culpa de docker-compose. Pero las preguntas siguen siendo válidas :)
Mirando su archivo de redacción, está haciendo referencia al directorio de origen como el ~/data/db relativo. Si tiene más de una cuenta de usuario en el sistema que puede acceder a ese archivo de redacción (es decir, root más una cuenta de usuario con nombre), entonces el directorio "~/data/db" sería diferente según el usuario que ejecutó compose para iniciar el contenedor. . Tal vez algo así sucedió en su entorno.
Es mejor usar una ruta absoluta a su volumen de host (es decir /opt/data/db:/data/db ) en lugar de algo que pueda cambiar según el usuario o el contexto del directorio principal para evitar la posibilidad de este tipo de problema .
El uso de un directorio de host estándar como volumen de datos no debería dar lugar a una reversión espontánea de los datos. Si no es un problema con el contexto del directorio como se mencionó anteriormente, entonces es posible que haya algún otro factor involucrado, como que alguien revierta una instantánea del sistema de archivos, restaure una copia de seguridad o altere la base de datos directamente.