<![CDATA[Foro QNAP en español - Portal]]> https://www.qnapclub.es/ Fri, 17 Apr 2026 16:39:51 +0000 MyBB <![CDATA[Representación]]> https://www.qnapclub.es/showthread.php?tid=5794 Thu, 16 Apr 2026 11:39:49 +0200 Blas-femia]]> https://www.qnapclub.es/showthread.php?tid=5794 Gracias a los administradores por ese trabajo que realizan y un saludo al resto.]]> Gracias a los administradores por ese trabajo que realizan y un saludo al resto.]]> <![CDATA[Instalación - Migración de QuTS Hero 6]]> https://www.qnapclub.es/showthread.php?tid=5793 Wed, 15 Apr 2026 02:51:57 +0200 yeraycito]]> https://www.qnapclub.es/showthread.php?tid=5793
Qnap lleva ya bastante tiempo enfocando sus lanzamientos hardware y algunas soluciones software a la gran empresa algo a lo que en principio no habría nada que objetar siempre y cuando no se aplique un olvido al resto de los usuarios. El problema es que a Qnap parece que se le olvida que la base de sus equipos estratosféricos es su sistema operativo y aunque ahora lo intenta remediar parciálmente con este nuevo Hero 6 el reciente pasado confirma ese olvido sin olvidar de que aunque llega tarde tampoco es que lo haga especiálmente bien. Por una parte el año pasado ni QTS ni el Hero recibieron nueva versión mayor algo que hasta la fecha ocurría todos los años, por otro lado se está a punto de lanzar el nuevo Hero 6 mientras que QTS 6 parece que a dia de hoy está en desarrollo sin ni siquiera una primera beta publicada dejando la salida de la versión final para finales de este año 2026 lo cual crea una segregación entre usuarios mindundis versus privilegiados. Pero es que los pretendidos esfuerzos por parte de Qnap de cara a triunfar en la gran empresa se ven enpequeñecidos aplicando en el nuevo Hero 6 ( y lo mismo harán con QTS 6 ) implementaciones rácanas comparándolas con su competencia natural y directa y hasta con la que no es directa como explicaré mas adelante. Actualizar bien y a su debido tiempo no solo permite mantener los equipos estables, seguros y modernizados sino que evita que los usuarios piensen que es mejor dedicar su dinero mirando hacia otro lado sin olvidar que las segregaciones están muy mal vistas a dia de hoy.


El componente principal de un sistema operativo es su kernel y desde hace ya unos años tanto QTS como el Hero han mantenido el mismo kernel, el 5.10.60




.png   0.png (Size: 32,77 KB / Downloads: 67)



El kernel 5.10 LTS tiene fecha de finalización de soporte diciembre de este año así que no le ha quedado otra a Qnap que subir de kernel y lo ha hecho a la versión 6.6.32 también LTS




.png   1.png (Size: 30,9 KB / Downloads: 65)



Y esta es una de muchas de las habituales racanerias de Qnap, han cogido un kernel publicado el 25 de Mayo de 2024 que no tiene mucho sentido cuando además del retraso con sus sistemas operativos se les  " olvida " que a dia de hoy existen dos kernels LTS mas modernos. Teniendo en cuenta que estamos hablando de la versión Hero con ZFS he intentado ver las diferencias entre el Hero 5 - 6 en la implementación de ZFS mediante comandos de consola y no ha habido forma debido a las limitaciones por parte de Qnap para su realización, un secreto que parece que Qnap intenta ocultar ya que es habitual que comuniquen que nuevo kernel implementa las versiones mayores pero no así la versión de ZFS que es otra de las bases del sistema junto al kernel. Aún así es razonable pensar que si aplican esa racatanería al kernel lo harán iguálmente con la versión de OpenZFS.

Las comparaciones son odiosas.... o eso dicen, podría comentar lo anterior con marcas como Ugreen o Terramaster pero lo voy a hacer con la alternativa mas cercana e igualitaria al Hero que no es otra que Truenas, este sistema operativo para nas basado también en ZFS tiene a dia de hoy publicada una beta de su próxima versión mayor ( kernel LTS 6.18.13 - OpenZFS 2.4.1 - Docker 29.0.4 )........ en fin, como digo las comparaciones a veces son odiosas.


Al principio he comentado que este tutorial consiste en explicar como instalar el nuevo Hero 6 a través de una REINICIALIZACION del nas, es decir, como si estuviera recién comprado. Los motivos por los que opto por este sistema en lugar de diréctamente actualizar son los siguientes:

 - Aumento de la versión del kernel linux LTS

 - Probable aumento de la versión de OpenZFS

 - Probable aumento de la versión Debian - Ubuntu de base

 - Desde que salió la primera beta del Hero 6 hasta su versión final van a pasar 5 meses lo cual es un desarrollo bastante largo en el tiempo que dan que 
   pensar que la reforma interna es grande. Por experiencia personal cambios grandes suelen dar problemas a corto o medio plazo por muy bien que se 
   hagan, la única forma de prevenirlos es a través de formateo + instalación limpia.

 - Uno de los motivos que reafirman lo anterior se puede ver en las notas de versión de la Release Candidate, dicen lo siguiente:
    
    Para garantizar la seguridad del sistema, a partir de la versión candidata h6.0.0, QuTS hero ya no se permite la degradación del firmware.

    Es decir, una vez instalado el Hero 6 ya no se permite la vuelta a otra versión anterior.



Os informo que debido a las limitaciones de espacio a la hora de subir imágenes a este foro he tenido que recortar algunas de ellas, lo importante se ve sin problemas, tan sólo se pierde la visualización de botones en la parte de abajo tipo Aplicar - Siguiente. Otra limitación la he tenido en la cantidad de imágenes, se me limita a 50 así que intentaré dividir la explicación en dos partes.


Para hacer la reinicialización nos vamos al apartado correspondiente del Panel de Control de nuestro nas:




.png   2.png (Size: 204,7 KB / Downloads: 65)



Se nos pide la contraseña del nas para proceder:




.png   3.png (Size: 206,09 KB / Downloads: 65)



Escojo la opción de Apagar el nas al terminar la reinicialización:




.png   4.png (Size: 163,31 KB / Downloads: 64)



El motivo por el que apago el nas es para sacar físicamente los discos duros y dejar únicamente los NVME ( el nas es un TS-264 )

Empieza el proceso de reinicialización:




.png   5.png (Size: 218,43 KB / Downloads: 66)



Pasan unos 10 minutos hasta que el nas se apaga. Una vez apagado retiro los discos duros y vuelvo a encender el nas a través de su botón físico, al hacerlo nos aparece la primera pantalla de configuración inicial:




.png   6.png (Size: 635,98 KB / Downloads: 66)



Al tener instalado anteriórmente el Hero 5 no tengo necesidad de darle al botón de Elegir otro firmware, si vosotros estáis en QTS 5 y queréis migrar al Hero si tenéis que darle a ese botón que es el que os permite el cambio de sistema operativo. En mi caso inicio la instalación inteligente y lo que me aparece son las Condiciones de uso que debemos aceptar:




.png   7.png (Size: 785,88 KB / Downloads: 65)



Lo siquiente que aparece son las opciones de firmware:




.png   8.png (Size: 569,29 KB / Downloads: 65)



Tengo descargado en mi ordenador desde la web de Qnap correspondiente a mi nas la RC del Hero 6 así que se lo indico, hecho esto procedo a actualizar.




.png   9.png (Size: 576,41 KB / Downloads: 64)




Os recuerdo que en este punto en el nas no hay nada instalado, lo que se está haciendo es actualizar el firmware alojado en la memoria DOM física del nas, tarda un poco en hacerse:




.png   10.png (Size: 408,36 KB / Downloads: 65)



Una vez actualizada la DOM volvemos a la pantalla inicial de la configuración, como ya hemos escogido anteriórmente el paso al Hero ya no nos aparece cambiar de versión:




.png   11.png (Size: 617,33 KB / Downloads: 67)



Nos obligan otra vez a aceptar las Condiciones del servicio:




.png   12.png (Size: 786,25 KB / Downloads: 65)



Nos vuelve a aparecer también la pantalla de elección de firmware, en este caso ya tenemos instalada la última versión:




.png   13.png (Size: 497,51 KB / Downloads: 65)



Lo siguiente es lo habitual, ponerle nombre al nas + usuario + contraseña:




.png   14.png (Size: 677,41 KB / Downloads: 66)



Escoger zona horaria:




.png   15.png (Size: 695,3 KB / Downloads: 66)



Configuración de red:




.png   16.png (Size: 454,85 KB / Downloads: 66)



Configuración de actualizaciones:




.png   17.png (Size: 620,72 KB / Downloads: 66)



Curiósamente siguen manteniendo la segmentación entre actualizaciones críticas o de calidad algo que nunca han implementado reálmente:




.png   18.png (Size: 602,6 KB / Downloads: 65)



Nos aparece un resumen de lo que acabamos de configurar:




.png   19.png (Size: 753,83 KB / Downloads: 66)



Ultimo aviso:




.png   20.png (Size: 378,92 KB / Downloads: 62)



Empieza el proceso:




.png   21.png (Size: 595,16 KB / Downloads: 67)



Cuando termina aparece un mensaje de error que también me apareció cuando me pasé anteriórmente de QTS al Hero:




.png   22.png (Size: 504,65 KB / Downloads: 64)



En la imagen que acabo de poner no se ve pero en la parte de abajo veréis que tenéis un botón para solucionar ese error, al darle nos aparece lo siguiente:




.png   23.png (Size: 43,39 KB / Downloads: 66)



Ponemos nuestro usuario - contraseña y accedemos a la interfaz del nas, nos aparece de primeras lo siguiente:




.png   24.png (Size: 109,95 KB / Downloads: 64)



Pasado el trámite.......




.png   25.png (Size: 593,33 KB / Downloads: 64)



Automáticamente se nos invita a crear un primer Conjunto de Almacenamiento:




.png   26.png (Size: 566,75 KB / Downloads: 66)



Antes de hacerlo vemos algunas de las opciones disponibles en la configuración, una de ellas es el porcentaje de utilización de la ram ARC que por defecto está en el 55% y que se puede reducir pero NO aumentar:




.png   27.png (Size: 448,87 KB / Downloads: 64)



Otras opciones disponibles son relativas a la monitorización de los discos:




.png   28.png (Size: 450,81 KB / Downloads: 65)



Lo siguiente que voy a hacer es crear un nuevo Conjunto de Almacenamiento pero explico que como novedad en el Hero 6 nos aparece la opción de crear un Conjunto de Almacenamiento Qtier, este sistema de Qnap se basa en que teniendo en el nas almacenamiento SSD - NVME + discos duros el sistema operativo va decidiendo donde se alojan los archivos dependiendo de su utilización, es decir, los que más se utilizan se almacenan en los nvme y los restantes en los discos duros mas lentos.




.png   29.png (Size: 159,1 KB / Downloads: 67)



Como he comentado antes en mi caso opto por crear un Conjunto de Almacenamiento clásico:




.png   30.png (Size: 738,64 KB / Downloads: 65)



En la siguiente pantalla tenemos que escoger si tenemos SSD - NVME ( tanto unos como otros Qnap los cataloga como SSD ) y el tipo de raid:




