🖥️ Cómo nació el minideb: mi primera nube propia con un Mac mini de 2011

En 2022 no tenía intención de montar un laboratorio doméstico, aprender administración de sistemas por entretenimiento ni llenar una estantería de ordenadores con luces parpadeantes.

Tenía un problema bastante menos romántico: me estaba quedando sin espacio en Dropbox y había dejado de confiar en iCloud Drive.

Durante años, Dropbox había sido una solución cómoda para mantener disponibles mis documentos de trabajo. Había acumulado 21,3 GB de almacenamiento gratuito, una cantidad considerable para una cuenta sin suscripción, pero el volumen de archivos seguía creciendo.

En un taller de artes gráficas no se trabaja únicamente con documentos de texto. Había fotografías, PDF, recursos gráficos, archivos preparados para impresión y proyectos creados con Affinity. Adobe no formaba parte de la ecuación, ni entonces ni ahora: procuro mantener una distancia prudencial de unos tres metros.

Los 21,3 GB habían servido durante bastante tiempo, pero empezaban a quedarse cortos.

La solución más evidente parecía iCloud Drive. Yo trabajaba con equipos Apple y, al menos sobre el papel, utilizar el servicio integrado en el sistema tenía todo el sentido. No necesitaba instalar una plataforma nueva, ni administrar un servidor, ni aprender tecnologías adicionales.

El problema fue que iCloud Drive nunca terminó de adaptarse a mi forma de trabajar.

Y cuando una herramienta encargada de proteger y sincronizar los archivos provoca que dejes de confiar en ellos, la comodidad deja de tener importancia.

☁️ El problema no era solamente el espacio

El límite de Dropbox fue el primer aviso, pero no fue la razón definitiva para buscar una alternativa.

El verdadero punto de ruptura llegó con iCloud Drive.

Una de sus características consiste en mantener determinados documentos como archivos virtuales. El sistema muestra el archivo en su ubicación habitual, pero su contenido completo puede no estar almacenado localmente. Cuando hace falta, se descarga desde la nube.

En teoría, es una forma razonable de ahorrar espacio en el disco.

En mi flujo de trabajo resultó ser una fuente de incertidumbre.

Entre una sincronización y la siguiente llegaron a perderse archivos. Algunos documentos parecían estar disponibles, otros se descargaban cuando el sistema lo consideraba oportuno y, en determinados momentos, dejaba de estar completamente claro qué copia era la correcta o dónde se encontraba el archivo completo.

Para un uso ocasional puede ser una molestia.

Para trabajar con documentos reales de clientes, proyectos gráficos y archivos que cambian constantemente, es un problema serio.

Una sincronización no debería obligarte a preguntarte si el documento que estás viendo existe realmente en el equipo, si sigue únicamente en la nube o si una modificación se ha propagado correctamente. Tampoco debería convertir una carpeta de trabajo en una especie de representación administrativa de tus propios archivos.

La pérdida de algunos documentos terminó de romper la confianza.

A partir de ese momento, el problema ya no podía resolverse comprando más almacenamiento.

Podía ampliar Dropbox o contratar un plan superior de iCloud, pero seguiría dependiendo de una plataforma cuyo funcionamiento no controlaba. Tendría más espacio, pero no necesariamente más tranquilidad.

Necesitaba una solución en la que los archivos estuvieran físicamente donde yo decidiera y en la que la sincronización se adaptara a mi forma de trabajar, no al revés.

Por esa experiencia, todavía hoy no utilizo la función de archivos virtuales de Nextcloud. Prefiero que los documentos sincronizados estén realmente almacenados en los equipos en los que trabajo.

No es una decisión teórica ni una preferencia basada en una comparativa de funciones.

Es la consecuencia directa de haber perdido archivos.

🔎 De ownCloud a Nextcloud

Yo ya conocía ownCloud como alternativa autoalojada a Dropbox.

Cuando empecé a buscar información para montar una nube propia, mi intención inicial era precisamente instalar ownCloud. Durante esa búsqueda descubrí Nextcloud, un proyecto surgido a partir de aquella misma base y orientado también al almacenamiento, sincronización y colaboración mediante una infraestructura controlada por el propio usuario.

Nextcloud ofrecía lo que necesitaba:

• almacenamiento bajo mi control;
• sincronización entre varios equipos;
• acceso mediante navegador;
• clientes para escritorio y dispositivos móviles;
• posibilidad de ampliar sus funciones;
• ausencia de un límite de capacidad impuesto por una cuenta comercial.

El espacio disponible dependería de los discos que conectara al servidor.

Eso cambiaba completamente el problema.

Con Dropbox, aumentar la capacidad significaba contratar un plan superior. Con una solución autoalojada, la capacidad dependía de la infraestructura física que estuviera dispuesto a utilizar.

Sin embargo, instalar Nextcloud implicaba resolver una cuestión previa: necesitaba una máquina que pudiera permanecer encendida, conectada a la red y disponible de manera continua.

Así apareció el minideb.

🧰 Aprovechar el hardware que ya tenía

Podía haber comprado un mini PC o algún equipo diseñado específicamente para funcionar como servidor doméstico.

No tenía ningún sentido hacerlo.

El proyecto era todavía experimental y disponía de material suficiente para ponerlo en marcha sin gastar dinero. Comprar una máquina nueva antes de saber si la solución funcionaría habría sido una manera bastante eficiente de convertir una prueba técnica en otro gasto innecesario.

El equipo elegido fue un Mac mini de 2011, con procesador Intel Core i5 y 16 GB de memoria RAM.

No era una máquina nueva, pero para ejecutar Debian y Nextcloud tenía recursos más que suficientes. Además, el formato del Mac mini ofrecía varias ventajas prácticas:

• ocupaba poco espacio;
• era silencioso;
• tenía un consumo razonable;
• podía mantenerse encendido permanentemente;
• disponía de conexión Ethernet;
• permitía instalar dos unidades internas.

En su interior había dos SSD.

Uno estaba dedicado al sistema y el otro se utilizaba para mantener una copia de seguridad. Además, el equipo tenía conectados dos discos duros de 3,5 pulgadas en cajas externas, destinados a ampliar el almacenamiento disponible.

Visto con criterios actuales, no era una infraestructura especialmente sofisticada. Tampoco pretendía serlo.

Era un ordenador reutilizado, varios discos que ya tenía y una necesidad concreta.

Eso era suficiente.

Primera iteración del minideb: un Mac mini de 2011 acompañado por las unidades externas que proporcionaban el almacenamiento.

El minideb vivía en el taller que tenía en aquel momento. Estaba conectado mediante Ethernet a una línea de fibra simétrica de 600/600 Mb, una conexión más que suficiente para trabajar con archivos desde el exterior sin que la velocidad de subida se convirtiera inmediatamente en el cuello de botella.

No había una sala técnica, un armario de comunicaciones ni una infraestructura diseñada previamente.

Había un Mac mini en el taller resolviendo un problema real.

🧪 Antes de Debian: probar varias opciones

Elegir el hardware fue la parte sencilla.

La elección del sistema operativo requirió más pruebas.

Antes de instalar definitivamente Debian pasé por varias alternativas. Entre ellas estuvieron Unraid, TrueNAS y Linux Mint utilizado como servidor.

No las descarté porque fueran sistemas malos. Las descarté porque no eran la solución adecuada para mí, para mis conocimientos de aquel momento y para el problema que necesitaba resolver.

Esa diferencia es importante.

En tecnología se tiende a convertir cualquier elección en una discusión universal: cuál es el mejor sistema, la mejor distribución, el mejor servidor o la mejor plataforma. En la práctica, una solución no se elige en el vacío. Se elige dentro de un contexto formado por los conocimientos disponibles, el hardware, el objetivo y el tiempo que se puede dedicar a mantenerla.

🟠 Unraid

Unraid era una opción atractiva por su facilidad para gestionar almacenamiento y servicios desde una interfaz centralizada.

Sin embargo, yo estaba acostumbrado a sistemas del entorno Debian. Había utilizado distribuciones como Ubuntu, Linux Mint y, en otros contextos, Kali Linux. Mi forma de entender la administración de sistemas estaba construida alrededor de GNU/Linux y, en particular, de herramientas y estructuras familiares dentro de la familia Debian.

El principal obstáculo con Unraid no fue una limitación concreta del producto.

Fue mi falta de conocimiento sobre su funcionamiento.

Podía aprenderlo, naturalmente, pero eso significaba añadir una capa nueva precisamente cuando ya tenía bastante trabajo por delante: instalar Nextcloud, organizar los discos, configurar la red y poner en funcionamiento la sincronización.

