Cómo diseñar una estructura de directorios propia para aplicaciones empresariales

Introducción

Diseñar una estructura de directorios propia para aplicaciones empresariales no consiste en crear muchas carpetas ni en imponer una jerarquía complicada. Consiste en decidir, antes de desplegar software, dónde debe vivir cada tipo de activo: código, binarios, configuración, datos persistentes, archivos temporales, registros, copias, secretos, scripts y documentación operativa.

Cuando esta decisión no se toma de forma consciente, el servidor empieza a crecer por acumulación. Una aplicación se instala dentro de /home, otra utiliza directamente /var/www, un script queda en /root, los datos terminan mezclados con el código, los logs aparecen en carpetas propias sin rotación y las copias se guardan en el mismo disco que la producción. Durante los primeros meses todo puede funcionar. El problema aparece después, cuando hay que actualizar, migrar, recuperar, delegar el mantenimiento o identificar qué archivos pertenecen realmente a cada servicio.

Una estructura útil debe respetar las convenciones del sistema Linux sin convertirlas en una norma rígida. El sistema operativo, los paquetes gestionados por la distribución y las aplicaciones empresariales propias tienen ciclos de vida diferentes. Separarlos permite actualizar el servidor, sustituir una aplicación, restaurar sus datos o retirar un servicio con menos riesgo.

Este artículo presenta un método práctico para diseñar directorios en servidores Linux utilizados por autónomos, microempresas, PYMES y organizaciones que operan aplicaciones web, integraciones, plataformas LMS, procesos de datos o servicios internos. El objetivo es conseguir una estructura que sea comprensible, repetible, segura y fácil de mantener, sin sobredimensionar la solución.

Índice

• Qué problema resuelve una estructura propia
• Principios de diseño
• Cómo encaja con la jerarquía estándar de Linux
• Cuándo utilizar /opt, /srv y /var
• Modelo base recomendado
• Dónde colocar código y binarios
• Cómo organizar versiones y despliegues
• Cómo separar la configuración
• Dónde gestionar secretos y credenciales
• Cómo organizar datos persistentes
• Cómo organizar logs y auditoría
• Archivos temporales, cachés y colas
• Scripts operativos y tareas programadas
• Copias, exportaciones y archivos de recuperación
• Usuarios, grupos y permisos
• Integración con systemd
• Aplicaciones web y servidores HTTP
• Aplicaciones desplegadas con contenedores
• Separación entre producción, pruebas y desarrollo
• Convenciones de nombres
• Ejemplo completo de aplicación empresarial
• Ejemplo aplicado a una plataforma LMS
• Cómo migrar una estructura desordenada
• Cómo auditar la estructura
• Errores frecuentes
• Lista de comprobación
• Preguntas frecuentes
• Conclusión

Qué problema resuelve una estructura propia

Una aplicación empresarial no está formada únicamente por un ejecutable o una carpeta de código. Normalmente necesita varios tipos de archivos con comportamientos distintos:

• código o binarios que cambian durante los despliegues;
• configuración específica del entorno;
• secretos que requieren protección especial;
• datos que deben sobrevivir a las actualizaciones;
• logs que crecen y necesitan rotación;
• cachés y archivos temporales que pueden regenerarse;
• scripts de operación y mantenimiento;
• copias o exportaciones que tienen su propia retención;
• documentación necesaria para administrar el servicio.

Si todos estos elementos se guardan juntos, cada intervención se vuelve más peligrosa. Una actualización puede sobrescribir datos. Una copia puede incluir gigabytes de caché inútil. Un técnico puede borrar una carpeta creyendo que solo contiene una versión antigua. Un secreto puede terminar dentro de un repositorio. Un log sin rotación puede llenar el disco donde se encuentra la base de datos.

La estructura de directorios aporta límites. Permite saber qué puede sustituirse, qué debe conservarse, qué puede eliminarse y qué necesita permisos especiales.

Una buena jerarquía no organiza archivos por apariencia, sino por función, ciclo de vida, propiedad y necesidad de recuperación.

Este enfoque complementa cómo organizar un servidor Linux para que siga siendo mantenible dentro de cinco años. Aquel artículo aborda la filosofía general de administración; aquí se profundiza en el diseño concreto de directorios para aplicaciones empresariales.

Principios de diseño

Separar lo sustituible de lo persistente

El código y los binarios pueden reemplazarse durante una actualización. Los datos empresariales no. Ambos elementos no deberían depender de la misma operación de copia, despliegue o limpieza.

Una ubicación debe tener un significado estable

