Usar un Storage Server con WordPress: qué funciona y qué no

El directorio wp-content/uploads es la parte de WordPress que crece sin frenos. Imágenes, archivos PDF, vídeos, y de cada imagen varios tamaños que WordPress genera automáticamente. Después de unos años hay allí decenas de gigabytes, y el espacio en el servidor web es el más caro que se puede comprar.

Un Storage Server cuesta una fracción de eso. La única pregunta es qué se puede mover fuera de verdad. En internet hay mucho escrito sobre esto que en la práctica no funciona. Este artículo separa los tres casos con limpieza.

Los tres casos de un vistazo

El último punto es el que hace tropezar a la mayoría. Por eso, primero la verdad incómoda.

Por qué no hay plugin para la biblioteca de medios

Los plugins de externalización conocidos para WordPress hablan todos el mismo idioma: S3. Se conectan con Amazon S3 o con un servicio compatible, suben allí el archivo, borran la copia local y sustituyen la dirección en la entrada por una dirección pública del servicio.

Justo eso no se puede trasladar a un Storage Server, y por dos razones:

• El almacenamiento habla SMB, SFTP y WebDAV, pero no S3.
• No existe una dirección pública por archivo. Cada acceso va autenticado, así que no puede haber un enlace que el navegador del visitante llame directamente.

Hay plugins sueltos que trabajan con FTP, pero ninguno con difusión apreciable y mantenimiento actual que mueva la biblioteca de medios por completo por SFTP o WebDAV. Quien encuentre uno debería mirar antes de usarlo la fecha de la última actualización y el número de instalaciones activas.

El camino que funciona: montar en lugar de mover fuera

En un servidor propio con permisos de root se le da la vuelta al asunto. En lugar de enseñar a WordPress a hablar con almacenamiento ajeno, se lleva el almacenamiento al sitio en el que WordPress escribe de todas formas:

apt install -y cifs-utils
mkdir -p /mnt/storage
printf 'username=u123456-sub1\npassword=TU_CONTRASENA\n' > /etc/samba/storage.cred
chmod 600 /etc/samba/storage.cred

Entrada en /etc/fstab:

//u123456.storage.kernelhost.net/backup /mnt/storage cifs credentials=/etc/samba/storage.cred,uid=www-data,gid=www-data,file_mode=0660,dir_mode=0770,seal,_netdev,nofail 0 0

Después, mudar los archivos existentes y sustituir el directorio:

mount -a
mkdir -p /mnt/storage/uploads
rsync -a /var/www/example.com/wp-content/uploads/ /mnt/storage/uploads/
mv /var/www/example.com/wp-content/uploads /var/www/example.com/wp-content/uploads.alt
ln -s /mnt/storage/uploads /var/www/example.com/wp-content/uploads

WordPress no nota nada, para la aplicación es una ruta totalmente normal. El directorio antiguo se queda como uploads.alt hasta que hayas comprobado que todo funciona. Bórralo solo entonces, no antes.

La trampa que hay aquí: las miniaturas

WordPress genera de cada imagen varios tamaños y los carga en cada visita de página. Si esos archivos pequeños están en el almacenamiento en red, se suma la latencia de red por archivo, y una galería con cuarenta imágenes espera cuarenta veces.

Dos soluciones, las dos buenas:

• Poner una caché por delante, por ejemplo una caché en el servidor web que mantenga en local los archivos entregados.
• Poner en el almacenamiento solo los originales y dejar en local los tamaños generados. Es algo más de trabajo, pero es el camino más limpio para páginas con muchas imágenes.

Copias de seguridad: el beneficio más rápido

Si solo haces una cosa, que sea esta. Una copia de seguridad en el mismo servidor no es una copia de seguridad: si el disco se borra o la web se cifra, se va con ella. En almacenamiento separado sobrevive.

El plugin gratuito WPvivid puede, en su versión base, copiar al almacenamiento por SFTP, con programación y regla de retención. La guía completa está en Copias de seguridad de WordPress en el Storage Server.

En un servidor propio se puede hacer aún mejor, es decir con rsync o BorgBackup directamente desde una tarea programada. Entonces transfieres solo los cambios, y BorgBackup además deduplica.

Entregar descargas grandes

Para archivos que los visitantes deban descargar, el almacenamiento es ideal: se leen pocas veces, son grandes, y no tienen que ser rápidos, solo llegar. El acceso va por un pequeño script que antes comprueba el permiso:

<?php
// en el functions.php o como plugin propio
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('Inicia sesión, por favor', '', ['response' => 403]);
    }

    $pfad = '/mnt/storage/downloads/' . basename($_GET['kh_download']);
    if (!is_readable($pfad)) {
        wp_die('Archivo no encontrado', '', ['response' => 404]);
    }

    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="' . basename($pfad) . '"');
    header('Content-Length: ' . filesize($pfad));
    readfile($pfad);
    exit;
});

El ejemplo parte de un almacenamiento montado. Sin montarlo, sustituyes readfile() por una llamada SFTP o WebDAV, como se describe en Usar un Storage Server para tu web.

El efecto secundario es agradable: como el archivo nunca tiene una dirección pública, nadie puede pasar el enlace a otros. La comprobación de permisos no se puede saltar.

Qué queda en hosting compartido

En hosting compartido, WebDAV sobre HTTPS es el camino más fiable, porque el puerto 443 prácticamente nunca está bloqueado. SFTP funciona igualmente, pero en nuestro caso va por el puerto 23, y no todos los proveedores permiten conexiones de salida en puertos así. Eso conviene comprobarlo brevemente antes de pedir.

Una subcuenta por fin

Cada Storage Server permite hasta 100 subcuentas, cada una con su propio directorio inicial, su propia contraseña y sus propios protocolos habilitados. Para WordPress eso significa al menos dos:

• Una cuenta para la web, que solo ve /uploads.
• Una cuenta para las copias de seguridad, que solo ve /backup.

Si algún día te toman la web, el atacante encuentra en el wp-config.php las credenciales de la primera cuenta. Las copias de seguridad quedan intactas, porque esa cuenta ni las conoce. Con una única cuenta principal, en ese punto se habría perdido todo.

Cuando varios usuarios necesitan espacio propio

Un Storage Server no conoce ninguna cuota por subcuenta. Una cuenta se queda en su directorio, pero allí puede llenar todo el plan. Quien quiera dar a clientes, fotógrafos o redactores un cupo limitado a cada uno pone por delante una aplicación que se encargue de ello. Nextcloud es la opción más evidente para eso, trae usuarios, cuotas y enlaces de compartición: Conectar Nextcloud con el Storage Server.

Qué plan encaja

Para una sola web de WordPress con copias de seguridad, Storage-1 suele bastar por mucho tiempo. Quien mueva fuera las bibliotecas de medios de varias páginas o trabaje con vídeo llega rápido a Storage-2 o Storage-3. Todos los planes están en Alemania, vienen sin cuota de instalación, se facturan en modalidad de prepago y no tienen permanencia mínima. Pasar al plan siguiente más grande es posible en cualquier momento, sin tocar los datos.