O chestie la care să te gândești: câți fac backup DE FAPT

O chestie la care să te gândești: câți fac backup DE FAPT ©

MxHost mi-a dat un răspuns care m-a blocat. Mă așteptam la un procent mic, dar mă așteptam la măcar 2-3%!

Dintre toți clienții lor doar 0.1% fac backup! Pe pagina lor zic că au peste 27.000 de clienți iar 0.1% înseamnă… șoc și groază, 27 de oameni.

Sigur, aici vorbim de backup din cPanel, operațiune ce poate fi monitorizată de MX, dar asta nu face lucrurile mai … uhm… roz.

Un backup periodic al cPanel îți garantează că poți muta RAPID lucrurile în altă parte în cazul unui eveniment nasol. Și aici nu vorbim despre fișiere la care poate ai backup periodic, ci vorbim despre funcționalițăți dincolo de site-uri: mail-uri, zone DNS etc.

Problema la backup-ul ăsta este că se poate face DOAR manual. Adică intri în cPanel, apeși pe butonul de backup, aștepți să fie gata, începi descărcarea. Efectiv nu există nici o modalitate de a automatiza acest proces, nici pentru clienții shared nici pentru conturi de reseller. Ceea ce mi se pare un pic aiurea, dar cu siguranță nu este o scuză.


Indiferent că ești client MX sau nu, intră acum în cpanel și fă un backup full. Pune-ți un reminder recurent în calendar, să-ți aducă aminte măcar de trei ori pe an!

Dacă folosești WordPress, îți recomand cu foarte mare căldură BackWPup. Știe să facă backup și la DB și la fișiere (dar dacă ești pe un server shared nu-ți recomand să îl folosești la fișiere, rupe la resurse), trimite backup ori pe mail, ori pe ftp ori în dropbox ori în alte o grămadă de locuri, trimite log-uri șamd. Poți programa backup-uri să ruleze automat la o anumită oră. La mine rulează zilnic.

Sigur, toată operațiunea asta nu-ți garantează că nu vei pierde date ci doar că vei face un damage control să fii iar pe linia de plutire. Adică ai prefera să pierzi datele din ultimul an sau cele din ultimele zile? Ai prefera să nu ai acces o săptămână la date?


Dacă ești programator, comportă-te ca un profesionist. Folosește Git pentru versionare, folosește seed-uri și migrări pentru baza de date și pentru numele lui Turing, nu mai dezvolta direct pe server! Dezvolți local, faci deploy automat în staging sau producție.

12 Comentarii

Malin a scris