Si una carpeta contiene hoy código y mañana se utiliza también para copias, deja de comunicar su función. La estructura debe poder explicarse mediante pocas reglas coherentes.

Respetar las convenciones del sistema

No conviene crear una jerarquía paralela que ignore completamente Linux. Utilizar ubicaciones reconocibles facilita el soporte, la automatización y la incorporación de otros administradores.

Evitar depender de una persona

La estructura debe ser comprensible para una persona autorizada que no haya instalado la aplicación. Los nombres personales y las carpetas improvisadas dentro de directorios privados dificultan el relevo.

Diseñar para actualizar y recuperar

Antes de decidir una ruta conviene preguntar:

• ¿cómo se desplegará una nueva versión?
• ¿cómo se volverá a la anterior?
• ¿qué debe copiarse?
• ¿qué puede regenerarse?
• ¿qué permisos necesita?
• ¿qué ocurre si el disco se llena?
• ¿cómo se trasladará a otro servidor?

Aplicar la mínima complejidad suficiente

Una aplicación pequeña no necesita veinte niveles de carpetas. El diseño debe resolver problemas reales sin convertirse en burocracia técnica.

Cómo encaja con la jerarquía estándar de Linux

Linux utiliza una jerarquía de directorios con finalidades conocidas. Aunque las distribuciones pueden introducir variaciones, varias ubicaciones son especialmente relevantes para aplicaciones empresariales.

La clave no es utilizar todas estas rutas, sino asignar responsabilidades coherentes. Una aplicación pequeña puede funcionar con código en /opt, configuración en /etc, datos en /var/lib y logs en /var/log. Una aplicación que publica archivos puede necesitar además /srv.

No conviene modificar directamente directorios gestionados por el sistema de paquetes, como determinadas rutas internas de /usr, para almacenar componentes empresariales improvisados. La actualización de la distribución debe poder ejecutarse sin confundir archivos propios con archivos del sistema.

Cuándo utilizar /opt, /srv y /var

Utilizar /opt para la aplicación desplegada

/opt resulta adecuado cuando la empresa instala una aplicación propia o de terceros que desea mantener separada del software de la distribución.

/opt/empresa/
└── aplicacion/
    ├── releases/
    ├── current -> releases/2026.08.01/
    └── shared/

Esta estructura permite identificar versiones y conservar una referencia clara a la versión activa.

Utilizar /srv para contenido ofrecido por un servicio

/srv puede utilizarse para datos que el servidor presta directamente: contenido web, repositorios, descargas, archivos compartidos o materiales publicados.

/srv/empresa/
├── web-publica/
├── descargas/
└── contenidos-lms/

No todo dato persistente debe ir en /srv. Una base interna, una cola o un índice de búsqueda suele encajar mejor en /var/lib.

Utilizar /var para el estado variable

/var agrupa información que cambia durante la operación:

• /var/lib/aplicacion para estado persistente;
• /var/log/aplicacion para registros;
• /var/cache/aplicacion para caché regenerable;
• /var/spool/aplicacion para colas o trabajo pendiente;
• /var/tmp/aplicacion para temporales que deben sobrevivir a un reinicio.

No existe una única respuesta universal

Dos aplicaciones pueden utilizar modelos distintos sin que uno sea incorrecto. Lo importante es que la elección sea explícita, documentada y compatible con copias, permisos, despliegues y recuperación.

Modelo base recomendado

Para una aplicación empresarial propia puede utilizarse una estructura como esta:

/opt/empresa/aplicacion/
├── releases/
│   ├── 2026.07.15/
│   └── 2026.08.01/
├── current -> releases/2026.08.01/
└── shared/
    ├── assets/
    └── docs/

/etc/empresa/aplicacion/
├── app.conf
├── logging.conf
└── app.conf.example

/var/lib/empresa/aplicacion/
├── data/
├── uploads/
├── state/
└── migrations/

/var/log/empresa/aplicacion/
├── app.log
├── error.log
└── audit.log

/var/cache/empresa/aplicacion/
/run/empresa/aplicacion/
/usr/local/lib/empresa/aplicacion/
/usr/local/sbin/empresa-aplicacion-maintenance

No es obligatorio introducir el nombre de la empresa en todas las rutas, pero hacerlo puede evitar colisiones y facilitar inventarios cuando el servidor aloja varias aplicaciones propias.

La estructura debe adaptarse al tamaño real. Para una utilidad sencilla podría bastar con:

