Cómo reparar Immich después de que su volumen de base de datos se llene

Cuando el volumen de la base de datos de Immich se llena, detén las nuevas escrituras de Immich, conserva el directorio de datos de PostgreSQL y crea espacio de trabajo seguro antes de intentar la recuperación. No elimines archivos de pg_wal ni de otras estructuras internas de PostgreSQL simplemente porque sean grandes.

Un sistema de archivos de base de datos lleno puede interrumpir los puntos de control o la recuperación tras un fallo, por lo que los reinicios repetidos pueden seguir fallando incluso después de que la aplicación de fotos parezca estar en buen estado. Primero confirma qué sistema de archivos está lleno —los datos de PostgreSQL, el almacenamiento raíz de Docker, la memoria compartida u otro punto de montaje— y luego recupera esa capa sin destruir las pruebas que puedas necesitar para volver atrás.

Confirma qué sistema de archivos está lleno y detén las escrituras adicionales

Comprueba la disponibilidad de bytes e inodos para el punto de montaje de PostgreSQL, la raíz de datos de Docker, el sistema de archivos raíz del host y cualquier ruta tmpfs o de memoria compartida mencionada en el error. Compara la marca de tiempo con los registros de PostgreSQL. Un mensaje de «no queda espacio en el dispositivo» procedente de pg_wal significa algo diferente de una caché de imágenes llena o de una partición de miniaturas llena.

Un debate sobre la recuperación de la base de datos de Immich muestra que PostgreSQL canceló la recuperación porque no pudo escribir un archivo WAL temporal después de que se llenara el almacenamiento. El caso es antiguo y específico de una implementación, pero demuestra por qué cambiar los permisos de los archivos o reiniciar la pila no soluciona un fallo de capacidad.

Pausa las cargas y las tareas en segundo plano; después, detén los componentes de la aplicación que generan nuevo trabajo para la base de datos. Conserva la primera ventana de registros con el fallo y el mapa de puntos de montaje. Si el sistema de archivos lleno no es realmente el sistema de archivos de datos de PostgreSQL, repara la ubicación correcta en lugar de mover la base de datos innecesariamente.

Conserva el estado de PostgreSQL antes de liberar espacio

Con PostgreSQL detenido, crea una instantánea del sistema de archivos o una copia completa del directorio de datos de la base de datos cuando el almacenamiento y las herramientas lo permitan. Incluye el directorio WAL y cualquier espacio de tablas no predeterminado como un único estado. Esta copia de seguridad te permite volver al punto del incidente si el siguiente intento de recuperación empeora la situación.

La guía de recuperación de PostgreSQL cuando se queda sin espacio en disco deja clara la regla fundamental: WAL forma parte de la coherencia de la base de datos, no es un conjunto de registros desechables, y eliminarlo manualmente puede corromper la base de datos. En su lugar, crea capacidad ampliando o moviendo el volumen, o eliminando datos no relacionados que sea seguro borrar. No sobrescribas inmediatamente la base de datos fallida con la última copia de seguridad, a menos que hayas decidido que el estado actual es irrecuperable y aceptes perder los cambios posteriores a esa copia. Conservar la instancia llena te proporciona un punto de reversión y pruebas de por qué desapareció la capacidad.

Recupera PostgreSQL primero y después decide si Immich necesita reparación

Una vez que haya espacio suficiente, inicia PostgreSQL por sí solo o con la pila mínima necesaria y observa los registros de recuperación. Un inicio limpio, una comprobación de estado correcta y un acceso normal de lectura son señales más sólidas que un estado del contenedor de «en ejecución». Crea una copia de seguridad nativa de la base de datos en cuanto esta sea lo bastante estable para hacerlo.

La guía de ZimaSpace sobre el mantenimiento o la sustitución de la base de datos de Immich establece el siguiente límite: los problemas normales de tamaño o rendimiento no deberían provocar una reconstrucción, mientras que los fallos repetibles de integridad o recuperación pueden justificar la restauración de una copia verificada de la base de datos.

Inicia Immich solo después de que PostgreSQL se mantenga en buen estado.

Comprueba los usuarios, la cronología, varios originales, los álbumes, la búsqueda y una nueva carga controlada. Si la base de datos se inicia, pero las consultas de la aplicación fallan de forma constante, conserva los nuevos registros y determina si el problema activo es ahora la compatibilidad de esquema o versión, o la integridad de los datos, y no el espacio libre.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

$799.00 - $2,499.00

Buy Now

Corrige la causa del crecimiento y demuestra que el sistema puede volver a llenarse de forma segura

Mide qué parte creció: las tablas normales de la base de datos, la retención de WAL, las copias de seguridad almacenadas en el mismo volumen, los registros, las capas de Docker o una ruta inesperada. Si el incidente se debió a un flujo de archivado o replicación fallido, o a otro servicio que escribía en el volumen de la base de datos, corrige esa causa en lugar de limitarte a aumentar la capacidad.

Configura alertas mucho antes de que el volumen alcance el punto en el que PostgreSQL no pueda realizar puntos de control o recuperarse. Supervisa tanto el porcentaje como el espacio libre absoluto, porque un volumen grande puede tener un porcentaje pequeño de espacio libre y aun así suficiente margen de trabajo, mientras que un volumen pequeño de base de datos puede volverse peligroso rápidamente. Mantén las copias de seguridad de la base de datos fuera del mismo límite de fallo que protegen.

Por último, repite un ciclo normal de carga y procesamiento en segundo plano, crea una copia de seguridad nueva de la base de datos, reinicia la pila y reinicia el host. La prueba se considera superada si la disminución del espacio libre es estable, no aparecen errores de WAL ni de recuperación, los recursos antiguos y nuevos se pueden leer y existe un umbral documentado que activa medidas antes de que las escrituras vuelvan a fallar.