.png   31.png (Size: 227,46 KB / Downloads: 64)



En mi caso personal tengo una configuración algo especialita, 2 nvme de distinto fabricante y tamaño, opto por un Raid 0 un tipo de raid que aplicaré posteriórmente también a mis dos discos duros, mi TS-264 lo tengo como nas de respaldo así que prefiero rendimiento.



En la siguiente pantalla nos aparece la elección de los, en mi caso, nvme:




.png   32.png (Size: 198,26 KB / Downloads: 66)



Mas opciones a configurar a gusto del consumidor:




.png   33.png (Size: 244,9 KB / Downloads: 65)



Opciones reservadas a unos pocos:




.png   34.png (Size: 269,96 KB / Downloads: 66)



Un resumen de lo configurado anteriórmente:




.png   35.png (Size: 209,39 KB / Downloads: 65)



Ultimo aviso:




.png   36.png (Size: 202,88 KB / Downloads: 66)



Hecho:




.png   37.png (Size: 141,71 KB / Downloads: 65)



Creado el Conjunto de Almacenamiento vamos a crear una primera carpeta compartida:




.png   38.png (Size: 696,34 KB / Downloads: 65)



Le pongo un nombre, escojo aprovisionamiento Thick, le asigno un tamaño y, muy importante, le doy a Configuración avanzada:




.png   39.png (Size: 221,11 KB / Downloads: 65)



Para configurar las opciones que aparecen debemos darle a los simbolitos que nos aparecen a la derecha:




.png   40.png (Size: 213,17 KB / Downloads: 65)




.png   41.png (Size: 211,1 KB / Downloads: 67)



En mi caso personal la compresión y la deduplicación las mantengo desactivadas. Respecto al ajuste de Clonación rápida la IA dice lo siguiente:

La clonación rápida en ZFS se logra mediante el uso de instantáneas (snapshots) y la tecnología de copia en escritura (copy-on-write - CoW), permitiendo crear réplicas completas de sistemas de archivos o volúmenes de forma instantánea, sin consumir espacio de almacenamiento adicional al momento de la creación.

Otro ajuste a tener muy en cuenta es el tamaño de bloque, la carpeta compartida que he creado está destinada a libros que son de tamaño pequeño así que lo configuro a tal efecto. Si el contenido que va a tener la carpeta compartida es otro podemos optar por mejores opciones:




.png   42.png (Size: 227,77 KB / Downloads: 67)



Tenemos como opción cifrar la carpeta:




.png   43.png (Size: 223,03 KB / Downloads: 66)



O aplicarle inmutabilidad WORM




.png   44.png (Size: 199,74 KB / Downloads: 64)



El sistema que aplica Qnap de cara a la inmutabilidad está bien pero tiene un problema que consiste en que una vez aplicada no se la podemos quitar hasta que cumpla el plazo que le hayamos configurado. Una opción para resolver lo anterior es aplicar inmutabilidad a una carpeta compartida manuálmente con fecha indefinida con la particularidad de que se la podemos quitar cuando nos apetezca, esto está explicado al final de este post:

https://www.qnapclub.es/showthread.php?tid=5417

Lo siguiente que nos aparece es un resumen de lo configurado anteriórmente:




.png   45.png (Size: 191,17 KB / Downloads: 67)



Hecha las primeras configuraciones vamos a ver otras cosas, una de ellas es la cuenta admin del nas:




.png   46.png (Size: 176,34 KB / Downloads: 66)



Por defecto está desactivada, si la activamos se nos pide ponerle una contraseña nueva.

Una novedad del Hero 6 es la compatibilidad con ACL 2.0 que no viene activada por defecto, se nos invita a hacerlo desde el apartado carpetas compartidas del Panel de Control:




.png   47.png (Size: 268,42 KB / Downloads: 64)



La mejor opción es escoger Actualizar a ACL 2.0




.png   48.png (Size: 277,07 KB / Downloads: 66)



Haciéndolo así todas las carpetas compartidas que se tengan pasan a esa nueva versión:




.png   49.png (Size: 131,13 KB / Downloads: 65)



Hasta aquí mi límite de 50 imágenes, la parte final de este post la pongo a continuación.
Las opciones de las carpetas compartidas son similares a lo que teníamos antes:




.png   50.png (Size: 127,44 KB / Downloads: 62)



La siguiente opción tengo que reconocer que no recuerdo si ya existia antes:




.png   51.png (Size: 298,81 KB / Downloads: 63)



En seguridad también se ven cositas:




.png   52.png (Size: 264,42 KB / Downloads: 60)



Iniciar sesión con QNAP ID




.png   53.png (Size: 283,88 KB / Downloads: 61)



Cifrados diversos para la conexiones SSH, por defecto está configurado en Modo de compatibilidad aunque al acceder a este apartado Qnap nos recomienda cambiarlo a Modo estándar aunque como se puede ver en la imagen siguiente se puede escoger un modo personalizado:




.png   54.png (Size: 227,71 KB / Downloads: 64)



Configuración de QNAP ID en otro sitio:




.png   55.png (Size: 504,5 KB / Downloads: 64)



Cambio de look para la tienda de aplicaciones del nas:




.png   56.png (Size: 399,61 KB / Downloads: 59)



Otra de las novedades del Hero 6 es la posibilidad de utilizar una yubikey para proteger el inicio de sesión al nas, para hacerlo necesitamos instalar una aplicación desde la tienda:




.png   57.png (Size: 550,43 KB / Downloads: 61)



Interfaz de FileStation 6




.png   58.png (Size: 130,75 KB / Downloads: 62)



Con esto voy terminando, antes de hacerlo comento dos cosas, la primera el consumo de ram, sobre esto hay que tener en cuenta un par de cosas, una es que no tengo activada la deduplicación en el nas que es una de las mayores culpables del consumo de ram en ZFS, otra es que en el punto en el que nos encontramos en este tutorial únicamente tengo instaladas las aplicaciones básicas que vienen instaladas " de serie ". Con estas condiciones el consumo de ram en el Hero 6 al poco tiempo de estar instalado es el siguiente:




.png   59.png (Size: 257,47 KB / Downloads: 60)



En mi caso lo siguiente que tengo pendiente de hacer es apagar el nas, volver a conectar físicamente los discos duros, encender el nas y configurar un nuevo Conjunto de Almacenamiento con ellos.

Me gustaría recordaros también que si tenéis un nas con conexiones de red Intel 2.5 es mas que conveniente flashearlas:

https://www.qnapclub.es/showthread.php?tid=5671]]>
Qnap lleva ya bastante tiempo enfocando sus lanzamientos hardware y algunas soluciones software a la gran empresa algo a lo que en principio no habría nada que objetar siempre y cuando no se aplique un olvido al resto de los usuarios. El problema es que a Qnap parece que se le olvida que la base de sus equipos estratosféricos es su sistema operativo y aunque ahora lo intenta remediar parciálmente con este nuevo Hero 6 el reciente pasado confirma ese olvido sin olvidar de que aunque llega tarde tampoco es que lo haga especiálmente bien. Por una parte el año pasado ni QTS ni el Hero recibieron nueva versión mayor algo que hasta la fecha ocurría todos los años, por otro lado se está a punto de lanzar el nuevo Hero 6 mientras que QTS 6 parece que a dia de hoy está en desarrollo sin ni siquiera una primera beta publicada dejando la salida de la versión final para finales de este año 2026 lo cual crea una segregación entre usuarios mindundis versus privilegiados. Pero es que los pretendidos esfuerzos por parte de Qnap de cara a triunfar en la gran empresa se ven enpequeñecidos aplicando en el nuevo Hero 6 ( y lo mismo harán con QTS 6 ) implementaciones rácanas comparándolas con su competencia natural y directa y hasta con la que no es directa como explicaré mas adelante. Actualizar bien y a su debido tiempo no solo permite mantener los equipos estables, seguros y modernizados sino que evita que los usuarios piensen que es mejor dedicar su dinero mirando hacia otro lado sin olvidar que las segregaciones están muy mal vistas a dia de hoy.


El componente principal de un sistema operativo es su kernel y desde hace ya unos años tanto QTS como el Hero han mantenido el mismo kernel, el 5.10.60




.png   0.png (Size: 32,77 KB / Downloads: 67)



El kernel 5.10 LTS tiene fecha de finalización de soporte diciembre de este año así que no le ha quedado otra a Qnap que subir de kernel y lo ha hecho a la versión 6.6.32 también LTS




.png   1.png (Size: 30,9 KB / Downloads: 65)



Y esta es una de muchas de las habituales racanerias de Qnap, han cogido un kernel publicado el 25 de Mayo de 2024 que no tiene mucho sentido cuando además del retraso con sus sistemas operativos se les  " olvida " que a dia de hoy existen dos kernels LTS mas modernos. Teniendo en cuenta que estamos hablando de la versión Hero con ZFS he intentado ver las diferencias entre el Hero 5 - 6 en la implementación de ZFS mediante comandos de consola y no ha habido forma debido a las limitaciones por parte de Qnap para su realización, un secreto que parece que Qnap intenta ocultar ya que es habitual que comuniquen que nuevo kernel implementa las versiones mayores pero no así la versión de ZFS que es otra de las bases del sistema junto al kernel. Aún así es razonable pensar que si aplican esa racatanería al kernel lo harán iguálmente con la versión de OpenZFS.

Las comparaciones son odiosas.... o eso dicen, podría comentar lo anterior con marcas como Ugreen o Terramaster pero lo voy a hacer con la alternativa mas cercana e igualitaria al Hero que no es otra que Truenas, este sistema operativo para nas basado también en ZFS tiene a dia de hoy publicada una beta de su próxima versión mayor ( kernel LTS 6.18.13 - OpenZFS 2.4.1 - Docker 29.0.4 )........ en fin, como digo las comparaciones a veces son odiosas.


Al principio he comentado que este tutorial consiste en explicar como instalar el nuevo Hero 6 a través de una REINICIALIZACION del nas, es decir, como si estuviera recién comprado. Los motivos por los que opto por este sistema en lugar de diréctamente actualizar son los siguientes:

 - Aumento de la versión del kernel linux LTS

 - Probable aumento de la versión de OpenZFS

 - Probable aumento de la versión Debian - Ubuntu de base

 - Desde que salió la primera beta del Hero 6 hasta su versión final van a pasar 5 meses lo cual es un desarrollo bastante largo en el tiempo que dan que 
   pensar que la reforma interna es grande. Por experiencia personal cambios grandes suelen dar problemas a corto o medio plazo por muy bien que se 
   hagan, la única forma de prevenirlos es a través de formateo + instalación limpia.

 - Uno de los motivos que reafirman lo anterior se puede ver en las notas de versión de la Release Candidate, dicen lo siguiente:
    
    Para garantizar la seguridad del sistema, a partir de la versión candidata h6.0.0, QuTS hero ya no se permite la degradación del firmware.

    Es decir, una vez instalado el Hero 6 ya no se permite la vuelta a otra versión anterior.



