Am publicat recent pe directorul oficial WordPress un plugin mic și deschis la cod pentru backup direct în Backblaze B2. M-am săturat de pluginurile consacrate care cer abonamente anuale de 70$ doar ca să deblocheze un amărât de upload S3-compatible. Dacă plănuiești să trimiți un plugin la review-ul oficial WordPress în perioada asta, povestea mea te poate scuti de vreo lună de ping-pong inutil cu reviewerii.
De ce Backblaze B2 și nu soluțiile clasice?
Am avut cazul unui client cu un magazin WooCommerce măricel — undeva la 45 GB de imagini și fișiere în uploads. UpdraftPlus cerea bani pe addon-ul de cloud storage extern, iar AWS S3 începea să adune costuri vizibile la egress și stocare pe termen lung.
Backblaze B2 oferă primii 10 GB gratuiți, iar după costă în jur de 0.006$ per GB lunar. Pentru un site de dimensiune medie, costul de stocare e practic o cafea pe an.
Trade-off-ul e evident: Backblaze e excepțional de ieftin la storage, dar API-ul lor compatibil S3 are mici ciudățenii pe conexiuni instabile. A trebuit să gestionez eu manual chunk-urile de upload ca să nu moară scriptul când shared hostingul taie execuția după 30 de secunde.
Calvarul review-ului pe WordPress.org
Dacă n-ai mai urcat un plugin pe repo-ul oficial în ultimii doi ani, pregătește-te psihic. Coada de așteptare pentru primul răspuns a durat 24 de zile. Când a venit răspunsul, a fost un email lung cu tichete de corectat.
Prima palmă a fost legată de SDK-ul AWS. Ca să nu reinventez roata pentru apelurile S3, trăsesem pachetul oficial via Composer. Folderul de vendor avea vreo 19 MB. Echipa de review mi-a respins pachetul pe motiv de „bloatware” — cereau să elimin componentele nefolosite. A trebuit să curăț manual SDK-ul și să păstrez strict clientul de S3 și dependințele de bază, reducând totul la 2.3 MB.
Al doilea refuz a venit din cauza verificărilor de permisiuni. Eu verificam nonces pe formularul din panoul de administrare, dar nu verificam explicit current_user_can('manage_options') înainte de fiecare acțiune REST pe care o declanșa interfața. Pentru ei, un nonce fără verificare de capabilitate este o breșă critică de securitate, chiar dacă endpoint-ul nu face altceva decât să testeze conexiunea la bucket.
A treia chestie stupidă: am folosit file_put_contents temporar pentru a scrie arhiva locală. Regula absolută pe WP.org este să folosești clasa WP_Filesystem. Dacă scrii direct pe disc fără abstractizarea lor, iei reject automat la scanarea automată.
Cum rulează și ce compromisuri am făcut
N-am vrut procese demonizate sau dependențe externe pe server, așa că totul se bazează pe WP-Cron.
Aici apare compromisul clasic de arhitectură: dacă site-ul nu are trafic noaptea, cron-ul intern nu se declanșează la ora 03:00. Soluția curată e să configurezi un cron nativ din Linux pe server (curl https://site.ro/wp-cron.php), dar pentru utilizatorul non-tehnic asta e mereu o bătaie de cap.
Pentru arhivare, generez fișiere zip în tranșe de maximum 10 MB per pas ca să nu lovesc limitele de memorie (multe instanțe ieftine sunt blocate la 128 MB RAM). Durează mai mult, dar merge fără erori de tip Allowed memory size exhausted.
Pluginul e pe GitHub, licențiat GPLv2, și funcționează fără brizbrizuri comerciale. Voi ce soluții folosiți pentru backup-uri mari pe WordPress: vă bazați pe unelte la nivel de server sau preferați încă un plugin dedicat?