Unraid pretendía simplificar la administración mediante su propia forma de trabajar. Para aprovechar esa simplificación, primero tenía que aprender la plataforma.

En aquel momento preferí invertir ese esfuerzo en profundizar en herramientas que ya conocía y que podrían servirme también fuera de ese proyecto.

🔵 TrueNAS

TrueNAS parecía una alternativa sólida, especialmente por su orientación al almacenamiento y por la reputación que tenía como sistema para construir servidores NAS.

El motivo por el que no continué con él fue más directo: estaba basado en FreeBSD, no en GNU/Linux.

FreeBSD es un sistema serio y perfectamente válido para un servidor. El problema era, nuevamente, el contexto.

Yo quería trabajar dentro de un entorno que me resultara familiar y trasladar conocimientos que ya tenía. Elegir TrueNAS significaba aprender diferencias en la organización del sistema, la gestión de paquetes, la administración y el funcionamiento general de la plataforma.

No buscaba estudiar varios sistemas operativos al mismo tiempo.

Buscaba poner en marcha una nube propia.

TrueNAS podía resolver una parte importante del problema, pero me alejaba del ecosistema en el que me sentía más cómodo y que tenía más interés en aprender a fondo.

🟢 Linux Mint

Linux Mint estaba mucho más cerca de mi terreno conocido.

Era una distribución basada en Ubuntu y, por extensión, dentro de la familia Debian. Había utilizado Mint anteriormente y conocía su lógica general.

Pero precisamente esa cercanía provocó la pregunta definitiva:

Si iba a utilizar como servidor una distribución basada en Debian, ¿por qué no ir directamente a la fuente?

Mint es una excelente distribución de escritorio. Su trabajo consiste, en gran medida, en tomar una base ya existente y ofrecer una experiencia más cómoda para el usuario final.

En un servidor sin entorno gráfico, muchas de esas ventajas dejaban de ser relevantes.

No necesitaba un escritorio preparado, una selección de aplicaciones ni una capa adicional de comodidad. Necesitaba una base estable, documentada y suficientemente limpia como para instalar únicamente lo que fuera necesario.

El rodeo dejó de tener sentido.

La elección final fue Debian.

🐧 Debian sin escritorio y sin red de seguridad estética

La instalación se realizó desde un pendrive.

En un Mac mini de aquella generación, el procedimiento comenzaba arrancando el equipo mientras mantenía pulsada la tecla Alt, seleccionando después la unidad USB como dispositivo de inicio.

No instalé Debian junto a macOS.

No había arranque dual ni una partición reservada por si algún día quería volver atrás. Debian quedó como único sistema operativo del disco.

Era una máquina dedicada y no tenía sentido conservar un sistema que no iba a utilizar.

La instalación era headless, sin entorno gráfico. El minideb no necesitaba monitor, teclado ni ratón para su funcionamiento diario. Una vez conectado a la red, la administración se realizaba mediante SSH desde mi ordenador principal.

En realidad, esa era una de las razones para utilizar Debian.

Un servidor no necesita ofrecer una experiencia visual agradable. Necesita arrancar, ejecutar sus servicios y continuar funcionando sin llamar la atención.

Cada componente adicional introduce mantenimiento, actualizaciones, consumo de recursos y nuevas posibilidades de fallo. Un escritorio completo habría aportado muy poco a una máquina cuya administración se realizaba remotamente.

Debian ofrecía justo lo que buscaba:

• una base estable;
• repositorios amplios;
• una comunidad enorme;
• abundante documentación;
• herramientas conocidas;
• libertad para instalar solo lo necesario;
• un sistema que no intentaba ocultar su funcionamiento detrás de una interfaz específica.

No era la opción más vistosa.

Era la opción que menos se interponía entre el problema y la solución.

📦 La primera instalación de Nextcloud

No recuerdo con exactitud qué versión de Nextcloud instalé. Fue en 2022 y la numeración concreta ha quedado enterrada bajo suficientes actualizaciones como para no fingir una precisión que no tengo.

Lo importante no era el número de versión.

Lo importante era que Nextcloud comenzó a funcionar sobre una Debian instalada en un Mac mini de 2011, utilizando discos que ya tenía y una conexión de fibra del propio taller.

A partir de ese momento, el almacenamiento dejó de depender de los 21,3 GB de Dropbox.