Cat de mult va complicati voi viata mai oameni buni cu toate cacaturile de BackupWPup si ManageWP care nu fac altceva decat sa manance resurse intul si sa riste sa faca backup-uri corupte in cazul in care nu exista suficiente resurse pe server.
Eu am un simplu cron care face rsync incremental odata pe zi la fisiere si alt cron care face mysqldump, compresie si apoi rsync la baza de date.
Apoi mai am un cron care trage fisierele de configurare de pe serverele unde am config-uri critice pe care mi-e lene de fapt sa le refac manual si un alt cron care sterge ZIP-urile de MySQL la 10 zile dupa ce au fost downloadate pe serverul de backup.
Si nu in ultimul rand am un cron care sincronizeaza totul folosind rsync incremental pe un al doilea server de backup in cloud, sunt eu mai paranoic de felul meu.
Diferenta intre pluginurile alea si rsync-ul incremental e ca, la fel ca si in cazul Git atunci cand se face o sincronizare de date se transmit doar delta-urile si modificarile si astfel nu se fac backup-uri redundante la aceleasi fisiere.
Asta scuteste timp si resurse.
Sincronizarea incrementala se face mai repede pentru ca preia doar modificarile la nivel de filesystem, sincronizarea e mai rapida pentru ca rsync stie compresie, se foloseste mai putin spatiu de stocare. Chiar daca pluginurile alea fac ZIP-uri, pentru backup-uri zilnice, in ZIP-urile alea ai unele si aceleasi fisiere, iar la fisierele media rata de compresie e oricum irelevanta in timp ce fisierele plain text (PHP, JS, HTML) nu fac mare diferenta in ceea ce priveste volumul de stocare. Asa ca intre un WordPress stocat intr-un director fara ZIP si niste fisiere ZIP-uite la un WordPress nu e mare diferenta de marime deci pluginurile alea nu fac mare diferenta.
Dincolo de asta, daca voi recomandati pluginurile alea doar pentru backup onsite atunci mai bine nu le mai recomandati pentru ca sunt efectiv inutile si nu fac decat sa consume resurse degeaba pe server. Softaculous are deja functie de backup automat cu reciclare pentru stocarea onsite, dar la ce bun un backup onsite cand se duce dracului cosmelia cum s-a intamplat la Webfactor?
E plin internetul de scripturi in Bash, Perl sau Python ce pot sa fie configurate si rulate pe un cron ca sa sincronizeze datele via sFTP sau rsync pe un alt server si sunt si scripturi care au capacitatea de sincronizare folosind WebDav si astfel merg configurate sa urce datele pe cloud undeva sau pe un StorageBox de 3 euro cum sunt astea de la Hetzner: https://www.hetzner.de/storage-box, iar scripturile alea sunt infinit mai utile, mai resource friendly, mai rapide si mai sigure decat pluginurile lui peste prajit.
Cat despre progamare, si in cazul asta am un cron care da git push pe 2 repo-uri diferite la fiecare 5 minute. E mai sigur asa… mai ales cand folosesti repo-uri private si nu ceva gen Github.
On a side note: Daca ai datele deja pe un alt server, sa presupunem ca ai un VPS de productie si altul pe care clonezi datele, bazele de date in format SQL si fisierele de configuratie si folosesti ceva DNS third-party ai si plan de contingenta nu doar de backup. E foarte simplu sa dai deploy la serviciile de web si mail pe al 2-lea VPS cand a picat primul, sa muti fisierele la care ai facut backup in locul lor pastrand intacta ierarhia sistemului de fisiere, sa corectezi permisiunile la nevoie si sa importi baza de date in SQL, apoi sa schimbi A record-ul din DNS ca sa mearga catre noul server. De fapt chiar si daca ai un plan de shared de 1 euro poti sa-ti faci un plan de backup/contingenta cu un VPS de la Aruba tot de 1 euro si ceva DNS third-party.
Solutii ieftine si eficiente exista si nu prea au nimic de-a face cu toate mizeriile de pluginuri pentru WordPress.

Malin a scris

P.S. Storage Box-ul ala de la Hetzner merge montat si ca network drive acasa ceea ce- face foarte util in momentul in care vrei sa salvezi datele de acolo si pe PC sau pe un HDD extern. Odata montat network drive-ul doar iei datele cu copy/paste si le copiezi pe stick sau HDD extern.
Science bitch!

Malin a scris

@Ionuț Staicu: Click-click-click s-a dovedit inutil. Eu unul ma indoiesc de faptul ca tu, tocmai tu scrii pentru Gheorghe instalatorul care are un blog de pescuit sau Zina gospodina care pune 2-3 retete ci pentru oameni care au putin habar de cum se utilizeaza un calculator si care ar trebui sa evite solutii de compromis doar pentru ca sunt mai simple sau mai ieftine. Degeaba dai click-click-click cand iti da rateu pluginul ca n-are suficienta memorie pentru buffer si-ti face backup corupt. Te pisi pe el cu jet cand tre’ sa dai restore. Si n-o spun pentru ca mi s-a nazarit mie ci pentru ca lucrez cu shared environment toata ziua si vad cazuri de backup-uri onsite corupte macar odata pe saptamana. Nici Softaculous nu e suficient de fiabil pentru ca la mai mult de 2GB sau baze de date de peste 200MB da rateu si ala si nu reuseste sa duca backup-ul la bun sfarsit, iar in unele cazuri daca n-ar exista R1Soft-ul firmei de hosting si-ar cam baga clientii ceva in site-urile lor si pluginurile alea fara sa fie nevoie ca firma de hosting sa dispara la fel ca Webfactor sau altii.