/opt/mi-aplicacion
/etc/mi-aplicacion
/var/lib/mi-aplicacion
/var/log/mi-aplicacion

La profundidad adicional solo debe introducirse cuando separa responsabilidades reales.

Dónde colocar código y binarios

El código desplegado debe estar en una ubicación controlada, legible y separada de los datos de usuario.

Aplicaciones autocontenidas

Una aplicación completa puede instalarse bajo /opt/empresa/aplicacion. Allí pueden residir:

• código ejecutable;
• dependencias empaquetadas;
• entornos virtuales;
• recursos estáticos versionados;
• archivos necesarios para iniciar el servicio.

Herramientas compartidas

Los scripts o binarios administrativos utilizados por varios servicios pueden instalarse en /usr/local/bin o /usr/local/sbin. Deben tener nombres claros y no sobrescribir comandos proporcionados por la distribución.

No ejecutar producción desde un repositorio personal

Desplegar directamente desde /home/usuario/proyecto crea varias dependencias:

• el servicio depende de una cuenta personal;
• los permisos pueden cambiar al modificar el usuario;
• el repositorio de trabajo se mezcla con producción;
• un comando de limpieza puede afectar al servicio;
• la baja del usuario complica la continuidad.

El repositorio de desarrollo y la versión desplegada deben considerarse elementos distintos.

Cómo organizar versiones y despliegues

Una aplicación mantenible debe permitir saber qué versión está activa, conservar una anterior durante un tiempo razonable y volver atrás cuando el cambio falla.

Directorio releases

/opt/empresa/aplicacion/releases/
├── 2026.07.15-1/
├── 2026.07.29-1/
└── 2026.08.01-2/

El identificador puede ser una versión semántica, una fecha, un número de compilación o una referencia de control de versiones. Debe ser inequívoco.

Enlace current

/opt/empresa/aplicacion/current -> releases/2026.08.01-2

El servicio apunta a current, no a una versión fija. Cambiar el enlace permite activar una versión nueva con una operación controlada.

Datos fuera de releases

Las cargas de usuarios, bases internas, claves y configuración no deben duplicarse dentro de cada versión. La nueva versión debe conectarse a ubicaciones persistentes separadas.

Conservar pocas versiones válidas

Guardar todas las versiones indefinidamente consume espacio y dificulta identificar qué puede eliminarse. Puede conservarse la activa, una o dos versiones anteriores y los paquetes necesarios para reconstruir otras.

Despliegues repetibles

La creación de una release debería poder repetirse mediante un procedimiento o script. Copiar archivos manualmente sin registro introduce diferencias difíciles de rastrear.

La filosofía de despliegues controlados se relaciona con cómo automatizar despliegues web sin perder control operativo.

Cómo separar la configuración

La configuración describe cómo debe funcionar la aplicación en un entorno concreto. No debería quedar mezclada con el código si cambia entre servidores o si contiene valores operativos.

Configuración principal en /etc

/etc/empresa/aplicacion/
├── app.conf
├── database.conf
├── logging.conf
└── integrations.conf

Esta ubicación facilita inventariar, copiar, comparar y controlar permisos.

Plantillas sin secretos

El repositorio del código puede incluir archivos de ejemplo:

app.conf.example
database.conf.example

Estos archivos muestran parámetros esperados, pero no contienen credenciales reales.

Separar configuración estática y dinámica

Los parámetros administrados por el sistema pueden residir en /etc. El estado modificado por la propia aplicación suele pertenecer a /var/lib. Mezclar ambos tipos dificulta saber qué debe versionarse y qué debe copiarse.

Validar antes de recargar

Cuando la aplicación ofrece un comando de validación, debe utilizarse antes de reiniciar o recargar. La estructura debe facilitar pruebas sobre el archivo exacto que utiliza producción.

Registrar la fuente oficial

Debe quedar claro si la configuración se mantiene manualmente, mediante un repositorio, una herramienta de gestión o un sistema de despliegue. Tener varias fuentes activas produce cambios contradictorios.

Dónde gestionar secretos y credenciales

Contraseñas, tokens, certificados y claves privadas requieren controles distintos a la configuración general.

No guardar secretos en el código

Un secreto incluido dentro del repositorio puede terminar en copias, entornos de prueba, registros o equipos personales. Eliminarlo de la versión actual no borra el historial.

Ubicaciones protegidas

En entornos pequeños puede utilizarse una ruta específica bajo /etc, con propietario y permisos restrictivos:

/etc/empresa/aplicacion/secrets/
├── database-password
├── api-token
└── private-key.pem