Os informo que debido a las limitaciones de espacio a la hora de subir imágenes a este foro he tenido que recortar algunas de ellas, lo importante se ve sin problemas, tan sólo se pierde la visualización de botones en la parte de abajo tipo Aplicar - Siguiente. Otra limitación la he tenido en la cantidad de imágenes, se me limita a 50 así que intentaré dividir la explicación en dos partes.


Para hacer la reinicialización nos vamos al apartado correspondiente del Panel de Control de nuestro nas:




.png   2.png (Size: 204,7 KB / Downloads: 65)



Se nos pide la contraseña del nas para proceder:




.png   3.png (Size: 206,09 KB / Downloads: 65)



Escojo la opción de Apagar el nas al terminar la reinicialización:




.png   4.png (Size: 163,31 KB / Downloads: 64)



El motivo por el que apago el nas es para sacar físicamente los discos duros y dejar únicamente los NVME ( el nas es un TS-264 )

Empieza el proceso de reinicialización:




.png   5.png (Size: 218,43 KB / Downloads: 66)



Pasan unos 10 minutos hasta que el nas se apaga. Una vez apagado retiro los discos duros y vuelvo a encender el nas a través de su botón físico, al hacerlo nos aparece la primera pantalla de configuración inicial:




.png   6.png (Size: 635,98 KB / Downloads: 66)



Al tener instalado anteriórmente el Hero 5 no tengo necesidad de darle al botón de Elegir otro firmware, si vosotros estáis en QTS 5 y queréis migrar al Hero si tenéis que darle a ese botón que es el que os permite el cambio de sistema operativo. En mi caso inicio la instalación inteligente y lo que me aparece son las Condiciones de uso que debemos aceptar:




.png   7.png (Size: 785,88 KB / Downloads: 65)



Lo siquiente que aparece son las opciones de firmware:




.png   8.png (Size: 569,29 KB / Downloads: 65)



Tengo descargado en mi ordenador desde la web de Qnap correspondiente a mi nas la RC del Hero 6 así que se lo indico, hecho esto procedo a actualizar.




.png   9.png (Size: 576,41 KB / Downloads: 64)




Os recuerdo que en este punto en el nas no hay nada instalado, lo que se está haciendo es actualizar el firmware alojado en la memoria DOM física del nas, tarda un poco en hacerse:




.png   10.png (Size: 408,36 KB / Downloads: 65)



Una vez actualizada la DOM volvemos a la pantalla inicial de la configuración, como ya hemos escogido anteriórmente el paso al Hero ya no nos aparece cambiar de versión:




.png   11.png (Size: 617,33 KB / Downloads: 67)



Nos obligan otra vez a aceptar las Condiciones del servicio:




.png   12.png (Size: 786,25 KB / Downloads: 65)



Nos vuelve a aparecer también la pantalla de elección de firmware, en este caso ya tenemos instalada la última versión:




.png   13.png (Size: 497,51 KB / Downloads: 65)



Lo siguiente es lo habitual, ponerle nombre al nas + usuario + contraseña:




.png   14.png (Size: 677,41 KB / Downloads: 66)



Escoger zona horaria:




.png   15.png (Size: 695,3 KB / Downloads: 66)



Configuración de red:




.png   16.png (Size: 454,85 KB / Downloads: 66)



Configuración de actualizaciones:




.png   17.png (Size: 620,72 KB / Downloads: 66)



Curiósamente siguen manteniendo la segmentación entre actualizaciones críticas o de calidad algo que nunca han implementado reálmente:




.png   18.png (Size: 602,6 KB / Downloads: 65)



Nos aparece un resumen de lo que acabamos de configurar:




.png   19.png (Size: 753,83 KB / Downloads: 66)



Ultimo aviso:




.png   20.png (Size: 378,92 KB / Downloads: 62)



Empieza el proceso:




.png   21.png (Size: 595,16 KB / Downloads: 67)



Cuando termina aparece un mensaje de error que también me apareció cuando me pasé anteriórmente de QTS al Hero:




.png   22.png (Size: 504,65 KB / Downloads: 64)



En la imagen que acabo de poner no se ve pero en la parte de abajo veréis que tenéis un botón para solucionar ese error, al darle nos aparece lo siguiente:




.png   23.png (Size: 43,39 KB / Downloads: 66)



Ponemos nuestro usuario - contraseña y accedemos a la interfaz del nas, nos aparece de primeras lo siguiente:




.png   24.png (Size: 109,95 KB / Downloads: 64)



Pasado el trámite.......




.png   25.png (Size: 593,33 KB / Downloads: 64)



Automáticamente se nos invita a crear un primer Conjunto de Almacenamiento:




.png   26.png (Size: 566,75 KB / Downloads: 66)



Antes de hacerlo vemos algunas de las opciones disponibles en la configuración, una de ellas es el porcentaje de utilización de la ram ARC que por defecto está en el 55% y que se puede reducir pero NO aumentar:




.png   27.png (Size: 448,87 KB / Downloads: 64)



Otras opciones disponibles son relativas a la monitorización de los discos:




.png   28.png (Size: 450,81 KB / Downloads: 65)



Lo siguiente que voy a hacer es crear un nuevo Conjunto de Almacenamiento pero explico que como novedad en el Hero 6 nos aparece la opción de crear un Conjunto de Almacenamiento Qtier, este sistema de Qnap se basa en que teniendo en el nas almacenamiento SSD - NVME + discos duros el sistema operativo va decidiendo donde se alojan los archivos dependiendo de su utilización, es decir, los que más se utilizan se almacenan en los nvme y los restantes en los discos duros mas lentos.




.png   29.png (Size: 159,1 KB / Downloads: 67)



Como he comentado antes en mi caso opto por crear un Conjunto de Almacenamiento clásico:




.png   30.png (Size: 738,64 KB / Downloads: 65)



En la siguiente pantalla tenemos que escoger si tenemos SSD - NVME ( tanto unos como otros Qnap los cataloga como SSD ) y el tipo de raid:




.png   31.png (Size: 227,46 KB / Downloads: 64)



En mi caso personal tengo una configuración algo especialita, 2 nvme de distinto fabricante y tamaño, opto por un Raid 0 un tipo de raid que aplicaré posteriórmente también a mis dos discos duros, mi TS-264 lo tengo como nas de respaldo así que prefiero rendimiento.



En la siguiente pantalla nos aparece la elección de los, en mi caso, nvme:




.png   32.png (Size: 198,26 KB / Downloads: 66)



Mas opciones a configurar a gusto del consumidor:




.png   33.png (Size: 244,9 KB / Downloads: 65)



Opciones reservadas a unos pocos:




.png   34.png (Size: 269,96 KB / Downloads: 66)



Un resumen de lo configurado anteriórmente:




.png   35.png (Size: 209,39 KB / Downloads: 65)



Ultimo aviso:




.png   36.png (Size: 202,88 KB / Downloads: 66)



Hecho:




.png   37.png (Size: 141,71 KB / Downloads: 65)



Creado el Conjunto de Almacenamiento vamos a crear una primera carpeta compartida:




.png   38.png (Size: 696,34 KB / Downloads: 65)



Le pongo un nombre, escojo aprovisionamiento Thick, le asigno un tamaño y, muy importante, le doy a Configuración avanzada:




.png   39.png (Size: 221,11 KB / Downloads: 65)



Para configurar las opciones que aparecen debemos darle a los simbolitos que nos aparecen a la derecha:




.png   40.png (Size: 213,17 KB / Downloads: 65)




.png   41.png (Size: 211,1 KB / Downloads: 67)



En mi caso personal la compresión y la deduplicación las mantengo desactivadas. Respecto al ajuste de Clonación rápida la IA dice lo siguiente:

La clonación rápida en ZFS se logra mediante el uso de instantáneas (snapshots) y la tecnología de copia en escritura (copy-on-write - CoW), permitiendo crear réplicas completas de sistemas de archivos o volúmenes de forma instantánea, sin consumir espacio de almacenamiento adicional al momento de la creación.

Otro ajuste a tener muy en cuenta es el tamaño de bloque, la carpeta compartida que he creado está destinada a libros que son de tamaño pequeño así que lo configuro a tal efecto. Si el contenido que va a tener la carpeta compartida es otro podemos optar por mejores opciones:




.png   42.png (Size: 227,77 KB / Downloads: 67)



Tenemos como opción cifrar la carpeta:




.png   43.png (Size: 223,03 KB / Downloads: 66)



O aplicarle inmutabilidad WORM




.png   44.png (Size: 199,74 KB / Downloads: 64)



El sistema que aplica Qnap de cara a la inmutabilidad está bien pero tiene un problema que consiste en que una vez aplicada no se la podemos quitar hasta que cumpla el plazo que le hayamos configurado. Una opción para resolver lo anterior es aplicar inmutabilidad a una carpeta compartida manuálmente con fecha indefinida con la particularidad de que se la podemos quitar cuando nos apetezca, esto está explicado al final de este post:

https://www.qnapclub.es/showthread.php?tid=5417

Lo siguiente que nos aparece es un resumen de lo configurado anteriórmente:




.png   45.png (Size: 191,17 KB / Downloads: 67)



Hecha las primeras configuraciones vamos a ver otras cosas, una de ellas es la cuenta admin del nas:




.png   46.png (Size: 176,34 KB / Downloads: 66)



Por defecto está desactivada, si la activamos se nos pide ponerle una contraseña nueva.

Una novedad del Hero 6 es la compatibilidad con ACL 2.0 que no viene activada por defecto, se nos invita a hacerlo desde el apartado carpetas compartidas del Panel de Control:




.png   47.png (Size: 268,42 KB / Downloads: 64)



La mejor opción es escoger Actualizar a ACL 2.0




.png   48.png (Size: 277,07 KB / Downloads: 66)



Haciéndolo así todas las carpetas compartidas que se tengan pasan a esa nueva versión:




.png   49.png (Size: 131,13 KB / Downloads: 65)



Hasta aquí mi límite de 50 imágenes, la parte final de este post la pongo a continuación.
Las opciones de las carpetas compartidas son similares a lo que teníamos antes:




.png   50.png (Size: 127,44 KB / Downloads: 62)



La siguiente opción tengo que reconocer que no recuerdo si ya existia antes:




.png   51.png (Size: 298,81 KB / Downloads: 63)



En seguridad también se ven cositas:




.png   52.png (Size: 264,42 KB / Downloads: 60)



Iniciar sesión con QNAP ID




.png   53.png (Size: 283,88 KB / Downloads: 61)



Cifrados diversos para la conexiones SSH, por defecto está configurado en Modo de compatibilidad aunque al acceder a este apartado Qnap nos recomienda cambiarlo a Modo estándar aunque como se puede ver en la imagen siguiente se puede escoger un modo personalizado:




.png   54.png (Size: 227,71 KB / Downloads: 64)



Configuración de QNAP ID en otro sitio:




.png   55.png (Size: 504,5 KB / Downloads: 64)



Cambio de look para la tienda de aplicaciones del nas:




.png   56.png (Size: 399,61 KB / Downloads: 59)



Otra de las novedades del Hero 6 es la posibilidad de utilizar una yubikey para proteger el inicio de sesión al nas, para hacerlo necesitamos instalar una aplicación desde la tienda:




.png   57.png (Size: 550,43 KB / Downloads: 61)