Apoi, cat despre Git, mai bine ca te abtii. Sincronizarea aia la 5 minute e pentru un singur proiect si e urmata de un download in format ZIP la fel de frecvent. Restul proiectelor nu se sincronizeaza asa frecvent si oricum sunt pe un backup zilnic si alea.
Nevoia de frecventa e determinata de faptul ca exista oameni care folosesc 24/7 scripturile alea, iar singurul care face update-uri pe ele sunt eu si e esential ca update-urile alea sa ajunga de indata la toata echipa pentru ca regex-urile sa fie actualizate. Oamenii inainte sa se apuce de treaba isi dau un git clone sau isi trag ZIP-ul de pe unul din repo-uri si stiu sigur ca au ce le trebuie. Era contra-productiv sa stau sa dau eu git push si sa ma asigur ca nu uit sa fac asta dupa fiecare regex pe care-l introduc.

Ionuț Staicu a scris

@Malin: nu știu ce să zic, click-click s-a dovedit inutil într-un singur caz, unde db avea aproape 1gb. În rest folosesc un plugin sau altul de ani de zile, fără probleme :) Pe blogul de față am un DB de 80mb și durează ~15 secunde dump, arhivare și trimitere pe dropbox. Probleme de memorie sunt într-adevăr de fiecare datâ când încerc să fac backup la fișiere (de unde și recomandarea de mai sus) dar la DB zbârnâie.

Modul în care ai ales tu să lucrezi cu git este peste mână; istoria repo-ului cred că este plină de pași în care sunt erori de sintaxă, să rulezi blame e un coșmar șamd. În plus, branch-urile nu sună a fi ceva ce s-ar putea integra ușor în ce faci tu…

Malin a scris

@Ionuț Staicu: Acuma mno’ fiecare zice ca e OK sau fiabil pana e patit si pe urma nu mai are aceeasi parere.
Apoi, revenind la Git. Eu am spus ca fac Git push, nu commit la fiecare 5 minute. E o diferenta mare intre cele doua. Push se face abia dupa ce dau eu commit si dupa ce trec fiecare regex printr-un tester ca sa confirm ca si da match pe ceea ce vreau eu sa dea match. Singurul lucru care efectiv se modifica e un fisier ce contine niste regex-uri si cam atat. Restul scripturilor sunt de regula intacte, dar daca survine vreo modificare atunci cine o face ar trebui sa caste ochii de doua ori inainte sa dea commit. Oricum alte modificari decat cele la fisierul de regex-uri sunt destul de rare. Deci erori de sintaxa nu exista. N-au de ce sa existe atat timp cat dau commit doar dupa ce sunt sigur ca am regex-ul corect si verific ca face match pe https://regex101.com/.
Repet, vorbim de un context diferit fata de ce-ti inchipui tu ca se face. In ultimele doua luni am facut peste 600 de regex-uri si nu e tocmai usor sau rapid sa faci un regex pe un fisier de malware polimorfic asa ca automatizarea git push ma scuteste de o grija si ii ajuta pe colegi sa aiba mereu si ultimul regex adaugat.
Peste mana era daca trebuia sa stau sa dau manual push in 2 repo-uri simultan dupa fiecare commit. Nu?

Adaugă un comentariurăspuns pentru

Link-urile în context sunt binevenite. Comentariile fără nume/email valid sunt șterse.
PS: Comentariul NU este editabil.

Site-ul blog.iamntz.com utilizează cookie-uri. Continuarea navigării presupune acceptarea lor. Mai multe informații.

windows apple dropbox facebook twitter