Usar un Storage Server para tu web: imágenes, descargas, archivos

En un servidor web el espacio en disco es el bien más caro. Está en SSD NVMe rápidas, construidas para bases de datos y PHP, y se encarece de forma notable con cada gigabyte. Al mismo tiempo allí hay cosas que nunca necesitan esa velocidad: fotos originales, archivos de vídeo, archivos de descarga, copias de seguridad antiguas.

Un Storage Server cuesta una fracción de eso y se lleva exactamente esa carga. Este artículo muestra qué tiene sentido mover fuera, qué protocolo funciona desde el servidor web, cómo llegan los archivos de forma segura a los visitantes y dónde están los límites.

Qué vale la pena mover fuera, y qué no

La línea de separación es sencilla: lo que se lee pocas veces y se transfiere una vez en bloque va al almacenamiento. Lo que se carga en cada visita de página se queda donde es rápido.

Qué es un Storage Server, y qué no es

Un Storage Server es almacenamiento en red con cuentas de usuario. Te conectas con credenciales y lees o escribes archivos. No es un almacenamiento de objetos con direcciones públicas y no es un CDN.

En la práctica eso significa: en tu página no puedes enlazar una imagen directamente al almacenamiento, porque cada acceso va autenticado. Tu servidor web recoge el archivo y lo pasa, o bien generas tú mismo enlaces de descarga con validez limitada. Cómo se hace esto con limpieza está más abajo.

Suena a limitación, pero tiene una ventaja: nadie puede hacerse con tus archivos adivinando direcciones o pasando un enlace a otros. El acceso va siempre por tu aplicación, y por tanto por tus reglas.

El patrón que funciona en la práctica

Tres pasos, no es más:

1. Los originales están en el almacenamiento. Se suben una vez y después casi no se tocan.
2. Las versiones derivadas se generan una vez y están en el servidor web. Es decir miniaturas, variantes recortadas, versiones comprimidas. Son pequeñas y hacen falta en cada visita de página.
3. Las descargas van por tu aplicación. Un pequeño script comprueba el permiso, recoge el archivo del almacenamiento y lo entrega.

Quien le dé la vuelta a esto y recoja las miniaturas del almacenamiento en cada visita se construye una web lenta. La latencia de red por archivo se acumula, y una galería con cuarenta imágenes espera cuarenta veces.

Qué protocolo para cada caso

La decisión más importante no depende del gusto, sino de tus permisos: en un servidor propio montas el almacenamiento como directorio, y cualquier aplicación puede usarlo sin saber nada de ello. Cómo se hace está en Montar el Storage Server como unidad de red.

En hosting compartido no tienes permisos de root, así que montar queda descartado. Allí el camino va por WebDAV o SFTP desde la aplicación, y WebDAV es normalmente la menor resistencia, porque el puerto 443 prácticamente nunca está bloqueado.

Configurar el acceso desde PHP

Para SFTP basta una biblioteca de PHP puro, no hace falta ninguna extensión en el servidor:

composer require phpseclib/phpseclib:~3.0

use phpseclib3\Net\SFTP;

$sftp = new SFTP('u123456.storage.kernelhost.net', 23);
if (!$sftp->login('u123456-sub1', $passwort)) {
    throw new RuntimeException('Error de autenticación');
}

// Subir un archivo
$sftp->put('/bilder/2026/original.jpg', '/tmp/upload.jpg', SFTP::SOURCE_LOCAL_FILE);

// Leer un archivo
$inhalt = $sftp->get('/bilder/2026/original.jpg');

Para WebDAV basta incluso con la extensión curl que ya viene incorporada:

$ch = curl_init('https://u123456.storage.kernelhost.net/bilder/2026/original.jpg');
curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_USERPWD        => 'u123456-sub1:' . $passwort,
    CURLOPT_TIMEOUT        => 30,
]);
$inhalt = curl_exec($ch);
curl_close($ch);

Los dos ejemplos usan una subcuenta, no la cuenta principal. Por qué, lo explica el apartado siguiente.

