Pocas siglas se confunden tanto como NAS y SAN. Se parecen hasta en las letras (son casi anagramas), ambos son "cajas de almacenamiento conectadas a la red", y mucha gente los usa como sinónimos. No lo son, y la diferencia no es un tecnicismo: define para qué sirve cada uno. La distinción cabe en una frase: el NAS entrega archivos; el SAN entrega bloques. Todo lo demás se deriva de ahí.
El NAS: te entrega archivos
Un NAS (Network Attached Storage) es, en esencia, un servidor de archivos especializado. Tiene su propio sistema operativo y gestiona él mismo el sistema de archivos. Tú, desde tu equipo, montas una carpeta compartida y trabajas con archivos: los copias, los abres, los editas. La comunicación usa protocolos de archivos: SMB (el de las carpetas compartidas de Windows) y NFS (el equivalente en el mundo Unix/Linux). Todo viaja por tu red normal.
El NAS es la respuesta natural para compartir archivos: documentos de la empresa, respaldos, carpetas de equipos, un lugar central donde todos guardan y acceden. Es relativamente simple de montar y administrar, y para la mayoría de las necesidades de almacenamiento compartido de una PyME, un NAS es exactamente lo que se necesita.
El SAN: te entrega bloques crudos
Un SAN (Storage Area Network) trabaja un nivel más abajo. En lugar de entregarte archivos, te entrega bloques de almacenamiento crudos —lo que se llama un LUN—, y tu servidor los ve como si fueran un disco local conectado directamente. El SAN no sabe ni le importa qué archivos guardas; solo entrega bloques. Es el servidor quien le pone encima su propio sistema de archivos y lo gestiona, igual que haría con un disco físico interno.
Esa comunicación de bloques usa protocolos distintos y suele correr sobre una red dedicada de alto rendimiento: iSCSI (bloques sobre red IP), Fibre Channel (una red exclusiva de almacenamiento) o SAS. El SAN es la respuesta para lo que exige máximo rendimiento y acceso a nivel de bloque: bases de datos, el almacén de máquinas virtuales de un clúster de virtualización, aplicaciones críticas. Es más complejo y más caro, y se justifica cuando el NAS se queda corto en rendimiento o cuando una aplicación exige un disco de bloques, no una carpeta.
Por qué la diferencia importa en la práctica
El punto no es cuál es "mejor", sino cuál encaja:
- Quieres que varios usuarios compartan y accedan a archivos: NAS. Los protocolos de archivos están hechos para el acceso compartido y concurrente.
- Un servidor o aplicación necesita un disco de alto rendimiento a nivel de bloque (una base de datos, un datastore de VMs): SAN. Le das lo que espera —un disco crudo— con el rendimiento de una red dedicada.
- Necesitas ambas cosas: hoy muchos sistemas de almacenamiento unificados hacen las dos, presentando archivos por SMB/NFS y bloques por iSCSI desde la misma caja. La línea se difumina en el equipo, pero el concepto —archivos vs bloques— sigue siendo la clave para pedir bien.
La trampa de comprar por sigla
El error caro es elegir por moda o por sigla impresionante. Montar un SAN carísimo para lo que un NAS resolvía —compartir archivos— es tirar dinero y complejidad. Intentar correr una base de datos exigente sobre un recurso de archivos cuando pedía bloques es pelear con la herramienta. La pregunta correcta nunca es "¿NAS o SAN?" en abstracto, sino "¿mi aplicación quiere archivos o bloques, y qué rendimiento necesita?". Responder eso —y no dejarse llevar por lo que suena más sofisticado— es lo que distingue una arquitectura de almacenamiento bien pensada de una cara e inadecuada.