Utiliser un Storage Server pour son site web : images, téléchargements, archives

Sur un serveur web, l'espace disque est le bien le plus cher. Il repose sur des SSD NVMe rapides, conçues pour les bases de données et PHP, et chaque gigaoctet se paie nettement. Or on y trouve en même temps des choses qui n'ont jamais besoin de cette vitesse : photos originales, fichiers vidéo, archives de téléchargement, anciennes sauvegardes.

Un Storage Server coûte une fraction de ce prix et reprend exactement cette charge. Cet article montre ce qu'il est judicieux de déporter, quel protocole fonctionne depuis le serveur web, comment les fichiers arrivent en toute sécurité chez les visiteurs, et où se situent les limites.

Ce qu'il vaut la peine de déporter, et ce qui doit rester

La ligne de partage est simple : ce qui est rarement lu et transféré une fois en gros volume appartient au stockage. Ce qui est chargé à chaque affichage de page reste là où c'est rapide.

Ce qu'est un Storage Server, et ce qu'il n'est pas

Un Storage Server est un stockage réseau avec des comptes utilisateurs. Vous vous connectez avec des identifiants et vous lisez ou écrivez des fichiers. Ce n'est pas un stockage objet avec des adresses publiques, et ce n'est pas un CDN.

Concrètement : vous ne pouvez pas placer dans votre page un lien d'image qui pointe directement vers le stockage, car chaque accès est authentifié. Votre serveur web récupère le fichier et le transmet, ou bien vous générez vous-même des liens de téléchargement à durée limitée. La façon propre de procéder se trouve plus bas.

Cela ressemble à une restriction, mais c'est aussi un avantage : personne ne peut récupérer vos fichiers en devinant des adresses ou en faisant circuler un lien. L'accès passe toujours par votre application, et donc par vos règles.

Le schéma qui fonctionne en pratique

Trois étapes, pas plus :

1. Les originaux se trouvent sur le stockage. Ils sont téléversés une fois, puis rarement touchés.
2. Les versions dérivées sont créées une fois et restent sur le serveur web. Autrement dit les vignettes, les variantes recadrées, les versions compressées. Elles sont petites, et elles servent à chaque affichage de page.
3. Les téléchargements passent par votre application. Un petit script vérifie l'autorisation, récupère le fichier sur le stockage et le renvoie.

Qui inverse ce schéma et va rechercher les vignettes sur le stockage à chaque appel se construit un site web lent. Le temps de trajet réseau s'additionne pour chaque fichier, et une galerie de quarante images attend quarante fois.

Quel protocole pour quel cas

La décision la plus importante ne dépend pas du goût, mais de vos droits : sur un serveur root, vous montez le stockage comme un répertoire, et chaque application peut l'utiliser sans rien en savoir. La marche à suivre figure dans Monter un Storage Server en lecteur réseau.

Sur un hébergement mutualisé, vous n'avez pas les droits root, le montage est donc exclu. La voie passe alors par WebDAV ou SFTP depuis l'application, et WebDAV offre en général la moindre résistance, car le port 443 n'est pratiquement jamais bloqué.

Mettre en place l'accès depuis PHP

Pour SFTP, une bibliothèque purement PHP suffit, aucune extension n'est nécessaire sur le serveur :

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('Échec de la connexion');
}

// Téléverser un fichier
$sftp->put('/bilder/2026/original.jpg', '/tmp/upload.jpg', SFTP::SOURCE_LOCAL_FILE);

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

Pour WebDAV, l'extension curl intégrée suffit même :

$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);

Les deux exemples utilisent un sous-compte, pas le compte principal. La raison figure dans la section suivante.

Un sous-compte par usage

Chaque Storage Server autorise jusqu'à 100 sous-comptes, et ce dans chaque forfait. Chacun reçoit :

• son propre répertoire de départ, dont il ne peut pas sortir,
• son propre mot de passe,
• ses propres autorisations de protocole, par exemple SFTP uniquement et pas Samba.

Pour un site web, cela donne : un sous-compte pour le serveur web, qui ne peut faire que du SFTP et ne voit que /web, et un second pour la sauvegarde, qui ne voit que /backup. Si le serveur web est un jour compromis, l'attaquant n'atteint pas les sauvegardes, car ce compte ne les connaît même pas.

Il y a une limite : un sous-compte ne reçoit pas de quota d'espace propre. Il reste dans son répertoire, mais il peut y remplir tout le stockage du forfait. Pour vraiment limiter des utilisateurs individuels, il faut une application en amont qui s'en charge. Connecter Nextcloud au Storage Server montre exactement ce montage.

Diffuser les téléchargements en toute sécurité

L'erreur la plus fréquente consiste à laisser les identifiants parvenir au navigateur, par exemple à travers un lien contenant le nom d'utilisateur et le mot de passe. La bonne méthode veut que votre serveur établisse la connexion et transmette le fichier :

<?php
// Vérifier l'autorisation avant que quoi que ce soit ne se passe
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;

Pour les fichiers très volumineux, il vaut mieux lire par blocs que de tout charger en mémoire, sinon la limite de mémoire de PHP éclate. Utilisez pour cela ob_end_flush() et envoyez le fichier morceau par morceau.

Si vous attendez beaucoup de téléchargements simultanés, pensez en outre que chaque téléchargement en cours occupe un processus PHP. À partir d'un certain ordre de grandeur, cela demande un serveur root plutôt qu'un hébergement mutualisé.

Sauvegarder le site web sur le stockage

C'est l'entrée en matière la plus simple, et elle sert immédiatement. Avec rsync, vous ne transférez que les modifications :

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

Pour des sauvegardes avec déduplication et chiffrement, BorgBackup est le meilleur choix, il est disponible nativement sur le stockage. S'y ajoutent les snapshots du stockage lui-même comme deuxième niveau : selon le forfait 10, 20, 30 ou 40 snapshots manuels, plus autant d'automatiques au rythme quotidien, hebdomadaire et mensuel.

La différence avec une sauvegarde sur le même serveur est décisive : un disque effacé ou chiffré emporte avec lui une sauvegarde locale, pas une sauvegarde sur un stockage séparé.

Avant de commencer : deux options

Dans l'espace client, vous trouvez sur le Storage Server le bouton « Paramètres d'accès ». Deux choses doivent être correctes :

• Accessibilité externe doit être activée, sinon votre serveur web n'atteint pas le stockage via Internet.
• Le protocole souhaité doit être autorisé, donc Samba pour SMB, SSH pour SFTP et rsync, WebDAV pour la voie HTTPS.

Sur les serveurs nouvellement commandés, tout cela est actif. Si vous désactivez par prudence ce dont vous n'avez pas besoin, souvenez-vous que c'est précisément là la cause la plus fréquente du « ça ne marche plus » constaté par la suite.

Quel forfait convient

Tous les Storage Server se trouvent en Allemagne, parlent FTP, FTPS, SFTP, SCP, Samba, WebDAV et WebDAVs, embarquent rsync et BorgBackup nativement et disposent d'IPv4 et d'IPv6. Il n'y a pas de frais de mise en service, la facturation se fait en PrePaid sans durée minimale. Vous pouvez donc commencer avec 1 TB et passer plus tard à une taille supérieure, sans déménager.

Un exemple de calcul : 1 TB d'espace supplémentaire sur un serveur web coûte, selon l'hébergeur, plusieurs fois 9,99 € par mois, et il se trouve alors sur la même machine que le site web. Le stockage à côté n'est pas seulement moins cher, il est aussi séparé.