La capacidad estaba determinada por mis propios discos.

También cambió la relación con los archivos.

Ya no estaban alojados únicamente en la infraestructura de una empresa externa. Existía una copia central almacenada físicamente en el taller y accesible desde los equipos autorizados.

Nextcloud no eliminaba la necesidad de tener copias de seguridad. Una nube propia no convierte mágicamente los discos en indestructibles, por mucho que a veces la palabra “nube” haga pensar que los datos flotan en una dimensión protegida de averías, errores humanos y café derramado.

Por eso el Mac mini disponía de un segundo SSD destinado a mantener una copia del sistema y de unidades externas para el almacenamiento.

La estructura podía perfeccionarse, pero desde el principio existía la conciencia de que sincronizar no es lo mismo que hacer una copia de seguridad.

Si un archivo se elimina o se corrompe y esa modificación se sincroniza correctamente, el problema también puede propagarse correctamente. La sincronización mantiene coherencia entre ubicaciones; una copia de seguridad permite volver a un estado anterior.

Aquella distinción se convertiría en uno de los aprendizajes más importantes del proyecto.

🌐 El primer obstáculo estaba fuera del servidor

La instalación de Debian podía estar correcta.

Nextcloud podía funcionar dentro de la red local.

La fibra podía ofrecer 600 Mb tanto de bajada como de subida.

Nada de eso garantizaba que el servidor fuera accesible desde Internet.

El operador mantenía la conexión detrás de CG-NAT.

CG-NAT permite que varios clientes compartan una misma dirección IPv4 pública. Para un usuario que solamente navega, utiliza mensajería o consume servicios externos, normalmente pasa desapercibido.

Para quien pretende publicar un servicio desde su propia red, se convierte inmediatamente en un obstáculo.

Las conexiones iniciadas desde el exterior no podían llegar directamente hasta el router del taller porque la dirección pública no pertenecía realmente a mi conexión de manera exclusiva.

Descubrí el problema inmediatamente.

No hicieron falta varios días de revisar Debian, reinstalar paquetes o culpar a Nextcloud. Tardé aproximadamente 37 microsegundos en sospechar de la red del operador. La cifra carece de rigor científico, pero describe razonablemente bien la situación.

El problema no estaba en el servidor.

Estaba antes de llegar al servidor.

Tuve que solicitar al operador que retirara el CG-NAT y asignara una dirección pública a la conexión. Una vez realizado el cambio, el acceso desde el exterior comenzó a funcionar.

El alivio fue casi físico.

Después de instalar el sistema, configurar el servicio, organizar los discos y comprobar que todo funcionaba dentro del taller, eliminar aquella barrera permitió que el proyecto cumpliera por fin su objetivo: acceder a mis propios archivos desde fuera de la red local.

Fue el equivalente técnico a desbloquear algo que llevaba demasiado tiempo atascado. No hace falta desarrollar más la metáfora.

🔐 Autoalojar también significa asumir responsabilidades

Montar una nube propia resolvía varios problemas, pero también trasladaba responsabilidades.

Cuando los archivos estaban en Dropbox o iCloud, otra empresa se ocupaba de los servidores, la conectividad, buena parte de la seguridad y la disponibilidad de la plataforma.

Con Nextcloud, esas tareas pasaban a depender de mí.

Había que mantener Debian actualizado, revisar Nextcloud, asegurar el acceso remoto, gestionar los discos, comprobar las copias y entender qué ocurría cuando algo fallaba.

Ese intercambio era consciente.

No estaba buscando una solución que no requiriera trabajo. Estaba buscando una solución cuyo funcionamiento pudiera comprender y controlar.

La nube comercial ofrecía comodidad a cambio de dependencia.

El autoalojamiento ofrecía control a cambio de responsabilidad.

En mi caso, el segundo equilibrio encajaba mejor.

Además, cada problema que aparecía obligaba a aprender algo reutilizable: permisos, servicios web, certificados, DNS, almacenamiento, copias de seguridad, acceso remoto y funcionamiento de la red.

El minideb no nació como una plataforma educativa, pero terminó convirtiéndose también en una.

🗂️ Los archivos virtuales que decidí no volver a utilizar

Nextcloud también permite trabajar con archivos virtuales.

El cliente puede mostrar el contenido de una carpeta sin descargar necesariamente todos los datos al dispositivo. Es una función útil cuando el almacenamiento local es limitado o cuando se gestionan volúmenes muy grandes.