Estos archivos no deben ser legibles por usuarios que no los necesiten. En entornos más maduros puede utilizarse un gestor de secretos.

Evitar secretos en variables visibles

Las variables de entorno pueden ser apropiadas en determinados diseños, pero no deben asumirse como automáticamente seguras. Debe conocerse quién puede inspeccionar procesos, unidades de systemd, volcados y archivos de entorno.

Rotación y recuperación

La documentación debe indicar qué sistema utiliza cada secreto, cómo se rota y qué ocurre durante una recuperación. Una credencial sin propietario termina olvidada.

La protección de accesos debe integrarse con cómo crear políticas de acceso en una empresa pequeña.

Cómo organizar datos persistentes

Los datos persistentes son aquellos que deben sobrevivir a una actualización, reinstalación o sustitución del código.

Estado interno de la aplicación

/var/lib/empresa/aplicacion/
├── database/
├── state/
├── indexes/
└── queues/

Esta ubicación resulta adecuada para bases internas, índices, metadatos, colas y otros elementos modificados por el servicio.

Archivos aportados por usuarios

Las cargas pueden necesitar una separación adicional:

/var/lib/empresa/aplicacion/uploads/
├── incoming/
├── validated/
├── rejected/
└── archived/

Separar estados facilita tratamiento de errores y evita mezclar archivos todavía no validados con contenido operativo.

Datos ofrecidos como servicio

Cuando los archivos se publican o comparten directamente, puede utilizarse /srv. La decisión depende de la función, no solo del formato.

Separar originales, derivados y temporales

• Originales: deben conservarse y copiarse.
• Derivados: pueden regenerarse, pero quizá resulte costoso.
• Temporales: pueden eliminarse cuando se completa el proceso.

Esta clasificación permite diseñar copias y políticas de limpieza diferentes.

Definir propietarios de los datos

El usuario del servicio debe poder leer y escribir únicamente las rutas necesarias. Los datos no deberían pertenecer de forma indiscriminada a root ni conceder permisos globales para resolver problemas rápidos.

Cómo organizar logs y auditoría

Los logs cambian continuamente y pueden crecer con rapidez. Deben estar separados del código y de los datos críticos.

Directorio propio

/var/log/empresa/aplicacion/
├── application.log
├── error.log
├── access.log
└── audit.log

Distinguir tipos de registro

• Aplicación: actividad y eventos funcionales.
• Error: fallos que requieren diagnóstico.
• Acceso: solicitudes o conexiones.
• Auditoría: acciones sensibles y cambios relevantes.

Rotación obligatoria

Un archivo de log no debe crecer indefinidamente. Deben definirse tamaño o frecuencia de rotación, compresión, retención y tratamiento cuando el disco se aproxima al límite.

No registrar secretos

Los logs no deben contener contraseñas, tokens completos, claves privadas ni datos personales innecesarios. La trazabilidad debe equilibrarse con seguridad y minimización.

Journal o archivos

Una aplicación gestionada por systemd puede enviar salida al journal. También puede utilizar archivos propios. La elección debe facilitar la consulta, rotación, envío y recuperación. No conviene registrar el mismo evento varias veces sin necesidad.

Archivos temporales, cachés y colas

Los archivos temporales y regenerables necesitan rutas y políticas de limpieza explícitas.

Caché

/var/cache/empresa/aplicacion/

Debe poder borrarse sin perder información empresarial, aunque la regeneración pueda afectar temporalmente al rendimiento.

Estado de ejecución

/run/empresa/aplicacion/

Puede contener sockets, PID y otros elementos que solo existen mientras el sistema está activo. Debe recrearse en cada arranque.

Temporales breves

/tmp puede utilizarse para archivos efímeros, pero la aplicación no debe asumir una conservación indefinida. Conviene crear nombres únicos, permisos adecuados y procedimientos de limpieza.

Temporales que deben sobrevivir al reinicio

/var/tmp puede ser más apropiado cuando un proceso largo necesita conservar archivos tras un reinicio. Aun así, debe existir una política de caducidad.

Colas y trabajo pendiente

Las colas empresariales no deben confundirse con caché. Si representan operaciones todavía no completadas, forman parte del estado persistente y deben protegerse.

Scripts operativos y tareas programadas

Los scripts de copia, mantenimiento, importación o comprobación no deberían quedar dispersos entre directorios personales.

Scripts propios de una aplicación

/usr/local/lib/empresa/aplicacion/
├── backup.sh
├── restore.sh
├── health-check.sh
├── cleanup.sh
└── migrate.sh