Interfaz de FileStation 6




.png   58.png (Size: 130,75 KB / Downloads: 62)



Con esto voy terminando, antes de hacerlo comento dos cosas, la primera el consumo de ram, sobre esto hay que tener en cuenta un par de cosas, una es que no tengo activada la deduplicación en el nas que es una de las mayores culpables del consumo de ram en ZFS, otra es que en el punto en el que nos encontramos en este tutorial únicamente tengo instaladas las aplicaciones básicas que vienen instaladas " de serie ". Con estas condiciones el consumo de ram en el Hero 6 al poco tiempo de estar instalado es el siguiente:




.png   59.png (Size: 257,47 KB / Downloads: 60)



En mi caso lo siguiente que tengo pendiente de hacer es apagar el nas, volver a conectar físicamente los discos duros, encender el nas y configurar un nuevo Conjunto de Almacenamiento con ellos.

Me gustaría recordaros también que si tenéis un nas con conexiones de red Intel 2.5 es mas que conveniente flashearlas:

https://www.qnapclub.es/showthread.php?tid=5671]]> <![CDATA[Otro nuevo por aquí]]> https://www.qnapclub.es/showthread.php?tid=5792 Tue, 14 Apr 2026 21:57:55 +0200 Coquenet]]> https://www.qnapclub.es/showthread.php?tid=5792 Tengo un QNAP TS-262-4G con una caja de expansión TR-004
Saludos]]> Tengo un QNAP TS-262-4G con una caja de expansión TR-004
Saludos]]> <![CDATA[RAID TR-004]]> https://www.qnapclub.es/showthread.php?tid=5791 Tue, 14 Apr 2026 12:28:49 +0200 Coquenet]]> https://www.qnapclub.es/showthread.php?tid=5791 Gracias y un saludo]]> Gracias y un saludo]]> <![CDATA[Hola a todos!]]> https://www.qnapclub.es/showthread.php?tid=5790 Wed, 08 Apr 2026 17:32:28 +0200 jogartra]]> https://www.qnapclub.es/showthread.php?tid=5790
Aunque hace ya más de 8 años que tengo el QNAP, todavía no me había registrado en ningún foro de usuarios. Lo he usado  principalmente como repositorio de medios (con Plex) y para copias de seguridad. Ahora me gustaría explorar el mundo de los dockers.

Mi equipo:
• Modelo: QNAP TS-253A
• Procesador: Intel Celeron N3160 (4 núcleos)
• Memoria RAM: 8 GB
• Sistema operativo: QTS 5.2.9.3410

Un saludo a toda la comunidad!

Jose.]]>
Aunque hace ya más de 8 años que tengo el QNAP, todavía no me había registrado en ningún foro de usuarios. Lo he usado  principalmente como repositorio de medios (con Plex) y para copias de seguridad. Ahora me gustaría explorar el mundo de los dockers.

Mi equipo:
• Modelo: QNAP TS-253A
• Procesador: Intel Celeron N3160 (4 núcleos)
• Memoria RAM: 8 GB
• Sistema operativo: QTS 5.2.9.3410

Un saludo a toda la comunidad!

Jose.]]> <![CDATA[Consulta RAM]]> https://www.qnapclub.es/showthread.php?tid=5789 Tue, 07 Apr 2026 14:04:44 +0200 Gwaihir]]> https://www.qnapclub.es/showthread.php?tid=5789
Seguí las instrucciones:
"Cuando instale módulos, asegúrese de lo siguiente: 
• Un módulo se instala en la ranura 1. 
• Los módulos se instalan de dos en dos. Cuando instale dos módulos, utilice las ranuras 1 y 3."

Así que instale 1-3 y 2 y 4.

Pero el otro día no se porque trasteando vi la imagen adjunta y pone instala los módulos iguales en el mismo canal. Y según se puede ver serían 1-2 y 3-4

Con lo cual ya me empezó a dar vueltas la cabeza pero no se como comprobar si está activado o no el dual channel, porque no lo pone en ningún sitio.

Alguna idea???

.png   2026-04-07 14 01 47.png (Size: 23,52 KB / Downloads: 34) ]]>
Seguí las instrucciones:
"Cuando instale módulos, asegúrese de lo siguiente: 
• Un módulo se instala en la ranura 1. 
• Los módulos se instalan de dos en dos. Cuando instale dos módulos, utilice las ranuras 1 y 3."

Así que instale 1-3 y 2 y 4.

Pero el otro día no se porque trasteando vi la imagen adjunta y pone instala los módulos iguales en el mismo canal. Y según se puede ver serían 1-2 y 3-4

Con lo cual ya me empezó a dar vueltas la cabeza pero no se como comprobar si está activado o no el dual channel, porque no lo pone en ningún sitio.

Alguna idea???

.png   2026-04-07 14 01 47.png (Size: 23,52 KB / Downloads: 34) ]]> <![CDATA[Trasladando docker de Joplin con su bbdd postgresql]]> https://www.qnapclub.es/showthread.php?tid=5787 Sun, 05 Apr 2026 13:07:05 +0200 Ganekogorta]]> https://www.qnapclub.es/showthread.php?tid=5787
En este post vamos a tratar de describir como hacer una copia o mover un docker de Joplin que usa como BBDD una postgresql desde una QNAP a otra máquina.

Para ello nos apoyaremos en el gestor de BBDD PgAdmin. 

Los pasos a realizar serán los siguientes:
1-detenemos el docker de Joplin
2-instalacion del docker de postgresql en la máquina nueva
3_1-instalación del docker de PgAdmin en la máquina nueva (opcion 1)
3_2-agregar servidor postgresql de máquina original en PgAdmin de máquina nueva (opcion 1)
4-1-agregar servidor postgresql de máquina nueva en PgAdmin de máquina original (opcion 2)
5-copia de seguridad de la BBDD usando PgAdmin
6-restauración de la BBDD en el nuevo postgresql usando PgAdmin
7-instalación del docker de Joplin en la nueva máquina apuntando a la BBDD restaurada
8-modificaciones de redirecciones en el router o proxy  inverso 

1-detenemos el docker de Joplin

Este punto es importante ya que podemos tener algún cliente externo haciendo modificaciones a los datos de Joplin y por tanto haciéndolos en la BBDD.
La detención la podemos hacer con algun gestor de dockers tipo Portainer,  el bot de Telegram para controlarlos o hacerlo mediante la consola de comandos.

En el siguiente comando de ejemplo el docker de Joplin se llama "joplin" (muy original  Wink )
Code:
docker stop joplin


.jpg   joplin_mover_1.jpg (Size: 3,52 KB / Downloads: 42)


2-instalacion del docker de postgresql en la máquina nueva

Aquí no hay mucho misterio, sólo hemos de lanzar el siguiente comando si fuese de QNAP
Code:
docker run -d --name="postgresql" --restart always -p 5432:5432-e POSTGRES_USER=usuario_admin -e POSTGRES_PASSWORD=clave_usuario -e POSTGRES_DB=postgresql_db -v /share/DockerData/postgresql:/var/lib/postgresql/data postgres:13.8

Como voy a hacerlo en un Terramaster, el código será similar a este otro
Code:
docker run -d --name="postgresql" --restart always -p 5432:5432-e POSTGRES_USER=usuario_admin -e POSTGRES_PASSWORD=clave_usuario -e POSTGRES_DB=postgresql_db -v /Volume1/DockerData/postgresql:/var/lib/postgresql/data postgres:13.8

También nos puede ser interesante indicar la ip del docker si sabemos el rango que va a tener. Esto se haría añadiendo algo como "--ip 10.10.30.2"

En el caso del comando anterior, no hemos puesto como versión de postgresql la "latest" y es que hemos obligado la versión del postgresql a 13.8, pero podemos usar otras, pero hemos de asegurarnos que la versión del docker de Joplin es compatible con la versión de postgresql que instalemos.

También hemos de leer la documentación del docker si usamos otras versiones ya que es posible que nos pida definir otras variables a la hora de crearlo.

3_1-instalación del docker de PgAdmin en la máquina nueva (opcion 1)

Este paso es opcional ya que NO tenemos porque instalar otro PgAdmin en la máquina nueva puesto que ya tenemos uno en la vieja. 
Podemos usar el PgAdmin de la Qnap para gestionar postgresql de otras máquinas de nuestra red.

He puesto este paso ya que creo interesante que si estamos moviendo dockers y BBDD de postgresql a una nueva máquina, es que la vieja va a ser retirada en algún modo y con este paso ya tenemos un nuevo PgAdmin operativo para futuros usos.

Para el despliegue del nuevo docker de PgAdmin usaremos este comando en una Qnap o en una Terramaster (es el mismo  Big Grin )
Code:
docker run -d  -p 9158:80 -p 9157:443 --restart always --name="pgadmin4" -e PGADMIN_DEFAULT_EMAIL=mi_correo_electronico -e PGADMIN_DEFAULT_PASSWORD=clave  dpage/pgadmin4:9.14.0

Los puertos 9158 y 9157 pueden ser otros de nuestra elección.

3_2-agregar servidor postgresql de máquina original en PgAdmin de máquina nueva (opcion 1)

Aquí tras identificarnos en el PgAdmin, hemos de agregar un nuevo servidor de postgresql en su lista.
Para hacerlo podemos hacerlo pulsando sobre cualquiera de las dos opciones de la siguiente imagen

.jpg   joplin_mover_19.jpg (Size: 164,69 KB / Downloads: 36)

Se nos presenta un asistente que completaremos como en las siguiente imágenes

.jpg   joplin_mover_20.jpg (Size: 66,15 KB / Downloads: 42)

ahora rellenamos con los datos de identificación (nombre de la base de datos, usuario y clave que usamos en su día cuando creamos el docker de postgresql)


.jpg   joplin_mover_22.jpg (Size: 65,78 KB / Downloads: 41)

Y tras aceptar, ya tendremos nuestro servidor postgresql de la máquina vieja registrado en el PgAdmin de la máquina nueva.

.jpg   joplin_mover_23.jpg (Size: 20,67 KB / Downloads: 40)

4-1-agregar servidor postgresql de máquina nueva en PgAdmin de máquina original (opcion 2)

De la misma forma, si no quisiéramos instalar el docker de PgAdmin en la nueva máquina, podemos usar el PgAdmin de la vieja para agregar el servidor postgresql de la máquina nueva y de esa forma el PgAdmin de la vieja puede gestionar las BBDD de postgreSQL de la nas vieja y las de la nueva máquina.

El proceso de adicción del nuevo servidor de postgreSQL es casi calcado del del punto anterior.
Nos identificamos en el PgAdmin de la Nas vieja e iniciamos el asistente de añadir un servidor:

.jpg   joplin_mover_24.jpg (Size: 100,63 KB / Downloads: 37)

Suministramos los datos del nuevo servidor de PostgreSQL para registrarlo

.jpg   joplin_mover_25.jpg (Size: 48,42 KB / Downloads: 39)

rellenamos con los datos de ip, usuario, clave y nombre de la base de datos

.jpg   joplin_mover_26.jpg (Size: 43,58 KB / Downloads: 39)

Y con eso, ya tendremos nuestro servidor PostgreSQL de la máquina nueva, registrado en el PgAdmin de la Nas vieja

