¿Qué método de respaldo mantiene consistente un contenedor de base de datos en ejecución en un NAS doméstico?

Para la mayoría de los usuarios de NAS domésticos y servidores autoalojados, el valor predeterminado más seguro es una copia de seguridad lógica nativa de la base de datos creada mientras la base de datos está en ejecución, seguida de una copia de seguridad normal de ese volcado junto con la configuración del contenedor y los archivos de la aplicación. Use una copia corta con el contenedor detenido cuando el tiempo de inactividad sea aceptable, y use una instantánea coordinada del sistema de archivos solo cuando la base de datos esté vaciada, bloqueada, con punto de control o preparada de otro modo para la instantánea. Una copia simple de un volumen de base de datos en vivo no es un método de respaldo consistente.

Definir “Consistente” como una restauración que la base de datos acepte

Una copia de seguridad consistente no es solo un árbol completo de carpetas. Después de la restauración, el motor de la base de datos debe iniciar, recuperar transacciones correctamente, pasar verificaciones de integridad y presentar un estado en un punto en el tiempo que la aplicación pueda usar. En un servidor doméstico que ejecuta Immich, Nextcloud, Paperless-ngx, Home Assistant u otra aplicación autoalojada, eso significa que la base de datos, las cargas, la configuración y los secretos deben estar sincronizados entre sí.

La persistencia del contenedor solo explica dónde viven los archivos. No hace que una base de datos en ejecución sea segura para copiar. Una base de datos puede tener transacciones activas, páginas en caché, registros de escritura anticipada, archivos temporales o metadatos que cambian mientras el software de respaldo del NAS lee el volumen.

Método 1: Usar un volcado lógico nativo de la base de datos como predeterminado en el NAS doméstico

Un volcado lógico solicita al motor de la base de datos exportar una representación consistente de esquemas y registros. Para un contenedor modesto de PostgreSQL o MariaDB en un NAS familiar, este suele ser el método más fácil para programar, inspeccionar, copiar fuera del sitio y restaurar en un contenedor de reemplazo limpio. Una guía actual de respaldo en Docker demuestra este patrón ejecutando volcados nativos de bases de datos desde un contenedor de respaldo programado.

Escriba el volcado en un directorio de respaldo dedicado fuera del volumen de datos en vivo. Luego, deje que el trabajo de respaldo del NAS proteja el volcado, el archivo Compose, la plantilla de entorno, la configuración de la aplicación y los datos cargados. No exponga contraseñas de producción dentro del nombre del archivo del volcado ni en registros sin protección.

Método 2: Detener brevemente la base de datos antes de copiar su volumen

Una copia de contenedor detenido es simple y físicamente completa. Detenga primero a los escritores de la aplicación, detenga la base de datos limpiamente, confirme que el proceso ha salido, copie todo el volumen persistente o el directorio de base de datos montado por enlace, y luego reinicie el conjunto. Una guía de Docker y MariaDB describe las copias de volúmenes físicos como rápidas pero dependientes de la versión y normalmente ligadas al tiempo de inactividad.

Este método funciona bien para un NAS doméstico pequeño donde unos minutos de mantenimiento son aceptables y la restauración usará una versión compatible de la base de datos. Es menos portátil que un volcado lógico y puede extender el tiempo de inactividad cuando el volumen es grande. Mantenga la etiqueta de la imagen de la base de datos y la disposición del almacenamiento con el respaldo para no restaurar archivos físicos en una versión de motor incompatible.

Método 3: Coordinar una instantánea rápida con la base de datos

Los sistemas de instantáneas ZFS, Btrfs, LVM y NAS pueden capturar un volumen grande de base de datos rápidamente, pero la instantánea debe coordinarse con la base de datos. Para MariaDB o MySQL, eso puede significar una ventana corta de bloqueo o vaciado; para PostgreSQL, puede significar el proceso de respaldo o punto de control soportado por la base de datos; para una base de datos gestionada por la aplicación, puede significar un gancho previo a la instantánea.

Una discusión sobre instantáneas de bases de datos explica que una copia en disco en vivo puede ser internamente inconsistente a menos que la base de datos esté congelada o la instantánea se tome de forma atómica. El intervalo de bloqueo o pausa debe ser corto: preparar la base de datos, crear la instantánea, liberar las escrituras y copiar la instantánea después.

Este método es útil cuando la base de datos es demasiado grande para volcados lógicos frecuentes o cuando necesita un intervalo de punto de recuperación más bajo. Requiere una secuenciación y pruebas de restauración más cuidadosas que un flujo de trabajo básico de volcado en un servidor doméstico.

No trate la imagen de Docker ni la exportación del contenedor como respaldo de base de datos

La imagen del contenedor contiene el entorno de ejecución de la aplicación, no necesariamente los datos persistentes en vivo. Exportar o confirmar el contenedor puede omitir volúmenes nombrados y no solicita a la base de datos crear un punto de recuperación consistente. Una cuenta de respaldo de contenedor PostgreSQL concluye que Docker save y commit no reemplazan las técnicas de respaldo específicas de PostgreSQL.