Comandos administrativos

Puede colocarse un lanzador claro en /usr/local/sbin:

/usr/local/sbin/aplicacion-backup
/usr/local/sbin/aplicacion-health-check

El lanzador puede invocar el script real sin exponer rutas largas al administrador.

No escribir lógica compleja dentro de cron

Una entrada programada debería ejecutar un script versionado y documentado. Los comandos extensos dentro de crontab son difíciles de probar, revisar y trasladar.

Registrar salidas y errores

Cada tarea debe indicar dónde deja resultados y cómo alerta cuando falla. Un proceso programado que funciona en silencio también puede fallar en silencio.

Evitar solapamientos

Los scripts deben controlar si ya existe una ejecución activa cuando el solapamiento puede corromper datos o consumir recursos excesivos.

Copias, exportaciones y archivos de recuperación

La estructura debe facilitar copias selectivas. No todo el árbol necesita la misma frecuencia ni retención.

Qué suele copiarse

• configuración;
• secretos mediante un mecanismo protegido;
• datos persistentes;
• cargas de usuarios;
• scripts propios;
• unidades de servicio;
• documentación operativa;
• referencias de versión.

Qué suele excluirse

• cachés regenerables;
• temporales;
• logs antiguos ya archivados;
• versiones de código que pueden reconstruirse;
• dependencias descargables, cuando exista un procedimiento fiable.

No guardar la única copia dentro del árbol de producción

Una carpeta llamada backup dentro del mismo disco no protege frente a fallo físico, cifrado malicioso, borrado o corrupción general.

Separar exportación de copia

Una exportación puede facilitar migraciones, pero no siempre conserva permisos, metadatos, consistencia o capacidad completa de restauración. Debe definirse qué función cumple cada mecanismo.

La estrategia global puede apoyarse en cómo implementar copias 3-2-1.

Usuarios, grupos y permisos

La estructura solo aporta seguridad si los permisos reflejan las funciones reales.

Usuario de servicio

La aplicación debería ejecutarse con una identidad propia cuando el riesgo lo justifique. Esa cuenta no necesita acceso interactivo salvo que exista una razón documentada.

Grupo administrativo

Un grupo puede permitir que varias personas autorizadas gestionen archivos sin compartir una cuenta.

aplicacion: usuario de servicio
aplicacion-admin: grupo de administradores

Ejemplo de propiedad

Evitar chmod 777

Conceder permisos totales a todos los usuarios oculta el problema de diseño y amplía el impacto de errores o intrusiones. Debe corregirse la propiedad, el grupo o la ruta concreta.

Revisar permisos heredados

La creación de subdirectorios debe conservar permisos adecuados. Puede ser necesario utilizar grupos, umask, ACL o mecanismos de creación controlada.

La administración de identidades puede ampliarse con cómo crear usuarios seguros en Linux para administrar un servidor.

Integración con systemd

La unidad de servicio debe referenciar rutas estables y declarar los directorios que necesita.

[Unit]
Description=Aplicación empresarial
After=network-online.target

[Service]
User=aplicacion
Group=aplicacion
WorkingDirectory=/opt/empresa/aplicacion/current
ExecStart=/opt/empresa/aplicacion/current/bin/start
EnvironmentFile=/etc/empresa/aplicacion/app.env
Restart=on-failure

[Install]
WantedBy=multi-user.target

El ejemplo debe adaptarse a la aplicación real. La unidad no debe incluir secretos directamente si pueden evitarse.

Directorios gestionados por systemd

Systemd puede ayudar a crear rutas de ejecución, estado, caché o logs con la propiedad correcta. Esto reduce comandos manuales durante la instalación.

Rutas absolutas y predecibles

Las unidades no deberían depender del directorio actual de un administrador ni de variables personales. Deben apuntar a ubicaciones empresariales estables.

Validación y recarga

Después de modificar una unidad deben comprobarse su sintaxis, dependencias y estado. La gestión segura de servicios se desarrolla en cómo reiniciar servicios Linux correctamente sin romper nada.

Aplicaciones web y servidores HTTP

Una aplicación web no debería utilizar /var/www como almacén universal. Conviene distinguir el código servido, los archivos públicos, las cargas y la configuración del servidor web.

Ejemplo

/opt/empresa/portal/current/        Código de aplicación
/srv/empresa/portal/public/         Archivos públicos administrados
/var/lib/empresa/portal/uploads/    Cargas de usuarios
/etc/nginx/sites-available/portal   Configuración de nginx
/etc/empresa/portal/                Configuración de aplicación
/var/log/nginx/portal-access.log    Accesos HTTP
/var/log/empresa/portal/            Logs de aplicación