Yo decidí no utilizarla.

No porque la implementación de Nextcloud fuera idéntica a la de iCloud Drive, sino porque la experiencia anterior había cambiado mi criterio.

Quería saber que los archivos de trabajo sincronizados estaban físicamente en el equipo.

Prefería asumir el consumo de espacio local antes que volver a depender de referencias que podían representar un contenido almacenado únicamente en remoto.

Esta decisión puede parecer conservadora. Lo es.

Pero no nació del miedo abstracto a una tecnología, sino de una incidencia concreta: había perdido archivos durante procesos de sincronización y no estaba dispuesto a repetir la experiencia por ahorrar espacio en un disco.

La eficiencia no consiste siempre en reducir el almacenamiento utilizado.

A veces consiste en reducir la incertidumbre.

✅ Cuándo el experimento dejó de ser un experimento

El proyecto comenzó como una prueba porque no sabía hasta qué punto aquella combinación sería fiable:

• un Mac mini de 2011;
• Debian sin entorno gráfico;
• dos SSD internos;
• dos discos externos;
• Nextcloud;
• acceso mediante SSH;
• una conexión de fibra del taller.

No había comprado hardware específicamente para ello y tampoco existía un plan de crecimiento detallado.

La prueba se volvió útil en cuanto pude sincronizar los archivos, acceder desde el exterior y trabajar sin depender del límite de Dropbox ni del comportamiento de iCloud Drive.

Ese fue el momento en que el minideb dejó de ser simplemente un ordenador antiguo reutilizado.

Se convirtió en una herramienta de trabajo.

El cambio no llegó mediante una gran migración organizada de antemano. Llegó cuando empecé a confiar más en la solución que había montado que en las plataformas que pretendía sustituir.

La sensación fue otra vez la de haber liberado una obstrucción.

Ya no tenía que decidir qué archivos merecían ocupar los 21,3 GB disponibles.

Ya no dependía de que iCloud interpretara correctamente qué debía conservar de forma local.

Ya no tenía que adaptar mi forma de trabajar a las reglas de almacenamiento de otra empresa.

Los archivos estaban en mis discos, dentro de una máquina que podía administrar y cuya capacidad podía ampliar cuando fuera necesario.

⚖️ Por qué Debian fue la decisión correcta

Con el tiempo, la elección de Debian demostró tener más importancia que la simple instalación de Nextcloud.

Podría haber continuado con una plataforma específica para almacenamiento. Tal vez algunas operaciones iniciales habrían resultado más sencillas mediante una interfaz gráfica.

Sin embargo, utilizar Debian directamente ofreció una ventaja que no era visible durante los primeros días: el conocimiento adquirido no quedaba encerrado dentro de un producto.

Aprender a administrar Debian significaba aprender sobre GNU/Linux, servicios, redes, permisos, paquetes, registros y procesos. Esos conocimientos podían aplicarse después a otros proyectos y a otras máquinas.

En cambio, una plataforma muy especializada habría resuelto determinadas tareas de forma cómoda, pero parte del aprendizaje habría quedado vinculado a su propia interfaz y a sus propias decisiones de diseño.

Debian me obligaba a comprender más cosas.

En aquel momento eso suponía más trabajo.

A largo plazo fue una ventaja.

La elección no demuestra que Debian sea universalmente mejor que Unraid o TrueNAS. Sería una conclusión bastante pobre para un caso basado precisamente en analizar el contexto.

Demuestra algo más útil:

La mejor plataforma no es necesariamente la que ofrece más funciones ni la que simplifica más tareas desde el primer día. Es la que encaja con el conocimiento disponible, permite resolver el problema y deja una base útil para lo que todavía no se ha previsto.

💶 El valor de no comprar nada

Otro elemento importante fue la decisión de no invertir en hardware nuevo.

Es fácil convertir cualquier proyecto técnico en una lista de compras: un mini PC moderno, discos nuevos, más memoria, una caja específica y accesorios que supuestamente resultan imprescindibles antes de haber instalado el primer servicio.

En este caso, comprar una máquina habría añadido coste sin resolver ninguna necesidad que el Mac mini no pudiera cubrir.

El equipo ya estaba disponible.

Tenía 16 GB de RAM.

Permitía instalar dos SSD internos.

Disponía de Ethernet.