.jpg   joplin_mover_27.jpg (Size: 39,82 KB / Downloads: 36)
5-copia de seguridad de la BBDD usando PgAdmin

Es muy importante que los docker de Postgresql y PgAdmin estén en la misma red de dockers o en la misma red local. Si no lo hacemos, el docker de PgAdmin no podrá alcanzar al docker de PostgreSQL.

Una vez identificados en PgAdmd y ya teniendo la conexión al servidor PostgreSQL podemos hacer la exportación.

En la siguiente imagen vemos que PgAdmin tiene definidas dos conexiones a dos servidores de PostgreSQL distintos.

.jpg   joplin_mover_2.jpg (Size: 98,46 KB / Downloads: 43)

El ejemplo, el que nos interesa es el llamado "postgressql" y su bbdd "joplin".

Para exportar la BBDD, seleccionamos la bbdd "joplin" y pulsamos botón secundario.
Al hacerlo se nos presenta un menú emergente del que seleccionaremos la opción de "respaldar"

.jpg   joplin_mover_3.jpg (Size: 81,6 KB / Downloads: 41)

Al continuar, empezará el proceso. Si pulsamos a la información durante la acción, podemos en una ventana el comando que se lanza y como va desarrollándose la copia de seguridad. 

.jpg   joplin_mover_4.jpg (Size: 46,76 KB / Downloads: 40)

En esa ventana podemos ver el comando que se lanza en el sistema (pg_dump).
Es conveniente recordar que si lo hacemos las restauraciones a versiones de postgresql distin podemos tener problemas de versión.
Como regla general, la base de datos exportada no dará problemas si lo importamos desde una versión igual o superior.
En el caso de la imagen se ve en la captura el comando "/usr/local/pgsql-16/pg_dump" . Es decir es una versión 16.


.jpg   joplin_mover_5.jpg (Size: 98,52 KB / Downloads: 41)


Nota:
En el caso de que usemos un PgAdmin para exportar y otro PgAdmin para importarlo, tenemos un pequeño inconveniente, y es que la copia ha queda dentro del docker de PgAdmin.
Para poder moverlo al sistema de archivo de la nas, hemos de lanzar un comando que lo copia por ejemplo a la carpeta /Public.
La ruta del archivo dentro del docker es "/var/lib/pgadmin/storage/usuario_pgadmin/" y el archivo será "joplin" (o el nombre que escribimos en las pantallas anteriores).

.jpg   joplin_mover_6.jpg (Size: 12,62 KB / Downloads: 43)

El comando a ejecutar es similar al siguiente.
Code:
docker cp nombre_docker_pgadmin:/var/lib/pgadmin/storage/usuario_pgadmin/joplin /share/Public/joplin

He usado como destino la carpeta Public porque existe en todas las nas de QNAP y así no tenemos pérdida a la hora de recuperarla  Big Grin

Una forma para evitar tener que usar el anterio comando sería si definimos en la cadena de creación del docker PgAdmin una ruta persistente del tipo
"-v /share/DockerData/pgadmin:/var/lib/pgadmib/storage".
Así al hacer la exportación, los archivos quedarían en esa carpeta accesible desde el sistema de archivos de la nas y nos evitaríamos lo del comando "docker cp"  Wink  y podemos copiar a una carpeta de la nas destino para hacer la importación.

6-restauración de la BBDD en el nuevo postgresql usando PgAdmin

Teniendo ya accesible la copia desde el PgAdmin, ahora toca restaurarla.
En función de como y desde donde hicimos la exportación procederemos de forma similar en todos los casos

Vamos al caso fácil, tenemos un PgAdmin con los dos servidores PostgreSQL (nuevo y viejo) conectados y administrados.

Seleccionamos el viejo servidor y hacemos botón secundario para elegir del menú emergente la opción de crear un usuario primero.

.jpg   joplin_mover_8.jpg (Size: 124,74 KB / Downloads: 37)

Lo llamaré igual que en la máquina original "joplin"

.jpg   joplin_mover_9.jpg (Size: 47,1 KB / Downloads: 34)

definimos la contraseña que luego la usaremos en la definición de creación del docker de Joplin.

.jpg   joplin_mover_10.jpg (Size: 57,06 KB / Downloads: 37)

le damos privilegios a ese usuario para que pueda operar con la bbdd

.jpg   joplin_mover_28.jpg (Size: 32,92 KB / Downloads: 35)


Ahora vamos con la creación de la base de datos vacía a la que asignaremos el usuario "joplin".
Seleccionamos de nuevo bases de datos y hacemos botón secundario, del menu emergente seleccionamos "crear", "base de datos" 

.jpg   joplin_mover_7.jpg (Size: 86,35 KB / Downloads: 35)

Y seguimos un asistente para crearla

.jpg   joplin_mover_12.jpg (Size: 46,84 KB / Downloads: 35)

Seleccionamos el usuario "joplin" como dueño

.jpg   joplin_mover_13.jpg (Size: 48,87 KB / Downloads: 38)

En la lengüeta de seguridad le demos los permisos adecuados

.jpg   joplin_mover_14.jpg (Size: 60,87 KB / Downloads: 41)

y ya tendremos creada la base de datos "joplin_db" vacía con un usuario llamado "joplin"

Ahora toca la restauración propiamente dicha haciendo botón secundario sobre la base de datos joplin y elegimos la opción de restaurar


.jpg   joplin_mover_15.jpg (Size: 154,01 KB / Downloads: 33)

Se inicia un asistente donde indicaremos el archivo origen y el tipo de copia

.jpg   joplin_mover_16.jpg (Size: 54,86 KB / Downloads: 35)

especificamos el nombre del archivo de la copia

.jpg   joplin_mover_32.jpg (Size: 68,47 KB / Downloads: 31)

Y tras unos segundos, la copia estará restaurada


7-instalación del docker de Joplin en la nueva máquina apuntando a la BBDD restaurada
Ahora hemos de desplegar el docker de Joplin haciendo que apunte a la nueva BBDD.
En el caso de ejemplo hay definido un archivo con unos parámetros de inicio que se encuentra ubicado en la carpeta persistente de Joplin.
Este archivo ha de ser creado antes de lanzar la cadena de creación del docker.
En nuestro caso está en "/share/DockerData/joplin" para una Qnap, y el una Terramaster estaría en "/Volume1/DockerData/joplin".
Ni que decir tiene que esa carpeta hemos de crearla con los permisos adecuados y dejar en su interior ese archivo ".env"
La forma mas fácil es usar un Winscp y hacer la copia entre ambas máquinas  Big Grin

Con el archivo ".env" ,desde una consola nos situamos en esa carpeta "/Volume1/DockerData/joplin" y lanzamos la cadena de creación del docker

Para una Qnap sería del tipo:
Code:
docker run -d  -p ip_nueva_nas:22300:22300 --restart always --name="joplin" --env-file .env -v /share/DockerData/joplin:/var/lib/postgresql/data -e DB_CLIENT=pg -e POSTGRES_HOST=ip_nueva_nas -e POSTGRES_PORT=5432 -e POSTGRES_DB=joplin -e POSTGRES_USER=usuario_joplin -e POSTGRES_PASSWORD=clave_usuario_joplin  joplin/server:latest

Y para una Terramaster sería del tipo
Code:
docker run -d  -p ip_nueva_nas:22300:22300 --restart always --name="joplin" --env-file .env -v /Volume1/DockerData/joplin:/var/lib/postgresql/data -e DB_CLIENT=pg -e POSTGRES_HOST=ip_nueva_nas -e POSTGRES_PORT=5432 -e POSTGRES_DB=joplin -e POSTGRES_USER=usuario_joplin -e POSTGRES_PASSWORD=clave_usuario_joplin  joplin/server:latest

Con esto ya tendríamos levantado en nuestra red un docker de Joplin que estaría accesible sólo desde equipos locales.

8-modificaciones de redirecciones en el router o proxy  inverso

Si queremos que esté accesible desde el exterior de nuestra red deberemos modificar las reglas de redireccionamiento que hicimos en su día en el router.
Este cambio es sencillo ya que sólo debemos editar la regla y cambiar la ip de la máquina vieja y poner la ip de la nueva. Los puertos se mantienen

Si en nuestra red el acceso a Joplin se hiciese por un proxy inverso tipo Nginx Proxy manager, debemos editar el "proxy host" adecuado y de nuevo con sólo actualizar la ip cambiando la vieja por la nueva tendremos nuestro Joplin accesible desde el exterior para nuestros equipos clientes.

Nota:
Este post se ha hecho en realidad para ver como hemos de proceder para mover un docker y los datos asociados  de su bbdd en postgresql.
Lo podemos aplicar para otros dockers que no sean Joplin  Smile

Para Joplin hay una forma muuucho mas fácil de moverlo ya que el mismo cliente de Joplin pemite hacer una copia de respaldo.
Es decir, que podíamos haber generado un nuevo postgresql y joplin vacíos, luego exportaríamos los datos Joplin con un cliente y desde un cliente  reconfiguramos la conexión al nuevo Joplin y restauraríamos los datos  Tongue
como siempre si veis algún error o errata me lo hacéis llegar por privado para corregirlo]]>
En este post vamos a tratar de describir como hacer una copia o mover un docker de Joplin que usa como BBDD una postgresql desde una QNAP a otra máquina.

Para ello nos apoyaremos en el gestor de BBDD PgAdmin. 

Los pasos a realizar serán los siguientes:
1-detenemos el docker de Joplin
2-instalacion del docker de postgresql en la máquina nueva
3_1-instalación del docker de PgAdmin en la máquina nueva (opcion 1)
3_2-agregar servidor postgresql de máquina original en PgAdmin de máquina nueva (opcion 1)
4-1-agregar servidor postgresql de máquina nueva en PgAdmin de máquina original (opcion 2)
5-copia de seguridad de la BBDD usando PgAdmin
6-restauración de la BBDD en el nuevo postgresql usando PgAdmin
7-instalación del docker de Joplin en la nueva máquina apuntando a la BBDD restaurada
8-modificaciones de redirecciones en el router o proxy  inverso 

1-detenemos el docker de Joplin

Este punto es importante ya que podemos tener algún cliente externo haciendo modificaciones a los datos de Joplin y por tanto haciéndolos en la BBDD.
La detención la podemos hacer con algun gestor de dockers tipo Portainer,  el bot de Telegram para controlarlos o hacerlo mediante la consola de comandos.

En el siguiente comando de ejemplo el docker de Joplin se llama "joplin" (muy original  Wink )
Code:
docker stop joplin


.jpg   joplin_mover_1.jpg (Size: 3,52 KB / Downloads: 42)


2-instalacion del docker de postgresql en la máquina nueva

Aquí no hay mucho misterio, sólo hemos de lanzar el siguiente comando si fuese de QNAP
Code:
docker run -d --name="postgresql" --restart always -p 5432:5432-e POSTGRES_USER=usuario_admin -e POSTGRES_PASSWORD=clave_usuario -e POSTGRES_DB=postgresql_db -v /share/DockerData/postgresql:/var/lib/postgresql/data postgres:13.8

