Usar um Storage Server para o seu site: imagens, downloads, arquivos

Num servidor web, o espaço em disco é o bem mais caro. Está em SSD NVMe rápidos, feitos para bases de dados e PHP, e encarece de forma sensível com cada gigabyte. Ao mesmo tempo, estão aí coisas que nunca precisam dessa velocidade: fotografias originais, ficheiros de vídeo, arquivos de download, backups antigos.

Um Storage Server custa uma fração disso e assume exatamente essa carga. Este artigo mostra o que faz sentido mover para fora, que protocolo funciona a partir do servidor web, como os ficheiros chegam em segurança aos visitantes e onde estão os limites.

O que vale a pena mover para fora, e o que não

A linha de separação é simples: o que é lido poucas vezes e transferido de uma só vez em grande volume pertence ao armazenamento. O que é carregado em cada visita de página fica onde é rápido.

O que é um Storage Server, e o que não é

Um Storage Server é armazenamento em rede com contas de utilizador. Liga-se com credenciais e lê ou escreve ficheiros. Não é um armazenamento de objetos com endereços públicos e não é um CDN.

Na prática, isso significa: não pode ligar uma imagem da sua página diretamente ao armazenamento, porque cada acesso é autenticado. O seu servidor web vai buscar o ficheiro e entrega-o, ou então gera ligações de download com validade limitada. Como se faz isso de forma limpa está mais abaixo.

Isto soa a limitação, mas tem uma vantagem: ninguém consegue obter os seus ficheiros adivinhando endereços ou passando uma ligação a outros. O acesso passa sempre pela sua aplicação e, portanto, pelas suas regras.

O padrão que funciona na prática

Três passos, não é mais do que isso:

1. Os originais ficam no armazenamento. São carregados uma vez e depois quase não se tocam.
2. As versões derivadas são criadas uma vez e ficam no servidor web. Ou seja, miniaturas, variantes recortadas, versões comprimidas. São pequenas e são necessárias em cada carregamento de página.
3. Os downloads passam pela sua aplicação. Um pequeno script verifica a permissão, vai buscar o ficheiro ao armazenamento e entrega-o.

Quem inverter isto e for buscar as miniaturas ao armazenamento em cada visita constrói um site lento. A latência de rede por ficheiro acumula-se, e uma galeria com quarenta imagens espera quarenta vezes.

Que protocolo para cada caso

A decisão mais importante não depende do gosto, mas dos seus privilégios: num servidor próprio monta o armazenamento como diretório, e qualquer aplicação pode usá-lo sem saber nada disso. Como se faz está em Montar o Storage Server como unidade de rede.

Em alojamento partilhado não tem privilégios de root, pelo que montar fica fora de questão. Aí o caminho passa por WebDAV ou SFTP a partir da aplicação, e o WebDAV é normalmente a menor resistência, porque a porta 443 praticamente nunca está bloqueada.

Configurar o acesso a partir do PHP

Para SFTP basta uma biblioteca em PHP puro, não é necessária nenhuma extensão no 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('Falha na autenticação');
}

// Carregar um ficheiro
$sftp->put('/bilder/2026/original.jpg', '/tmp/upload.jpg', SFTP::SOURCE_LOCAL_FILE);

// Ler um ficheiro
$inhalt = $sftp->get('/bilder/2026/original.jpg');

Para WebDAV basta mesmo a extensão curl já 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);

Os dois exemplos usam uma subconta, não a conta principal. A razão está na secção seguinte.

Uma subconta própria para cada finalidade

Cada Storage Server permite até 100 subcontas, e isso em todos os tarifários. Cada uma recebe:

• um diretório inicial próprio, do qual não consegue sair,
• uma palavra-passe própria,
• protocolos autorizados próprios, ou seja, por exemplo apenas SFTP e nada de Samba.

Para um site isso significa: uma subconta para o servidor web, que só pode usar SFTP e só vê /web, e uma segunda para o backup, que só vê /backup. Se um dia o servidor web for comprometido, o atacante não chega aos backups, porque essa conta nem sequer os conhece.

Há um limite: uma subconta não recebe uma quota de espaço própria. Fica no seu diretório, mas aí pode encher todo o armazenamento do tarifário. Quem quiser limitar realmente utilizadores individuais precisa de uma aplicação à frente que assuma essa tarefa. O artigo Ligar o Nextcloud ao Storage Server mostra exatamente esta montagem.

Entregar downloads em segurança

O erro mais frequente é deixar as credenciais chegarem ao navegador, por exemplo através de uma ligação com nome de utilizador e palavra-passe. O correto é que o seu servidor estabeleça a ligação e entregue o ficheiro:

<?php
// Verificar a permissão antes de acontecer qualquer outra coisa
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;

Com ficheiros muito grandes é melhor ler em blocos em vez de carregar tudo para a memória, senão o limite de memória do PHP é excedido. Para isso use ob_end_flush() e entregue o ficheiro aos pedaços.

Quem esperar muitos downloads simultâneos deve ter em conta que cada download em curso ocupa um processo de PHP. A partir de certa ordem de grandeza, uma coisa assim pertence a um servidor próprio e não a alojamento partilhado.

Guardar o backup do site no armazenamento

Este é o ponto de partida mais simples, e dá resultado logo. Com rsync transfere apenas as alterações:

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

Para backups com desduplicação e encriptação, o BorgBackup é a melhor escolha, está disponível de forma nativa no armazenamento. A isso juntam-se os snapshots do próprio armazenamento como segundo nível: dependendo do tarifário, 10, 20, 30 ou 40 snapshots manuais, mais outros tantos automáticos em ritmo diário, semanal e mensal.

A diferença em relação ao backup no mesmo servidor é a decisiva: um disco apagado ou encriptado leva consigo um backup local, um backup em armazenamento separado não.

Antes de começar: dois interruptores

Na área de cliente encontra, no Storage Server, o botão «Definições de Acesso». Duas coisas têm de estar certas:

• A Acessibilidade Externa tem de estar ativada, senão o seu servidor web não chega ao armazenamento através da internet.
• O protocolo que pretende tem de estar autorizado, ou seja, Samba para SMB, SSH para SFTP e rsync, WebDAV para o caminho via HTTPS.

Nos servidores encomendados recentemente, tudo isso está ativo. Quem desligar por razões de segurança aquilo de que não precisa deve ter em conta que é justamente isso, mais tarde, a causa mais frequente de «já não funciona».

Que tarifário encaixa

Todos os Storage Servers estão na Alemanha, falam FTP, FTPS, SFTP, SCP, Samba, WebDAV e WebDAVs, trazem rsync e BorgBackup de forma nativa e têm IPv4 e IPv6. Não há taxa de instalação, a faturação é em regime PrePaid e sem período mínimo de contrato. Pode portanto começar com 1 TB e aumentar mais tarde, sem ter de migrar nada.

Um exemplo de cálculo: 1 TB de espaço adicional num servidor web custa, dependendo do fornecedor, várias vezes 9,99 euros por mês, e fica depois na mesma máquina que o site. O armazenamento ao lado não é apenas mais barato, está também separado.