Storage Server pentru site-ul propriu: imagini, descărcări, arhive

Pe un server web, spațiul pe disc este bunul cel mai scump. Stă pe SSD-uri NVMe rapide, construite pentru baze de date și PHP, și devine simțitor mai scump cu fiecare gigabyte. În același timp, acolo zac lucruri care nu au nevoie niciodată de viteza asta: fotografii originale, fișiere video, arhive de descărcare, backupuri vechi.

Un Storage Server costă o fracțiune din asta și preia exact această povară. Articolul arată ce merită mutat, ce protocol funcționează de pe serverul web, cum ajung fișierele în siguranță la vizitatori și unde sunt limitele.

Ce merită mutat și ce nu

Linia de separare este simplă: ce se citește rar și se transferă o dată, într-o bucată mare, ține de storage. Ce se încarcă la fiecare afișare de pagină rămâne acolo unde este rapid.

Ce este un Storage Server și ce nu este

Un Storage Server este spațiu de stocare în rețea cu conturi de utilizator. Te conectezi cu datele de acces și citești sau scrii fișiere. Nu este spațiu de stocare de obiecte cu adrese publice și nu este un CDN.

Practic, asta înseamnă: în pagina ta nu poți include o imagine printr-un link direct către storage, pentru că fiecare acces este autentificat. Serverul tău web ia fișierul și îl trimite mai departe, sau generezi singur linkuri de descărcare limitate în timp. Cum se face asta curat scrie mai jos.

Sună ca o limitare, dar are un avantaj: nimeni nu îți poate lua fișierele ghicind adrese sau dând un link mai departe. Accesul trece mereu prin aplicația ta și deci prin regulile tale.

Modelul care funcționează în practică

Trei pași, nimic mai mult:

1. Originalele stau pe storage. Se încarcă o dată și după aceea se ating rar.
2. Versiunile derivate se creează o dată și stau pe serverul web. Deci miniaturi, variante decupate, versiuni comprimate. Sunt mici și este nevoie de ele la fiecare afișare de pagină.
3. Descărcările trec prin aplicația ta. Un script mic verifică dreptul de acces, ia fișierul de pe storage și îl livrează.

Cine întoarce asta pe dos și ia miniaturile proaspăt de pe storage la fiecare afișare își construiește un site lent. Latența de rețea se adună pentru fiecare fișier, iar o galerie cu patruzeci de imagini așteaptă patruzeci de ori.

Ce protocol pentru ce caz

Decizia cea mai importantă nu ține de gust, ci de drepturile tale: pe un server propriu montezi storage-ul ca director, și orice aplicație îl poate folosi fără să știe nimic despre el. Cum se face scrie în Montarea Storage Server-ului ca unitate de rețea.

Pe hosting partajat nu ai drepturi de root, deci montarea cade. Acolo drumul trece prin WebDAV sau SFTP, din aplicație, iar WebDAV este de obicei calea cu cea mai mică rezistență, pentru că portul 443 nu este practic niciodată blocat.

Configurarea accesului din PHP

Pentru SFTP este suficientă o bibliotecă scrisă doar în PHP, nu este nevoie de nicio extensie pe server:

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('Autentificare eșuată');
}

// Încarcă fișierul
$sftp->put('/bilder/2026/original.jpg', '/tmp/upload.jpg', SFTP::SOURCE_LOCAL_FILE);

// Citește fișierul
$inhalt = $sftp->get('/bilder/2026/original.jpg');

Pentru WebDAV ajunge chiar extensia curl deja integrată:

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

Ambele exemple folosesc un subcont, nu contul principal. De ce, scrie în secțiunea următoare.

Pentru fiecare scop un subcont separat

Fiecare Storage Server permite până la 100 de subconturi, și asta la fiecare tarif. Fiecare primește:

• un director de start propriu, din care nu poate ieși,
• o parolă proprie,
• permisiuni de protocol proprii, deci de exemplu doar SFTP și niciun Samba.

Pentru un site asta înseamnă: un subcont pentru serverul web, care are voie doar SFTP și vede doar /web, și un al doilea pentru backup, care vede doar /backup. Dacă serverul web ajunge să fie compromis, atacatorul nu mai ajunge la backupuri, pentru că acel cont nici nu le cunoaște.

O limită există: un subcont nu primește o cotă de spațiu proprie. Rămâne în directorul lui, dar acolo poate umple tot spațiul tarifului. Cine vrea să limiteze cu adevărat utilizatori individuali are nevoie în fața storage-ului de o aplicație care preia asta. Conectarea Nextcloud la Storage Server arată exact această structură.

Livrarea sigură a descărcărilor

Greșeala cea mai frecventă este să lași datele de acces să ajungă în browser, de exemplu printr-un link cu nume de utilizator și parolă. Corect este ca serverul tău să deschidă conexiunea și să trimită fișierul mai departe:

<?php
// Verifică dreptul de acces înainte să se întâmple orice altceva
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;

La fișiere foarte mari este mai bine să citești în blocuri, în loc să încarci totul în memorie, altfel depășești limita de memorie a PHP. Pentru asta folosește ob_end_flush() și livrează fișierul bucată cu bucată.

Cine se așteaptă la multe descărcări simultane ar trebui să țină cont și de faptul că fiecare descărcare în curs ocupă un proces PHP. Peste un anumit ordin de mărime, așa ceva ține de un server propriu, nu de hosting partajat.

Backupul site-ului pe storage

Acesta este cel mai simplu început și aduce imediat ceva. Cu rsync transferi doar modificările:

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

Pentru backupuri cu deduplicare și criptare, BorgBackup este alegerea mai bună, pe storage este disponibil nativ. La asta se adaugă snapshot-urile storage-ului însuși ca al doilea nivel: în funcție de tarif, 10, 20, 30 sau 40 de snapshot-uri manuale, plus tot atâtea automate, în ritm zilnic, săptămânal și lunar.

Diferența față de backupul pe același server este cea decisivă: un disc șters sau criptat ia cu el backupul local, pe un storage separat backupul rămâne.

Înainte să începi: două comutatoare

În panoul clientului găsești la Storage Server butonul „Setări de acces”. Două lucruri trebuie să fie în ordine:

• Accesibilitate externă trebuie să fie activată, altfel serverul tău web nu ajunge la storage prin internet.
• Protocolul dorit trebuie să fie permis, deci Samba pentru SMB, SSH pentru SFTP și rsync, WebDAV pentru calea prin HTTPS.

La serverele comandate nou, toate acestea sunt active. Cine închide din motive de siguranță ce nu îi trebuie ar trebui să țină minte că exact asta este mai târziu cauza cea mai frecventă pentru „nu mai merge”.

Ce tarif se potrivește

Toate Storage Server-ele stau în Germania, vorbesc FTP, FTPS, SFTP, SCP, Samba, WebDAV și WebDAVs, aduc rsync și BorgBackup nativ și au IPv4 și IPv6. Nu există taxă de configurare, facturarea se face pe bază PrePaid, fără durată minimă. Poți deci începe cu 1 TB și crește mai târziu, fără să te muți.

Un exemplu de calcul: 1 TB de spațiu suplimentar pe un server web costă, în funcție de furnizor, de mai multe ori prețul de 9,99 euro pe lună, și stă apoi pe aceeași mașină ca site-ul. Storage-ul de lângă nu este doar mai ieftin, este și separat.