Una subcuenta propia para cada fin

Cada Storage Server permite hasta 100 subcuentas, y eso en todos los planes. Cada una recibe:

• un directorio inicial propio del que no puede salir,
• una contraseña propia,
• protocolos habilitados propios, es decir por ejemplo solo SFTP y nada de Samba.

Para una web eso significa: una subcuenta para el servidor web, que solo puede SFTP y solo ve /web, y una segunda para la copia de seguridad, que solo ve /backup. Si algún día te toman el servidor web, el atacante no llega a las copias de seguridad, porque esa cuenta ni las conoce.

Hay un límite: una subcuenta no recibe un cupo de espacio propio. Se queda en su directorio, pero allí puede llenar todo el almacenamiento del plan. Quien quiera limitar de verdad a usuarios concretos necesita por delante una aplicación que se encargue de ello. Conectar Nextcloud con el Storage Server muestra exactamente este montaje.

Entregar descargas de forma segura

El error más frecuente es dejar que las credenciales lleguen al navegador, por ejemplo con un enlace que lleva usuario y contraseña. Lo correcto es que tu servidor establezca la conexión y pase el archivo:

<?php
// Comprobar el permiso antes de que ocurra cualquier otra cosa
if (!nutzer_darf_datei($_GET['id'])) {
    http_response_code(403);
    exit;
}

$sftp = neue_verbindung();
$datei = $sftp->get(pfad_zu($_GET['id']));

header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="dokument.pdf"');
header('Content-Length: ' . strlen($datei));
echo $datei;

Con archivos muy grandes es mejor leer en bloques en lugar de cargar todo en memoria, porque si no revienta el límite de memoria de PHP. Para eso pon ob_end_flush() y entrega el archivo por partes.

Quien espere muchas descargas simultáneas debería tener en cuenta además que cada descarga en marcha ocupa un proceso de PHP. A partir de cierto orden de magnitud, algo así va detrás de un servidor propio y no detrás de hosting compartido.

Copiar la web al almacenamiento

Es la entrada más sencilla, y aporta algo de inmediato. Con rsync transfieres solo los cambios:

rsync -az --delete -e "ssh -p 23" \
      /var/www/example.com/ \
      u123456-sub2@u123456.storage.kernelhost.net:/backup/web/

Para copias de seguridad con deduplicación y cifrado, BorgBackup es la mejor elección, está disponible de forma nativa en el almacenamiento. A eso se suman las instantáneas (snapshots) del propio almacenamiento como segundo nivel: según el plan, 10, 20, 30 o 40 instantáneas manuales, más otras tantas automáticas en ritmo diario, semanal y mensual.

La diferencia con una copia de seguridad en el mismo servidor es la decisiva: un disco borrado o cifrado se lleva consigo una copia local, una copia en almacenamiento separado no.

Antes de empezar: dos interruptores

En el área de cliente encontrarás en el Storage Server el botón "Ajustes de acceso". Dos cosas tienen que estar bien:

• La accesibilidad externa tiene que estar activada, porque si no tu servidor web no llega al almacenamiento por internet.
• El protocolo que quieras tiene que estar habilitado, es decir Samba para SMB, SSH para SFTP y rsync, WebDAV para la vía HTTPS.

En los servidores recién pedidos todo eso está activo. Quien desactive por seguridad lo que no necesita debería acordarse de que eso es justamente después la causa más frecuente de "ya no funciona".

Qué plan encaja

Todos los Storage Server están en Alemania, hablan FTP, FTPS, SFTP, SCP, Samba, WebDAV y WebDAVs, traen rsync y BorgBackup de forma nativa y tienen IPv4 e IPv6. No hay cuota de instalación, la facturación es de prepago y sin permanencia mínima. Así que puedes empezar con 1 TB y ampliar más tarde, sin mudarte.

Un ejemplo de cálculo: 1 TB de espacio adicional en un servidor web cuesta, según el proveedor, varias veces 9,99 euros al mes, y además queda en la misma máquina que la web. El almacenamiento de al lado no solo es más barato, también está separado.