Era compacto y silencioso.

Podía ejecutar Debian sin dificultad.

La pregunta no era si existía un ordenador más rápido o eficiente. Naturalmente que existía.

La pregunta era si hacía falta.

La respuesta era no.

Reutilizar el hardware permitió validar la idea antes de dedicar dinero a ella. Si el proyecto no hubiera funcionado, la pérdida habría sido principalmente de tiempo y aprendizaje. Si funcionaba, cualquier ampliación futura podría decidirse con datos reales en lugar de basarse en previsiones.

Ese criterio sigue siendo válido para muchos proyectos tecnológicos: primero comprobar que la solución aporta valor; después invertir donde exista una limitación demostrable.

Comprar infraestructura por adelantado es una manera muy humana de sentirse productivo sin haber resuelto todavía el problema. Las cajas recién abiertas generan satisfacción. Los servicios estables generan resultados. Conviene no confundir ambas cosas.

🔄 Lo que haría diferente hoy

Visto desde el presente, algunas decisiones podrían organizarse mejor.

La estrategia de copias de seguridad podría haberse diseñado desde el principio con criterios más claros de versiones, separación física y pruebas periódicas de restauración.

La documentación de la instalación también podría haber sido más sistemática. Cuando un sistema empieza como experimento, existe la tentación de pensar que ciertos detalles podrán recordarse más adelante. La memoria humana, esa base de datos sin índices ni garantías de consistencia, suele opinar lo contrario.

También habría definido antes una estructura clara para separar:

• sistema operativo;
• datos de Nextcloud;
• copias de configuración;
• copias de los archivos;
• registros de cambios;
• procedimientos de recuperación.

Sin embargo, no cambiaría la decisión principal.

Volvería a utilizar el hardware disponible.

Volvería a instalar Debian directamente.

Volvería a administrar la máquina mediante SSH.

Y volvería a evitar los archivos virtuales para los documentos de trabajo que necesito tener realmente disponibles.

📌 Qué enseñó el minideb

El minideb nació porque dos servicios comerciales dejaron de resolver correctamente una necesidad concreta.

Dropbox ofrecía estabilidad, pero el espacio gratuito se había quedado pequeño.

iCloud Drive ofrecía integración, pero su funcionamiento con archivos virtuales no resultó fiable para mi forma de trabajar y llegó a provocar la pérdida de documentos.

Nextcloud apareció como una alternativa que permitía recuperar el control sobre el almacenamiento y la sincronización.

Para ejecutarlo no fue necesario comprar un servidor nuevo.

Bastaron un Mac mini de 2011, varios discos disponibles, Debian y el tiempo necesario para comprender cómo encajaban todas las piezas.

El resultado dejó varias lecciones que siguen siendo aplicables:

• Un problema concreto debe definir la infraestructura, no al revés.
• Sincronización y copia de seguridad no son la misma cosa.
• La confianza en los archivos vale más que el ahorro de espacio local.
• El hardware antiguo puede seguir siendo útil cuando la tarea está bien dimensionada.
• No conviene comprar equipamiento para validar una idea que puede probarse con recursos disponibles.
• Una solución especializada no siempre es mejor que una base general bien conocida.
• Elegir una tecnología también significa elegir qué conocimientos se quieren desarrollar.
• El autoalojamiento proporciona control, pero obliga a asumir mantenimiento, seguridad y copias.
• Una conexión rápida no sirve para publicar servicios si el operador mantiene la línea detrás de CG-NAT.
• La mejor solución puede ser la menos espectacular, siempre que funcione de forma predecible.

🧭 El aprendizaje permanente

La documentación de Nextcloud explica cómo instalar la plataforma.

La documentación de Debian explica cómo administrar el sistema.

Los manuales de red explican qué es CG-NAT.

Lo que ninguna de esas fuentes puede decidir es si tiene sentido combinar todas esas piezas para resolver un problema concreto.

Ese fue el verdadero trabajo.

No consistió únicamente en ejecutar comandos o instalar paquetes. Consistió en identificar por qué las soluciones existentes habían dejado de servir, evaluar alternativas, descartar plataformas válidas que no encajaban con el contexto y construir una solución proporcionada con los recursos disponibles.

El minideb no nació porque quisiera tener un servidor.

Nació porque necesitaba dejar de preocuparme por dónde estaban mis archivos.

Todo lo demás vino después.