Como voy a hacerlo en un Terramaster, el código será similar a este otro
Code:
docker run -d --name="postgresql" --restart always -p 5432:5432-e POSTGRES_USER=usuario_admin -e POSTGRES_PASSWORD=clave_usuario -e POSTGRES_DB=postgresql_db -v /Volume1/DockerData/postgresql:/var/lib/postgresql/data postgres:13.8

También nos puede ser interesante indicar la ip del docker si sabemos el rango que va a tener. Esto se haría añadiendo algo como "--ip 10.10.30.2"

En el caso del comando anterior, no hemos puesto como versión de postgresql la "latest" y es que hemos obligado la versión del postgresql a 13.8, pero podemos usar otras, pero hemos de asegurarnos que la versión del docker de Joplin es compatible con la versión de postgresql que instalemos.

También hemos de leer la documentación del docker si usamos otras versiones ya que es posible que nos pida definir otras variables a la hora de crearlo.

3_1-instalación del docker de PgAdmin en la máquina nueva (opcion 1)

Este paso es opcional ya que NO tenemos porque instalar otro PgAdmin en la máquina nueva puesto que ya tenemos uno en la vieja. 
Podemos usar el PgAdmin de la Qnap para gestionar postgresql de otras máquinas de nuestra red.

He puesto este paso ya que creo interesante que si estamos moviendo dockers y BBDD de postgresql a una nueva máquina, es que la vieja va a ser retirada en algún modo y con este paso ya tenemos un nuevo PgAdmin operativo para futuros usos.

Para el despliegue del nuevo docker de PgAdmin usaremos este comando en una Qnap o en una Terramaster (es el mismo  Big Grin )
Code:
docker run -d  -p 9158:80 -p 9157:443 --restart always --name="pgadmin4" -e PGADMIN_DEFAULT_EMAIL=mi_correo_electronico -e PGADMIN_DEFAULT_PASSWORD=clave  dpage/pgadmin4:9.14.0

Los puertos 9158 y 9157 pueden ser otros de nuestra elección.

3_2-agregar servidor postgresql de máquina original en PgAdmin de máquina nueva (opcion 1)

Aquí tras identificarnos en el PgAdmin, hemos de agregar un nuevo servidor de postgresql en su lista.
Para hacerlo podemos hacerlo pulsando sobre cualquiera de las dos opciones de la siguiente imagen

.jpg   joplin_mover_19.jpg (Size: 164,69 KB / Downloads: 36)

Se nos presenta un asistente que completaremos como en las siguiente imágenes

.jpg   joplin_mover_20.jpg (Size: 66,15 KB / Downloads: 42)

ahora rellenamos con los datos de identificación (nombre de la base de datos, usuario y clave que usamos en su día cuando creamos el docker de postgresql)


.jpg   joplin_mover_22.jpg (Size: 65,78 KB / Downloads: 41)

Y tras aceptar, ya tendremos nuestro servidor postgresql de la máquina vieja registrado en el PgAdmin de la máquina nueva.

.jpg   joplin_mover_23.jpg (Size: 20,67 KB / Downloads: 40)

4-1-agregar servidor postgresql de máquina nueva en PgAdmin de máquina original (opcion 2)

De la misma forma, si no quisiéramos instalar el docker de PgAdmin en la nueva máquina, podemos usar el PgAdmin de la vieja para agregar el servidor postgresql de la máquina nueva y de esa forma el PgAdmin de la vieja puede gestionar las BBDD de postgreSQL de la nas vieja y las de la nueva máquina.

El proceso de adicción del nuevo servidor de postgreSQL es casi calcado del del punto anterior.
Nos identificamos en el PgAdmin de la Nas vieja e iniciamos el asistente de añadir un servidor:

.jpg   joplin_mover_24.jpg (Size: 100,63 KB / Downloads: 37)

Suministramos los datos del nuevo servidor de PostgreSQL para registrarlo

.jpg   joplin_mover_25.jpg (Size: 48,42 KB / Downloads: 39)

rellenamos con los datos de ip, usuario, clave y nombre de la base de datos

.jpg   joplin_mover_26.jpg (Size: 43,58 KB / Downloads: 39)

Y con eso, ya tendremos nuestro servidor PostgreSQL de la máquina nueva, registrado en el PgAdmin de la Nas vieja

.jpg   joplin_mover_27.jpg (Size: 39,82 KB / Downloads: 36)
5-copia de seguridad de la BBDD usando PgAdmin

Es muy importante que los docker de Postgresql y PgAdmin estén en la misma red de dockers o en la misma red local. Si no lo hacemos, el docker de PgAdmin no podrá alcanzar al docker de PostgreSQL.

Una vez identificados en PgAdmd y ya teniendo la conexión al servidor PostgreSQL podemos hacer la exportación.

En la siguiente imagen vemos que PgAdmin tiene definidas dos conexiones a dos servidores de PostgreSQL distintos.

.jpg   joplin_mover_2.jpg (Size: 98,46 KB / Downloads: 43)

El ejemplo, el que nos interesa es el llamado "postgressql" y su bbdd "joplin".

Para exportar la BBDD, seleccionamos la bbdd "joplin" y pulsamos botón secundario.
Al hacerlo se nos presenta un menú emergente del que seleccionaremos la opción de "respaldar"

.jpg   joplin_mover_3.jpg (Size: 81,6 KB / Downloads: 41)

Al continuar, empezará el proceso. Si pulsamos a la información durante la acción, podemos en una ventana el comando que se lanza y como va desarrollándose la copia de seguridad. 

.jpg   joplin_mover_4.jpg (Size: 46,76 KB / Downloads: 40)

En esa ventana podemos ver el comando que se lanza en el sistema (pg_dump).
Es conveniente recordar que si lo hacemos las restauraciones a versiones de postgresql distin podemos tener problemas de versión.
Como regla general, la base de datos exportada no dará problemas si lo importamos desde una versión igual o superior.
En el caso de la imagen se ve en la captura el comando "/usr/local/pgsql-16/pg_dump" . Es decir es una versión 16.


.jpg   joplin_mover_5.jpg (Size: 98,52 KB / Downloads: 41)


Nota:
En el caso de que usemos un PgAdmin para exportar y otro PgAdmin para importarlo, tenemos un pequeño inconveniente, y es que la copia ha queda dentro del docker de PgAdmin.
Para poder moverlo al sistema de archivo de la nas, hemos de lanzar un comando que lo copia por ejemplo a la carpeta /Public.
La ruta del archivo dentro del docker es "/var/lib/pgadmin/storage/usuario_pgadmin/" y el archivo será "joplin" (o el nombre que escribimos en las pantallas anteriores).

.jpg   joplin_mover_6.jpg (Size: 12,62 KB / Downloads: 43)

El comando a ejecutar es similar al siguiente.
Code:
docker cp nombre_docker_pgadmin:/var/lib/pgadmin/storage/usuario_pgadmin/joplin /share/Public/joplin

He usado como destino la carpeta Public porque existe en todas las nas de QNAP y así no tenemos pérdida a la hora de recuperarla  Big Grin

Una forma para evitar tener que usar el anterio comando sería si definimos en la cadena de creación del docker PgAdmin una ruta persistente del tipo
"-v /share/DockerData/pgadmin:/var/lib/pgadmib/storage".
Así al hacer la exportación, los archivos quedarían en esa carpeta accesible desde el sistema de archivos de la nas y nos evitaríamos lo del comando "docker cp"  Wink  y podemos copiar a una carpeta de la nas destino para hacer la importación.

6-restauración de la BBDD en el nuevo postgresql usando PgAdmin

Teniendo ya accesible la copia desde el PgAdmin, ahora toca restaurarla.
En función de como y desde donde hicimos la exportación procederemos de forma similar en todos los casos

Vamos al caso fácil, tenemos un PgAdmin con los dos servidores PostgreSQL (nuevo y viejo) conectados y administrados.

Seleccionamos el viejo servidor y hacemos botón secundario para elegir del menú emergente la opción de crear un usuario primero.

.jpg   joplin_mover_8.jpg (Size: 124,74 KB / Downloads: 37)

Lo llamaré igual que en la máquina original "joplin"

.jpg   joplin_mover_9.jpg (Size: 47,1 KB / Downloads: 34)

definimos la contraseña que luego la usaremos en la definición de creación del docker de Joplin.

.jpg   joplin_mover_10.jpg (Size: 57,06 KB / Downloads: 37)

le damos privilegios a ese usuario para que pueda operar con la bbdd

.jpg   joplin_mover_28.jpg (Size: 32,92 KB / Downloads: 35)


Ahora vamos con la creación de la base de datos vacía a la que asignaremos el usuario "joplin".
Seleccionamos de nuevo bases de datos y hacemos botón secundario, del menu emergente seleccionamos "crear", "base de datos" 

.jpg   joplin_mover_7.jpg (Size: 86,35 KB / Downloads: 35)

Y seguimos un asistente para crearla

.jpg   joplin_mover_12.jpg (Size: 46,84 KB / Downloads: 35)

Seleccionamos el usuario "joplin" como dueño

.jpg   joplin_mover_13.jpg (Size: 48,87 KB / Downloads: 38)

En la lengüeta de seguridad le demos los permisos adecuados

.jpg   joplin_mover_14.jpg (Size: 60,87 KB / Downloads: 41)

y ya tendremos creada la base de datos "joplin_db" vacía con un usuario llamado "joplin"

Ahora toca la restauración propiamente dicha haciendo botón secundario sobre la base de datos joplin y elegimos la opción de restaurar


.jpg   joplin_mover_15.jpg (Size: 154,01 KB / Downloads: 33)

Se inicia un asistente donde indicaremos el archivo origen y el tipo de copia

.jpg   joplin_mover_16.jpg (Size: 54,86 KB / Downloads: 35)

especificamos el nombre del archivo de la copia

.jpg   joplin_mover_32.jpg (Size: 68,47 KB / Downloads: 31)

Y tras unos segundos, la copia estará restaurada


7-instalación del docker de Joplin en la nueva máquina apuntando a la BBDD restaurada
Ahora hemos de desplegar el docker de Joplin haciendo que apunte a la nueva BBDD.
En el caso de ejemplo hay definido un archivo con unos parámetros de inicio que se encuentra ubicado en la carpeta persistente de Joplin.
Este archivo ha de ser creado antes de lanzar la cadena de creación del docker.
En nuestro caso está en "/share/DockerData/joplin" para una Qnap, y el una Terramaster estaría en "/Volume1/DockerData/joplin".
Ni que decir tiene que esa carpeta hemos de crearla con los permisos adecuados y dejar en su interior ese archivo ".env"
La forma mas fácil es usar un Winscp y hacer la copia entre ambas máquinas  Big Grin

Con el archivo ".env" ,desde una consola nos situamos en esa carpeta "/Volume1/DockerData/joplin" y lanzamos la cadena de creación del docker

Para una Qnap sería del tipo:
Code:
docker run -d  -p ip_nueva_nas:22300:22300 --restart always --name="joplin" --env-file .env -v /share/DockerData/joplin:/var/lib/postgresql/data -e DB_CLIENT=pg -e POSTGRES_HOST=ip_nueva_nas -e POSTGRES_PORT=5432 -e POSTGRES_DB=joplin -e POSTGRES_USER=usuario_joplin -e POSTGRES_PASSWORD=clave_usuario_joplin  joplin/server:latest