Para un servidor doméstico ZimaOS o Docker, mantenga la definición de despliegue y el plan de protección de datos separados: preserve los archivos Compose y las etiquetas de imagen para que el servicio pueda reconstruirse, y preserve la base de datos mediante un método consistente con la base de datos para que su estado pueda restaurarse.

Nunca copie directamente un volumen de base de datos que se esté escribiendo activamente

El software de copia de seguridad NAS puede leer diferentes archivos de base de datos en diferentes momentos. El archivo resultante puede contener un archivo de datos de un estado de transacción, un registro de otro y metadatos de un tercero. Una visión general de los métodos de copia de seguridad SQL de código abierto advierte que una base de datos en movimiento puede capturarse en un momento inconsistente mientras un estado importante aún está en memoria.

La recuperación de fallos puede reparar algunas instantáneas capturadas atómicamente, pero una copia recursiva ordinaria de archivos no es atómica. Si la aplicación no puede tolerar tiempo de inactividad, use un volcado lógico, una herramienta de copia de seguridad física compatible o una instantánea coordinada en su lugar.

Trate los contenedores SQLite como bases de datos, no como archivos ordinarios

Muchas aplicaciones para servidores domésticos usan SQLite porque es compacto y fácil de implementar. El riesgo es que los administradores vean un archivo .db y asuman que puede copiarse mientras la aplicación escribe. En modo WAL, los cambios comprometidos recientes pueden estar aún fuera del archivo principal. Un artículo práctico sobre recuperación de SQLite recomienda usar el mecanismo de copia de seguridad en línea o una copia cerrada limpia en lugar de copiar un archivo de base de datos en vivo.

Use la copia de seguridad incorporada de la aplicación si tiene una. De lo contrario, use la función de copia de seguridad en línea propia de SQLite o detenga la aplicación limpiamente antes de copiar todo el directorio de la base de datos. No copie solo el archivo principal de la base de datos dejando atrás su estado de diario o WAL.

Elija el método según el tiempo de inactividad, tamaño de la base de datos y portabilidad de la restauración

Respalde Toda la Aplicación Autoalojada, No Solo la Base de Datos

Un paquete de recuperación utilizable debe incluir la copia de seguridad de la base de datos, el archivo Docker Compose, las versiones de las imágenes, las variables de entorno o un paquete de secretos recuperable, la configuración del proxy inverso, la configuración de la aplicación, los archivos subidos y cualquier clave de cifrado. Respaldar solo el volcado SQL puede restaurar registros pero dejar la aplicación incapaz de encontrar fotos, documentos, miniaturas, certificados o rutas de almacenamiento.

Para la planificación de recuperación del servidor doméstico, la guía de ZimaSpace sobre montajes bind y volúmenes nombrados explica por qué las rutas de almacenamiento visibles ayudan en la recuperación pero aún no reemplazan una copia de seguridad de base de datos consistente con la aplicación.

Demuestre el Método Restaurando en un Nuevo Contenedor

Cree una pila de prueba aislada con un nuevo nombre de proyecto, diferentes puertos de host y un directorio de datos temporal. Restaure el volcado o la instantánea, inicie la base de datos, ejecute sus verificaciones de integridad o consistencia y luego conecte una copia de prueba de la aplicación. Confirme que los usuarios, registros, adjuntos y transacciones recientes estén presentes.

Mida tanto el punto de recuperación como el tiempo de recuperación. Si un volcado lógico es consistente pero tarda demasiado en restaurarse, manténgalo como la capa de recuperación portátil y agregue una instantánea coordinada más rápida. Si una copia de volumen detenido se restaura rápidamente pero solo a la misma versión de la base de datos, conserve un volcado lógico como respaldo para migración.

Preguntas Frecuentes

¿Es suficiente pausar un contenedor de base de datos antes de copiar el volumen?

No como regla general. Pausar congela el proceso pero no prueba que la base de datos haya vaciado el estado correcto para una copia de seguridad portátil. Use un volcado nativo de la base de datos, un apagado limpio o un procedimiento documentado de pausa y instantánea.

¿Es suficiente una instantánea NAS sola para PostgreSQL o MariaDB?

Solo cuando la instantánea sea atómica y coordinada con el proceso de consistencia soportado por la base de datos. Una instantánea no coordinada puede ser simplemente consistente con un fallo, y una copia de archivo no atómica puede ser peor.

¿Qué debo respaldar para una aplicación de servidor doméstico basada en SQLite?

Utilice la exportación de la aplicación o la copia de seguridad en línea de SQLite cuando esté disponible. También preserve la configuración de la aplicación, el archivo Compose, los secretos, los adjuntos y el directorio que contiene la base de datos en lugar de asumir el principal. .db el archivo es toda la aplicación.

Recomendación Final

Utilice volcados lógicos programados como predeterminado para la mayoría de los contenedores PostgreSQL y MariaDB en un NAS doméstico. Use una copia limpia del volumen detenido cuando se acepte un tiempo de inactividad corto, y utilice instantáneas coordinadas o herramientas físicas nativas de la base de datos cuando la base de datos sea grande o la ventana de punto de recuperación sea estrecha. Sea cual sea el método que elija, restáurelo en un nuevo contenedor antes de confiar en él.