Raíz pública mínima

El servidor HTTP debe exponer únicamente los archivos necesarios. Configuración, secretos, copias y código interno no deben quedar dentro de una ruta pública.

Uploads fuera de la release

Los archivos subidos por usuarios deben sobrevivir a los despliegues y aplicar validación, permisos y copias propias.

Separar proxy y aplicación

Nginx o Apache pueden gestionar TLS, límites y entrega estática, mientras la aplicación se ejecuta con un usuario y puerto interno. Las responsabilidades deben ser visibles.

Aplicaciones desplegadas con contenedores

Los contenedores no eliminan la necesidad de una estructura clara. Trasladan parte de la organización a imágenes, volúmenes, archivos de composición y secretos.

Proyecto de despliegue

/opt/empresa/aplicacion-container/
├── compose.yaml
├── env.example
├── scripts/
└── docs/

Datos persistentes

Los volúmenes deben tener una ubicación, propietario, copia y procedimiento de restauración conocidos. Un volumen con nombre automático puede ser difícil de identificar durante una incidencia.

No introducir datos dentro de la imagen

La imagen debe ser sustituible. Los datos empresariales y secretos no deberían formar parte de ella.

Logs

Debe definirse si se envían a stdout, journal, un controlador de logs o archivos montados. La retención sigue siendo necesaria.

Controlar versiones

Las etiquetas genéricas como latest dificultan reproducir y revertir. Conviene fijar versiones y registrar cuándo se actualizan.

El uso proporcionado de contenedores puede ampliarse con cómo usar contenedores en PYMES.

Separación entre producción, pruebas y desarrollo

Los entornos deben distinguirse de forma visible para reducir errores.

Servidores separados

Es la opción más clara cuando el riesgo y el presupuesto lo justifican. Cada servidor mantiene la misma estructura, pero con configuración y datos propios.

Separación dentro del mismo servidor

En entornos pequeños puede utilizarse una jerarquía explícita:

/opt/empresa/produccion/aplicacion/
/opt/empresa/pruebas/aplicacion/

/etc/empresa/produccion/aplicacion/
/etc/empresa/pruebas/aplicacion/

/var/lib/empresa/produccion/aplicacion/
/var/lib/empresa/pruebas/aplicacion/

Esta solución exige usuarios, puertos, bases y permisos separados. Un simple sufijo en el nombre no garantiza aislamiento.

No utilizar datos reales sin control

Las pruebas deben utilizar datos generados, anonimizados o limitados. Copiar producción completa por comodidad aumenta riesgo y dificulta cumplir políticas de protección.

Mantener simetría

Los entornos deberían conservar una estructura equivalente para que los procedimientos puedan repetirse, aunque su capacidad sea diferente.

Convenciones de nombres

Los nombres deben permitir identificar función y evitar ambigüedades.

Características recomendables

• minúsculas;
• guiones cuando mejoran legibilidad;
• sin espacios;
• sin nombres personales;
• sin abreviaturas oscuras;
• sin fechas salvo en versiones o archivos históricos;
• coherencia entre rutas, servicios, usuarios y logs.

Ejemplo coherente

Aplicación: gestor-matriculas
Usuario: gestor-matriculas
Servicio: gestor-matriculas.service
Configuración: /etc/empresa/gestor-matriculas/
Datos: /var/lib/empresa/gestor-matriculas/
Logs: /var/log/empresa/gestor-matriculas/

Evitar nombres temporales permanentes

Directorios como nuevo, final, prueba2 o antiguo-bueno pierden significado rápidamente. Las versiones deben identificarse mediante un sistema objetivo.

No incluir datos que cambian

Un nombre de ruta no debería depender del responsable actual, el proveedor o una ubicación física que puede cambiar.

Ejemplo completo de aplicación empresarial

Una microempresa dispone de una aplicación interna que recibe formularios, valida datos, genera documentos y envía resultados a un sistema externo.

/opt/empresa/gestor-solicitudes/
├── releases/
│   ├── 2.3.0/
│   └── 2.4.0/
├── current -> releases/2.4.0/
└── shared/
    └── docs/

/etc/empresa/gestor-solicitudes/
├── application.conf
├── integrations.conf
├── logging.conf
└── secrets/
    ├── database-password
    └── external-api-token

/var/lib/empresa/gestor-solicitudes/
├── incoming/
├── validated/
├── rejected/
├── generated/
├── state/
└── queues/