Y para una Terramaster sería del tipo
Code:
docker run -d  -p ip_nueva_nas:22300:22300 --restart always --name="joplin" --env-file .env -v /Volume1/DockerData/joplin:/var/lib/postgresql/data -e DB_CLIENT=pg -e POSTGRES_HOST=ip_nueva_nas -e POSTGRES_PORT=5432 -e POSTGRES_DB=joplin -e POSTGRES_USER=usuario_joplin -e POSTGRES_PASSWORD=clave_usuario_joplin  joplin/server:latest

Con esto ya tendríamos levantado en nuestra red un docker de Joplin que estaría accesible sólo desde equipos locales.

8-modificaciones de redirecciones en el router o proxy  inverso

Si queremos que esté accesible desde el exterior de nuestra red deberemos modificar las reglas de redireccionamiento que hicimos en su día en el router.
Este cambio es sencillo ya que sólo debemos editar la regla y cambiar la ip de la máquina vieja y poner la ip de la nueva. Los puertos se mantienen

Si en nuestra red el acceso a Joplin se hiciese por un proxy inverso tipo Nginx Proxy manager, debemos editar el "proxy host" adecuado y de nuevo con sólo actualizar la ip cambiando la vieja por la nueva tendremos nuestro Joplin accesible desde el exterior para nuestros equipos clientes.

Nota:
Este post se ha hecho en realidad para ver como hemos de proceder para mover un docker y los datos asociados  de su bbdd en postgresql.
Lo podemos aplicar para otros dockers que no sean Joplin  Smile

Para Joplin hay una forma muuucho mas fácil de moverlo ya que el mismo cliente de Joplin pemite hacer una copia de respaldo.
Es decir, que podíamos haber generado un nuevo postgresql y joplin vacíos, luego exportaríamos los datos Joplin con un cliente y desde un cliente  reconfiguramos la conexión al nuevo Joplin y restauraríamos los datos  Tongue
como siempre si veis algún error o errata me lo hacéis llegar por privado para corregirlo]]> <![CDATA[Traslado de un docker Nginx Proxy Manager con MariaDB a NAS de Terramaster]]> https://www.qnapclub.es/showthread.php?tid=5773 Sun, 29 Mar 2026 22:53:23 +0200 Ganekogorta]]> https://www.qnapclub.es/showthread.php?tid=5773
Voy a tratar de describir como trasladar un docker de Nginx Proxy Manager que usa MariaDB a otra máquina.
A la inversa sería muy similar ya que a fin de cuentas estamos trasladando dockers

El este caso lo voy a hacer a una NAS que no es de Qnap.

Lo que quiero que se vea que el traslado de dockers es "casi" independiente del tipo de Nas o máquina empleada.

Los pasos generales serían los siguientes:
1-backup de la base de datos de MariaDB con PhpMyAdmin desde la máquina QNAP.
2-activacion de MariaDB en la máquina destino si es que no lo tiene instalado.
3-restauracion de la base de datos.
4-despliegue del docker adaptándolo rutas a las de la máquina nueva.
5-cambios en nuestro router para que los puertos 443 y 80 externos a nuestra red, lleguen al nuevo docker de Nginx.


1-backup de la base de datos de MariaDB con PhpMyAdmin

Abrimos la aplicación web PhpMyAdmin.
Dependiendo de nuestra instalación podemos tener instalada en nuestra nas la BBDD en MariaDB 5, MariaDB10 o incluso tener las dos simultáneamente.

Lanzamos PhPMyAdmin

.jpg   nginxl_mover_1.jpg (Size: 5,67 KB / Downloads: 61)

Abrimos sesión en la que tenga la BBDD de nuestro Nginx Proxy Manager

.jpg   nginxl_mover_11.jpg (Size: 24,81 KB / Downloads: 57)

En el caso de la imagen se puede observar que puedo seleccionar otros servidores de MariaDB. 
Estos servidores NO tiene porque ser de la máquina que hospeda PhpMyAdmin, pueden ser incluso los de otras máquinas.

Lo normal es que sólo tengamos uno y nos permita sólo abrir el que tengamos.
Una vez identificados en PhPMyAdmin veremos la lista de bases de datos que tenemos instaladas.
En nuestro caso la que nos interesa es la de nginx (que se definió durante la creación y arranque del docker de Nginx Proxy Manager)


.jpg   nginxl_mover_3.jpg (Size: 36,54 KB / Downloads: 54)

Seleccionamos la base de datos y vamos a lengüeta de exportar

.jpg   nginxl_mover_4.jpg (Size: 61,23 KB / Downloads: 52)

dejamos el formato SQL y pulsamos en el botón de "Exportar"

Nos generará un archivo con extensión .sql que usaremos mas adelante.

2-activacion de MariaDB en la máquina destino si es que no lo tiene instalado

En este caso voy a trasladarlo a otra nas pero de marca distinta a Qnap, usaré un Terramaster, pero podia haber sido un PC, una UGreen, Synology,... u otra Qnap.

En el caso de Terramaster, no se incluye de serie el gestor PhPMyAdmin.
Viene uno llamado simplemente MariaDB

.jpg   nginxl_mover_6.jpg (Size: 2,74 KB / Downloads: 61)

Que si lo abrimos es Hydra para Adminer. 
Este Adminer es un buen gestor web de BBDD similar a PhPMyAdmin que podemos instalar también en nuestra QNAP 

.jpg   nginxl_mover_5.jpg (Size: 34,41 KB / Downloads: 59)

Si alguno lo quiere instalar en su QNAP que lance el siguiente comando en la consola para instalar Adminer como Docker usando el puerto 9080
Code:
docker run -d --name=adminer -p 9080:8080 -e ADMINER_DESIGN='price' --restart unless-stopped -e ADMINER_DEFAULT_SERVER=mysql adminer

Pero para hacerlo mas "sencilo" y homogéneo usaremos PhPMyAdmin.

Para ello tenemos dos opciones: 
  • instalamos PhPMYAdmin en la Terramaster
  • hacemos que nuestra PHPMyAdmin instalala en la QNAP pueda gestionar la MariaDB de la Terramaster

Y en mi caso instalé PhpMyAdmin desde el centro de aplicaciones de la Terramaster

.jpg   nginxl_mover_7.jpg (Size: 37,87 KB / Downloads: 61)

Si queremos usarlo desde la QNAP, hemos de editar (con cuidado) el archivo de configuración de PhpMyAdmin "config.inc.php"
En este otro post ya se comentó como hacer este tipo de configuración.

Por ejemplo deberíamos añadir algo "similar"  a esto en el archivo "config.inc.php" si nuestra Terramaster tuviese la ip 192.168.88.88
Code:
/**
* servidor externo
*/
$i++;
/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['verbose'] = 'Terramaster';
/* Server parameters */
$cfg['Servers'][$i]['host'] = '192.168.88.88';
$cfg['Servers'][$i]['Connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;
/**
* End of servers configuration
*/

Una vez que tengamos nuestro PhpMyAdmin con acceso a la Terramaster.
Deberemos crear la BBDD vacía con el mismo nombre y el mismo nombre usuario y privilegios sobre esa BBDD que usamos en nuestra QNAP.

.jpg   nginxl_mover_8.jpg (Size: 121,15 KB / Downloads: 58)

Ahora creamos al usuario y usamos la misma clave que se usó en QNAP (si los cambiamos lo haremos también en la creación del docker)
Para crear al usuario lo haremos estando dentro de la base de datos Nginx_db y vamos a la lengüeta de 

.jpg   nginxl_mover_12.jpg (Size: 96,78 KB / Downloads: 54)

y tras pulsar al botón de "Go" se crea el usuario con permisos sólo en esa BBDD

.jpg   nginxl_mover_13.jpg (Size: 156,27 KB / Downloads: 55)

tal como muestra la siguiente pantalla de resumen

.jpg   nginxl_mover_14.jpg (Size: 79,04 KB / Downloads: 52)


3-restauracion de la base de datos.

Ahora teniendo seleccionada la BBDD "nginx_db" abrimos la legüeta de importar

.jpg   nginxl_mover_9.jpg (Size: 107,93 KB / Downloads: 57)

Seleccionamos el archivo sql que generamos en el punto 1 y pulsamos al botón inferior de importar.
Si todo ha ido bien, veremos la estructura y datos que teníamos en nuestra QNAP.

.jpg   nginxl_mover_10.jpg (Size: 42,56 KB / Downloads: 58)

En la parte de la derecha podemos ver el número de registros que contiene cada tabla.
4-despliegue del docker adaptándolo rutas a las de la máquina nueva.

Ahora lanzamos la cadena de creación del docker.
Cuando se hizo en la QNAP se lanzó con este comando
Code:
docker run -d -p 2080:80 -p 2081:81 -p 2443:443 --restart always --name="nginx" -v /share/DockerData/nginx/data:/data/ -v /share/DockerData/nginx/letsencrypt:/etc/letsencrypt/  -e "DB_MYSQL_HOST=ip_de_nuestra_nas" -e "DB_MYSQL_PORT=3307" -e "DB_MYSQL_USER=usernginx" -e "DB_MYSQL_PASSWORD=claveusernginx" -e "DB_MYSQL_NAME=nginx_db" -e "DISABLE_IPV6=true" jc21/nginx-proxy-manager:latest

Para lanzarlo en Terramaster, debemos adaptar las rutas persistentes al sistema de carpetas de Terramaster
Code:
docker run -d -p 2080:80 -p 2081:81 -p 2443:443 --restart always --name="nginx" -v /Volume1/DockerData/nginx/data:/data/ -v /Volume1/DockerData/nginx/letsencrypt:/etc/letsencrypt/  -e "DB_MYSQL_HOST=ip_de_nuestra_nas" -e "DB_MYSQL_PORT=3306" -e "DB_MYSQL_USER=usernginx" -e "DB_MYSQL_PASSWORD=claveusernginx" -e "DB_MYSQL_NAME=nginx_db" -e "DISABLE_IPV6=true" jc21/nginx-proxy-manager:latest

En en caso de la Terramaster, su estructura de archivos no es igual en cuanto a rutas de carpetas compartidas y hay que recordar que tenemos alguna usada como persistente en la definición del docker.
En vez de estar en "/share/" como en QNAP, se ubican en "/VolumeXX/"

También he cambiado el puerto usado por la MariaDB de 3307 en la Qnap al habitual 3306 en la Terramaster. Esto es así ya que en la Qnap teníamos dos MariaDB. La version 5 y la 10, que usaban el 3306 y 3307 respectivamente.

Si todo ha ido bien, abriremos un navegador web y escribiremos "https://ip_nas_terramaster:2081" y se nos presentará la web de gestión de Nginx Proxy Manager.
Introducimos el mismo usuario y clave que usabamos en nuestra anterior Qnap y veremos el mismo contenido que tenemos en la anterio nas.

.jpg   nginxl_mover_15.jpg (Size: 31,83 KB / Downloads: 48)

5-cambios en nuestro router para que los puertos 443 y 80 externos a nuestra red, lleguen al nuevo docker de Nginx.

Ahora, para activarlo, sólo debemos editar las reglas de nuestro cortafuegos para que los puertos 80 y 443 externos, en vez de ser redirigidos a la ip de la QNAP, lo sean al de la Terramaster.

Evidentemente este tipo de traslados tiene sentido cuando hay muchas configuraciones dentro de nuestro nginx que son tediosas de repetir en uno nuevo.
También puede ser útil el hacerlo simplemente para tener una replica de uno por si cayese la máquina que lo aloja y con iniciarlo y reconfigurar las dos reglas del router ya tendríamos de nuevo operativo uno.

Y con esto hemos finalizado.


Si veis alguna errata comentadme por privado para corregirla.]]>
Voy a tratar de describir como trasladar un docker de Nginx Proxy Manager que usa MariaDB a otra máquina.
A la inversa sería muy similar ya que a fin de cuentas estamos trasladando dockers

