Buenos dias a todos nuevamente, llevo años en el foro pero por distintos motivos, llevaba sin pasarme por aquí varios años, así que me considero como recien ingresado, espero, ahora que todo está normalizado, poder ser mas activo en el foro y aprender de él.
Gracias a los administradores por ese trabajo que realizan y un saludo al resto.
En este tutorial voy a tratar de explicar como instalar el nuevo QuTS Hero 6 que va a ser iguálmente válido tanto para los que tengáis un nas con el Hero versión 5xx como para los que estéis en QTS 5 y decidáis dar el paso de migrar al Hero. La versión que voy a instalar es la Release Candidate del Hero 6 que aunque no es la versión final se le acerca mucho. Asimismo explicaré las novedades mas importantes que trae y una vez instalado explicaré también las primeras configuraciones a realizar. La instalación la voy a hacer a través de una REINICIALIZACION del nas que implica la pérdida de los datos alojados en el nas con lo cual es de obligado cumplimiento realizar antes copia externa de los datos que se tengan, sabiendo esto comentaré los motivos por los que opto por una reinicialización del nas en lugar de diréctamente actualizar. Antes de empezar voy a hacer una introducción explicando lo que tenemos entre las manos y los motivos por los que se ha llegado a este punto:
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
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
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:
Se nos pide la contraseña del nas para proceder:
Escojo la opción de Apagar el nas al terminar la reinicialización:
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:
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:
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:
Lo siquiente que aparece son las opciones de firmware:
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.
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:
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:
Nos obligan otra vez a aceptar las Condiciones del servicio:
Nos vuelve a aparecer también la pantalla de elección de firmware, en este caso ya tenemos instalada la última versión:
Lo siguiente es lo habitual, ponerle nombre al nas + usuario + contraseña:
Escoger zona horaria:
Configuración de red:
Configuración de actualizaciones:
Curiósamente siguen manteniendo la segmentación entre actualizaciones críticas o de calidad algo que nunca han implementado reálmente:
Nos aparece un resumen de lo que acabamos de configurar:
Ultimo aviso:
Empieza el proceso:
Cuando termina aparece un mensaje de error que también me apareció cuando me pasé anteriórmente de QTS al Hero:
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:
Ponemos nuestro usuario - contraseña y accedemos a la interfaz del nas, nos aparece de primeras lo siguiente:
Pasado el trámite.......
Automáticamente se nos invita a crear un primer Conjunto de Almacenamiento:
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:
Otras opciones disponibles son relativas a la monitorización de los discos:
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.
Como he comentado antes en mi caso opto por crear un Conjunto de Almacenamiento clásico:
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:
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:
Mas opciones a configurar a gusto del consumidor:
Opciones reservadas a unos pocos:
Un resumen de lo configurado anteriórmente:
Ultimo aviso:
Hecho:
Creado el Conjunto de Almacenamiento vamos a crear una primera carpeta compartida:
Le pongo un nombre, escojo aprovisionamiento Thick, le asigno un tamaño y, muy importante, le doy a Configuración avanzada:
Para configurar las opciones que aparecen debemos darle a los simbolitos que nos aparecen a la derecha:
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:
Tenemos como opción cifrar la carpeta:
O aplicarle inmutabilidad WORM
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:
Lo siguiente que nos aparece es un resumen de lo configurado anteriórmente:
Hecha las primeras configuraciones vamos a ver otras cosas, una de ellas es la cuenta admin del nas:
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:
La mejor opción es escoger Actualizar a ACL 2.0
Haciéndolo así todas las carpetas compartidas que se tengan pasan a esa nueva versión:
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:
La siguiente opción tengo que reconocer que no recuerdo si ya existia antes:
En seguridad también se ven cositas:
Iniciar sesión con QNAP ID
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:
Configuración de QNAP ID en otro sitio:
Cambio de look para la tienda de aplicaciones del nas:
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:
Interfaz de FileStation 6
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:
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:
Buenas tengo un NAS con una caja de expansión TR-004 con un RAID de 3 discos y me queda una posición libre. Quisiera saber antes de comprar otro disco si lo puedo utilizar fuera del RAID y que sea un disco independiente del RAID no me queda del todo claro en las especificaciones.
Gracias y un saludo
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.
tengo un TS-673 y la verdad hasta hoy ni me lo había planteado pero cuando lo compre le instalé dos módulos extra de memoria para ocupar los 4 slots que trae.
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.
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 )
Code:
docker stop joplin
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
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 )
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
Se nos presenta un asistente que completaremos como en las siguiente imágenes
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)
Y tras aceptar, ya tendremos nuestro servidor postgresql de la máquina vieja registrado en el PgAdmin de la máquina nueva. 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:
Suministramos los datos del nuevo servidor de PostgreSQL para registrarlo
rellenamos con los datos de ip, usuario, clave y nombre de la base de datos
Y con eso, ya tendremos nuestro servidor PostgreSQL de la máquina nueva, registrado en el PgAdmin de la Nas vieja 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.
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"
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.
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.
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).
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
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" 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.
Lo llamaré igual que en la máquina original "joplin"
definimos la contraseña que luego la usaremos en la definición de creación del docker de Joplin.
le damos privilegios a ese usuario para que pueda operar con la bbdd
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"
Y seguimos un asistente para crearla
Seleccionamos el usuario "joplin" como dueño
En la lengüeta de seguridad le demos los permisos adecuados
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
Se inicia un asistente donde indicaremos el archivo origen y el tipo de copia
especificamos el nombre del archivo de la copia
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
Con el archivo ".env" ,desde una consola nos situamos en esa carpeta "/Volume1/DockerData/joplin" y lanzamos la cadena de creación del docker
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
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
como siempre si veis algún error o errata me lo hacéis llegar por privado para corregirlo
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
Abrimos sesión en la que tenga la BBDD de nuestro Nginx Proxy Manager
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)
Seleccionamos la base de datos y vamos a lengüeta de exportar
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
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
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
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
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.
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
y tras pulsar al botón de "Go" se crea el usuario con permisos sólo en esa BBDD
tal como muestra la siguiente pantalla de resumen
3-restauracion de la base de datos.
Ahora teniendo seleccionada la BBDD "nginx_db" abrimos la legüeta de importar
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.
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
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.
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.
buenos días tengo un qnap con unos 10 usuarios open vpn y todo bien pero desde hace unos días creo que por una actualización de repente no deja entrar a mas usuarios y los que están dentro sigue funcionando con normalidad este es el error que da
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
)
)