/var/log/empresa/gestor-solicitudes/
├── application.log
├── error.log
└── audit.log

/var/cache/empresa/gestor-solicitudes/
/run/empresa/gestor-solicitudes/

/usr/local/lib/empresa/gestor-solicitudes/
├── backup.sh
├── restore.sh
├── cleanup.sh
└── health-check.sh

Qué se despliega

Solo se crea una nueva carpeta en releases y se actualiza el enlace current después de validar la versión.

Qué se conserva

Configuración, secretos, datos, colas y logs permanecen fuera de la release.

Qué se copia

Se copian configuración, secretos protegidos, datos persistentes, scripts y documentación. La caché y los temporales se excluyen.

Qué puede eliminarse

Las releases antiguas pueden retirarse después del periodo de reversión. La caché puede limpiarse. Los logs se eliminan según retención.

Qué permite recuperar

En otro servidor puede instalarse la release, restaurarse configuración y datos, recrearse el usuario del servicio y activar la unidad.

Ejemplo aplicado a una plataforma LMS

Una empresa de formación online puede separar la plataforma, los contenidos fuente, los archivos publicados, las cargas de alumnos y las copias.

/opt/empresa/lms/                 Código y releases
/etc/empresa/lms/                 Configuración del LMS
/var/lib/empresa/lms/database/    Estado de base de datos si corresponde
/var/lib/empresa/lms/uploads/     Archivos aportados por usuarios
/srv/empresa/lms/content/         Contenido publicado
/srv/empresa/lms/downloads/       Materiales descargables
/var/log/empresa/lms/             Logs de aplicación
/var/cache/empresa/lms/           Cachés regenerables

Contenidos fuente fuera del LMS

Guiones, vídeos originales, documentos editables y ejercicios maestros no deberían existir únicamente dentro de la plataforma publicada. Necesitan un repositorio fuente con versiones y copias.

Archivos de alumnos

Las entregas y cargas deben estar protegidas, asociadas a usuarios y sometidas a políticas de conservación. No deben mezclarse con recursos públicos.

Separar publicación y producción

El contenido que consume el alumno puede estar optimizado o convertido. Los originales deben conservarse de forma independiente.

Restauración coherente

La base de datos y los archivos deben recuperarse de forma consistente. Restaurar una copia de uno sin el otro puede dejar referencias rotas.

Campañas y crecimiento

Separar logs, cachés, uploads y contenidos facilita controlar el espacio y detectar qué componente crece. Este análisis se ampliará en el artículo específico sobre cómo controlar el crecimiento del espacio en disco.

Cómo migrar una estructura desordenada

Reorganizar un servidor en producción debe hacerse por fases. Mover carpetas sin comprender dependencias puede interrumpir el servicio.

Paso 1. Inventariar

Registrar procesos, servicios, puertos, usuarios, tareas programadas y rutas abiertas. Puede utilizarse el método de cómo inventariar servicios instalados en un servidor Linux.

Paso 2. Clasificar archivos

• código;
• configuración;
• secretos;
• datos persistentes;
• logs;
• temporales;
• copias;
• archivos obsoletos.

Paso 3. Diseñar el destino

Crear la estructura nueva y asignar propietarios antes de mover producción.

Paso 4. Probar con una copia

Reproducir el servicio en un entorno de pruebas o con una copia controlada. Validar rutas absolutas, permisos, enlaces, scripts y copias.

Paso 5. Preparar compatibilidad temporal

Los enlaces simbólicos pueden facilitar una transición, pero deben documentarse y retirarse. No conviene convertirlos en una capa permanente de rutas históricas.

Paso 6. Planificar la intervención

Definir copia previa, parada, sincronización final, cambio, validación y reversión.

Paso 7. Actualizar servicios y tareas

Modificar unidades, cron, configuraciones, scripts, monitorización y copias. Buscar referencias antiguas.

Paso 8. Validar resultado empresarial

No basta con comprobar que el proceso está activo. Debe verificarse que la aplicación atiende solicitudes, escribe datos, genera archivos y envía integraciones correctamente.

Paso 9. Retirar rutas antiguas

Después de un periodo prudente, eliminar duplicados y enlaces temporales para evitar que reaparezcan dependencias.

Cómo auditar la estructura

Una revisión periódica debe comprobar que la jerarquía sigue representando la realidad.

Preguntas de auditoría