El este caso lo voy a hacer a una NAS que no es de Qnap.

Lo que quiero que se vea que el traslado de dockers es "casi" independiente del tipo de Nas o máquina empleada.

Los pasos generales serían los siguientes:
1-backup de la base de datos de MariaDB con PhpMyAdmin desde la máquina QNAP.
2-activacion de MariaDB en la máquina destino si es que no lo tiene instalado.
3-restauracion de la base de datos.
4-despliegue del docker adaptándolo rutas a las de la máquina nueva.
5-cambios en nuestro router para que los puertos 443 y 80 externos a nuestra red, lleguen al nuevo docker de Nginx.


1-backup de la base de datos de MariaDB con PhpMyAdmin

Abrimos la aplicación web PhpMyAdmin.
Dependiendo de nuestra instalación podemos tener instalada en nuestra nas la BBDD en MariaDB 5, MariaDB10 o incluso tener las dos simultáneamente.

Lanzamos PhPMyAdmin

.jpg   nginxl_mover_1.jpg (Size: 5,67 KB / Downloads: 61)

Abrimos sesión en la que tenga la BBDD de nuestro Nginx Proxy Manager

.jpg   nginxl_mover_11.jpg (Size: 24,81 KB / Downloads: 57)

En el caso de la imagen se puede observar que puedo seleccionar otros servidores de MariaDB. 
Estos servidores NO tiene porque ser de la máquina que hospeda PhpMyAdmin, pueden ser incluso los de otras máquinas.

Lo normal es que sólo tengamos uno y nos permita sólo abrir el que tengamos.
Una vez identificados en PhPMyAdmin veremos la lista de bases de datos que tenemos instaladas.
En nuestro caso la que nos interesa es la de nginx (que se definió durante la creación y arranque del docker de Nginx Proxy Manager)


.jpg   nginxl_mover_3.jpg (Size: 36,54 KB / Downloads: 54)

Seleccionamos la base de datos y vamos a lengüeta de exportar

.jpg   nginxl_mover_4.jpg (Size: 61,23 KB / Downloads: 52)

dejamos el formato SQL y pulsamos en el botón de "Exportar"

Nos generará un archivo con extensión .sql que usaremos mas adelante.

2-activacion de MariaDB en la máquina destino si es que no lo tiene instalado

En este caso voy a trasladarlo a otra nas pero de marca distinta a Qnap, usaré un Terramaster, pero podia haber sido un PC, una UGreen, Synology,... u otra Qnap.

En el caso de Terramaster, no se incluye de serie el gestor PhPMyAdmin.
Viene uno llamado simplemente MariaDB

.jpg   nginxl_mover_6.jpg (Size: 2,74 KB / Downloads: 61)

Que si lo abrimos es Hydra para Adminer. 
Este Adminer es un buen gestor web de BBDD similar a PhPMyAdmin que podemos instalar también en nuestra QNAP 

.jpg   nginxl_mover_5.jpg (Size: 34,41 KB / Downloads: 59)

Si alguno lo quiere instalar en su QNAP que lance el siguiente comando en la consola para instalar Adminer como Docker usando el puerto 9080
Code:
docker run -d --name=adminer -p 9080:8080 -e ADMINER_DESIGN='price' --restart unless-stopped -e ADMINER_DEFAULT_SERVER=mysql adminer

Pero para hacerlo mas "sencilo" y homogéneo usaremos PhPMyAdmin.

Para ello tenemos dos opciones: 
  • instalamos PhPMYAdmin en la Terramaster
  • hacemos que nuestra PHPMyAdmin instalala en la QNAP pueda gestionar la MariaDB de la Terramaster

Y en mi caso instalé PhpMyAdmin desde el centro de aplicaciones de la Terramaster

.jpg   nginxl_mover_7.jpg (Size: 37,87 KB / Downloads: 61)

Si queremos usarlo desde la QNAP, hemos de editar (con cuidado) el archivo de configuración de PhpMyAdmin "config.inc.php"
En este otro post ya se comentó como hacer este tipo de configuración.

Por ejemplo deberíamos añadir algo "similar"  a esto en el archivo "config.inc.php" si nuestra Terramaster tuviese la ip 192.168.88.88
Code:
/**
* servidor externo
*/
$i++;
/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = 'cookie';
$cfg['Servers'][$i]['verbose'] = 'Terramaster';
/* Server parameters */
$cfg['Servers'][$i]['host'] = '192.168.88.88';
$cfg['Servers'][$i]['Connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;
/**
* End of servers configuration
*/

Una vez que tengamos nuestro PhpMyAdmin con acceso a la Terramaster.
Deberemos crear la BBDD vacía con el mismo nombre y el mismo nombre usuario y privilegios sobre esa BBDD que usamos en nuestra QNAP.

.jpg   nginxl_mover_8.jpg (Size: 121,15 KB / Downloads: 58)

Ahora creamos al usuario y usamos la misma clave que se usó en QNAP (si los cambiamos lo haremos también en la creación del docker)
Para crear al usuario lo haremos estando dentro de la base de datos Nginx_db y vamos a la lengüeta de 

.jpg   nginxl_mover_12.jpg (Size: 96,78 KB / Downloads: 54)

y tras pulsar al botón de "Go" se crea el usuario con permisos sólo en esa BBDD

.jpg   nginxl_mover_13.jpg (Size: 156,27 KB / Downloads: 55)

tal como muestra la siguiente pantalla de resumen

.jpg   nginxl_mover_14.jpg (Size: 79,04 KB / Downloads: 52)


3-restauracion de la base de datos.

Ahora teniendo seleccionada la BBDD "nginx_db" abrimos la legüeta de importar

.jpg   nginxl_mover_9.jpg (Size: 107,93 KB / Downloads: 57)

Seleccionamos el archivo sql que generamos en el punto 1 y pulsamos al botón inferior de importar.
Si todo ha ido bien, veremos la estructura y datos que teníamos en nuestra QNAP.

.jpg   nginxl_mover_10.jpg (Size: 42,56 KB / Downloads: 58)

En la parte de la derecha podemos ver el número de registros que contiene cada tabla.
4-despliegue del docker adaptándolo rutas a las de la máquina nueva.

Ahora lanzamos la cadena de creación del docker.
Cuando se hizo en la QNAP se lanzó con este comando
Code:
docker run -d -p 2080:80 -p 2081:81 -p 2443:443 --restart always --name="nginx" -v /share/DockerData/nginx/data:/data/ -v /share/DockerData/nginx/letsencrypt:/etc/letsencrypt/  -e "DB_MYSQL_HOST=ip_de_nuestra_nas" -e "DB_MYSQL_PORT=3307" -e "DB_MYSQL_USER=usernginx" -e "DB_MYSQL_PASSWORD=claveusernginx" -e "DB_MYSQL_NAME=nginx_db" -e "DISABLE_IPV6=true" jc21/nginx-proxy-manager:latest

Para lanzarlo en Terramaster, debemos adaptar las rutas persistentes al sistema de carpetas de Terramaster
Code:
docker run -d -p 2080:80 -p 2081:81 -p 2443:443 --restart always --name="nginx" -v /Volume1/DockerData/nginx/data:/data/ -v /Volume1/DockerData/nginx/letsencrypt:/etc/letsencrypt/  -e "DB_MYSQL_HOST=ip_de_nuestra_nas" -e "DB_MYSQL_PORT=3306" -e "DB_MYSQL_USER=usernginx" -e "DB_MYSQL_PASSWORD=claveusernginx" -e "DB_MYSQL_NAME=nginx_db" -e "DISABLE_IPV6=true" jc21/nginx-proxy-manager:latest

En en caso de la Terramaster, su estructura de archivos no es igual en cuanto a rutas de carpetas compartidas y hay que recordar que tenemos alguna usada como persistente en la definición del docker.
En vez de estar en "/share/" como en QNAP, se ubican en "/VolumeXX/"

También he cambiado el puerto usado por la MariaDB de 3307 en la Qnap al habitual 3306 en la Terramaster. Esto es así ya que en la Qnap teníamos dos MariaDB. La version 5 y la 10, que usaban el 3306 y 3307 respectivamente.

Si todo ha ido bien, abriremos un navegador web y escribiremos "https://ip_nas_terramaster:2081" y se nos presentará la web de gestión de Nginx Proxy Manager.
Introducimos el mismo usuario y clave que usabamos en nuestra anterior Qnap y veremos el mismo contenido que tenemos en la anterio nas.

.jpg   nginxl_mover_15.jpg (Size: 31,83 KB / Downloads: 48)

5-cambios en nuestro router para que los puertos 443 y 80 externos a nuestra red, lleguen al nuevo docker de Nginx.

Ahora, para activarlo, sólo debemos editar las reglas de nuestro cortafuegos para que los puertos 80 y 443 externos, en vez de ser redirigidos a la ip de la QNAP, lo sean al de la Terramaster.

Evidentemente este tipo de traslados tiene sentido cuando hay muchas configuraciones dentro de nuestro nginx que son tediosas de repetir en uno nuevo.
También puede ser útil el hacerlo simplemente para tener una replica de uno por si cayese la máquina que lo aloja y con iniciarlo y reconfigurar las dos reglas del router ya tendríamos de nuevo operativo uno.

Y con esto hemos finalizado.


Si veis alguna errata comentadme por privado para corregirla.]]> <![CDATA[Received control message: AUTH_FAILED]]> https://www.qnapclub.es/showthread.php?tid=5763 Tue, 17 Mar 2026 16:08:19 +0100 marsoni_sistemas]]> https://www.qnapclub.es/showthread.php?tid=5763
Tue Mar 17 16:01:03 2026 AUTH: Received control message: AUTH_FAILED
Tue Mar 17 16:01:03 2026 SIGUSR1[soft,auth-failure] received, process restarting


reinicio el qnap y funciona otra vez durante unas horas]]>
Tue Mar 17 16:01:03 2026 AUTH: Received control message: AUTH_FAILED
Tue Mar 17 16:01:03 2026 SIGUSR1[soft,auth-failure] received, process restarting


reinicio el qnap y funciona otra vez durante unas horas]]> <![CDATA[buenos dias]]> https://www.qnapclub.es/showthread.php?tid=5762 Tue, 17 Mar 2026 16:03:46 +0100 marsoni_sistemas]]> https://www.qnapclub.es/showthread.php?tid=5762