• ¿Cada aplicación tiene una raíz identificable?
• ¿El código está separado de los datos?
• ¿Las versiones activas pueden identificarse?
• ¿La configuración tiene una fuente oficial?
• ¿Los secretos están protegidos?
• ¿Los logs tienen rotación?
• ¿Las cachés pueden borrarse sin perder datos?
• ¿Las tareas programadas utilizan scripts controlados?
• ¿Las copias incluyen lo necesario y excluyen lo regenerable?
• ¿Los usuarios y grupos siguen siendo correctos?
• ¿Existen carpetas huérfanas?
• ¿Quedan versiones antiguas sin propietario?
• ¿Hay rutas personales utilizadas por producción?
• ¿La estructura puede reproducirse en otro servidor?

Buscar crecimiento inesperado

Conviene revisar tamaño por rutas para descubrir logs, temporales, uploads o releases que crecen sin control.

Comparar con documentación

La ficha del servidor debe coincidir con las rutas reales. La documentación específica puede estructurarse siguiendo cómo documentar correctamente un servidor Linux.

Probar la recuperación

La mejor auditoría consiste en reconstruir la aplicación en un entorno controlado. Si faltan rutas, permisos o secretos, la estructura todavía no está suficientemente definida.

Errores frecuentes

Guardar todo dentro de /var/www

Mezcla código público, configuración, cargas, copias y datos. Aumenta exposición y dificulta despliegues.

Ejecutar producción desde /home

Vincula el servicio a una cuenta personal y confunde trabajo de desarrollo con operación.

Colocar datos dentro de cada release

Una actualización puede duplicarlos, perderlos o dejarlos asociados a una versión antigua.

Guardar secretos en el repositorio

Las credenciales se propagan por historial, copias y equipos.

No aplicar rotación de logs

Un archivo puede llenar el disco y detener servicios no relacionados.

Usar permisos globales

chmod 777 evita comprender quién necesita acceso y amplía el riesgo.

Crear demasiados niveles

Una jerarquía excesiva aumenta longitud y mantenimiento sin aportar aislamiento real.

Mezclar varias convenciones

Una aplicación utiliza /opt, otra una carpeta personal y otra /usr/local/share sin criterio común. El servidor se vuelve impredecible.

No diferenciar caché y estado

Borrar una supuesta caché puede eliminar colas o información necesaria para continuar procesos.

Guardar copias en el mismo árbol

No protege frente a fallos generales y duplica espacio sin estrategia.

No actualizar tareas programadas

Después de una migración, cron o scripts pueden seguir escribiendo en rutas antiguas.

Conservar enlaces simbólicos indefinidamente

Las capas de compatibilidad ocultan la estructura real y complican futuras intervenciones.

Diseñar sin considerar la recuperación

Una estructura elegante puede ser inútil si nadie sabe qué copiar ni cómo reconstruirla.

Lista de comprobación

Preguntas frecuentes

Conclusión

Diseñar una estructura de directorios propia para aplicaciones empresariales significa convertir el sistema de archivos en una parte explícita de la arquitectura.

El código, la configuración, los secretos, los datos, los logs, las cachés, los temporales y los scripts tienen ciclos de vida diferentes. Separarlos permite actualizar sin sobrescribir información, copiar únicamente lo necesario, aplicar permisos precisos y recuperar el servicio con menos incertidumbre.

La mejor estructura no es la que utiliza más carpetas, sino la que permite saber qué puede sustituirse, qué debe conservarse, quién puede modificarlo y cómo se reconstruye el servicio.

Linux ya ofrece convenciones útiles mediante /opt, /srv, /etc, /var/lib, /var/log, /var/cache, /run y /usr/local. La empresa debe utilizarlas con criterio, sin crear una jerarquía paralela difícil de comprender.

Una aplicación pequeña puede empezar con cuatro rutas bien definidas. A medida que crece, puede incorporar releases, datos compartidos, colas, scripts y separación de entornos. La complejidad debe aparecer únicamente cuando resuelve una necesidad real.

La estructura debe mantenerse junto con la documentación, las copias, los servicios y los procedimientos de cambio. Cada nueva aplicación debe seguir el mismo criterio o justificar claramente su excepción.

Cuando los directorios reflejan responsabilidades y ciclos de vida, el servidor deja de ser una acumulación de archivos y se convierte en una plataforma que puede administrarse, migrarse y evolucionar con control.

ESTUDIO METADATOS desarrolla programas de formación online orientados a comprender y aplicar tecnología en entornos profesionales reales. Puedes consultar sus programas de formación tecnológica para profundizar en Linux, servidores, automatización, seguridad, datos y continuidad operativa.