Am un VPS la DO (ubuntu) pe care țin diverse site-uri, câteva cron-job-uri pentru sincronizări de repo-uri șamd.
Nu prea îmi surâde ideea de a mă baza doar pe backup-ul săptămânal venit de la DO și aș vrea să configurez și un sistem zilnic, de preferat pe amazon s3.
Aș vrea să am trei backup-uri:
Configs (astfel încât să pot replica VPS-ul rapid în altă parte) și setările. Pentru asta am găsit Blueprint, rămâne să mă lămuresc ce și cum. Fără să mă limitez doar la astea, vreau backup la config de: nginx, php, cron etc;
fișierele (~ și /var/www);
bazele de date (mysql/mariaDB);
Problemele sunt următoarele:
DO nu livrează un ubuntu curat, are diverse chestii preinstalate - un utilitar de genul Blueprint mi-ar permite replicarea pe un VPS non DO?
cum? tar -zcpf e suficient?
cum? mysqldump e suficient?
pentru e vorba de câțiva GB de date (ce sunt imagini, deci nu vor fi comprimate de tar), aș vrea ca backup-ul fișierelor/sql să fie incremental zilnic, diferențial săptămânal, full lunar.
eu am un microserver acasa pe care il folosesc cu rol de NAS si in acelasi timp VPS-urile isi fac in timpul noptii backup prin SSH pe acel microserver.
Chestia asta nu îmi place. Nu am un al doilea VPS disponibil, poate doar să mai iau un vps doar pt backup…
DB nu sunt mari. Nu sar de ~50MB toate dump-urile (arhivate). La ăsta nu țin neapărat să fie incremental
Nu mă deranjează cât timp funcționează.
E mai dificil aici. Config de la nginx într-un loc, cel de la sql în alt loc, cron în altă parte șamd. Dacă ar fi fost toate într-un singur loc n-aș fi avut problema asta. Oare ln ar funcționa bine? Hmm…
pentru e vorba de câțiva GB de date (ce sunt imagini, deci nu vor fi comprimate de tar), aș vrea ca backup-ul fișierelor/sql să fie incremental zilnic, diferențial săptămânal, full lunar.
cum pun totul pe S3?
Tizule, așa idee creață mi-a venit!.. Ideea mea nu rezolvă fiecare punct pe care l-ai menționat, dar e așa de nebună că n-o pot ține doar pentru mine!
(Folosești doar bash, curl și API-ul DO)
Dacă n-ai făcut-o deja, creezi un Floating IP pe care îl asociezi cu droplet-ul tău și modifici intrările DNS să folosească IP-ul respectiv
Faci un cron care rulează zilnic, la o oră în care n-ai vizitatori, un script gen start-backup.sh care, folosind API-ul, pornește un droplet de 5$ folosind un snapshot despre care vorbim imediat.
Creezi un droplet de 5$ pe care pui un apache sau nginx
În DocumentRoot-ul de mai sus, pui o pagină frumoasă cu “Under maintenance” și faci url-rewrite ca orice request să afișeze pagina aia
Pe al doilea droplet (D2) adaugi un script la start-up care va face efectiv backup-ul în felul următor (tot prin API):
Mută Floating IP-ul pe el însuși, așa încât toate request-urile către domeniul tău să ajungă la el, nu la droplet-ul original (D1)
Dă shutdown la D1
Face un snapshot la D1
Așteaptă până-i gata snapshot-ul
Pornește D1
După ce-ai configurat D2, îi faci un snapshot și distrugi droplet-ul (acesta va fi re-creat o dată pe zi din snapshot de către scriptul start-backup.sh de pe D1)
Pe D1, adaugi la startup un alt script care:
Verifică dacă există D2 iar dacă există
Mută Floating IP-ul înapoi pe D1
Distruge D2
…și gata! În felul ăsta vei avea snapshot-uri zilnice la droplet-ul principal, cu tot ce se găsește pe el.
În privința costului, nu vei plăti decât acele câteva minute pe zi cât va funcționa D2 iar snapshot-urile sunt gratuite (Bine, frumos ar fi să mai și ștergi din ele, eventual să ții unul pe lună + unul pe săptămână pentru ultima lună + unul pe zi pentru ultima săptămână).
Pe lângă asta, va mai fi downtime-ul de câteva minute pe zi… Tu știi dacă e acceptabil.
Nu stiu daca exista ceva mai inteligent pentru digitalocean, insa in general folosesc
backupuri la confurile /etc/. Cel mai bine ar fi sa de folosit niste retete puppet. De exemplu, conful meu de dev machine il pot target si spre digitalocean (https://puphpet.com/)
la mysql: backup zilnic sau de doua ori pe zi de pe un slave.
rsync la content
Pentru 1 si 3 se poate folosi bacula care stie de incremental si total. De salvat, salvez pe un nas SYNOLOGY. Tot zic sa imi fac timp sa salvez pe Amazon Glacier (S3 mi se pare prea scump)
O regula extra pe care foarte multa lume o ignora: simuleaza un recovery - ca sa fii sigur ca salvezi ce trebuie (si astfel iti poti creiona si procedura de recovery )
Legat de arhivele tar - e mai bine sa incerci cpio (ar trebui sa existe instalat) sau altceva - daca se corupe arhiva tar nu cred ca mai poti recupera datele - sau cel putin asa am patit si asa am citit.
Daca ai alt VPS ready cu consola, poti incerca si rsync, dar ai zis ca asta nu ar fi o varianta. Mai poti face ca file storage ceva pe baza de git - gen bitbucket - daca tot nu ocupa mult arhivele - n-am incercat sa folosesc pentru asta bitbucket pana acum. S3 nu e scump versus alte variante care stiu sa faca mai multe lucruri?
Mysqldump-ul l-as face per baza de date, nu full - ca sa fie mai usor de prelucrat ulterior.
Daca vrei backup incremental si la DB, va trebui sa faci niste mici artificii - de exemplu eu am folosit un mysql proxy scris in Lua care primea fiecare interogare si o adauga secvential in niste fisiere, ca sa existe istoric
Ln functioneaza cat timp sunt in aceeasi zona fisierele (gen nu over the network din cate stiu)
In rest, cred ca ai primit deja o sumedenie de sugestii
Hai sa va zic un truc cu mysql :
Singura problema la backup-uri tine de mysql si metoda prin care se face backup-ul. Eu de ani de zile folosesc https://sypex.net/en/ in mod CLI prin cron pe multe servere cu baze de date de zeci de Gb si imi realizeaza un backup intr-un timp record. Intradevar exista o problema la restabilire cu index-urile, dar folositi mysql db < backupsypex.sql si se vor regenera index-urile in mod corect. In plus spatiul ocupat este mult mai mic. (gen o baza de date de 3gb imi ocupa sub 1gb salvat cu sypex)
Eventual daca ai baze de date mici va functiona corect si script-ul lor de restabilire si e capabil sa restaureze doar anumite baze de date dintr-un backup. (sa nu mai zic ca iti repune o baza de date de 500 mb in cam 5 secunde)
Eu iti recomand sa folosesti stocare de la amazon pe care sa salvezi backup-urile, in cel mai rau caz un NAS personal sau un alt server. Daca e vorba de un client care nu are cine stie ce resurse merge si backup direct pe dropbox sau servicii gen digi storage.
Amazon e și alegerea mea. Înca nu știu dacă Glacier sau S3, dar pe amazon va fi sigur.
Clientul sunt eu, în cazul de față Pe vps este ținut un proiect personal, ce nu produce nimic, de unde și reticiența de a apela la încă un server. Să zicem că tot costul serverului în acest moment e acoperit de lucrurile extra făcute de el: îl folosesc pe post de proxy uneori (este în US), am câteva cron-uri pentru sincronizări între repo-uri github->gitlab șamd.
În acest moment nu este nimic vital pe el, acum m-aș oftica să pierd toate setările. Dar în câteva luni presupun că se adună ceva mai multe date și… aș vrea sa fiu pregătit acum, să nu fiu ca Homer
Când un bărbat spune că va face ceva, va face, nu trebuie să i se aducă aminte la fiecare șase luni!
Altfel spus, încă nu am făcut nimic. Timpul nu mi-a permis să dedic câteva zile acestei probleme, iar atunci când am avut o zi mai liberă am preferat să vegetez
M-a enervat chestia asta de mi-am facut cont ca sa pot raspunde
Si pentru mine rsync a fost solutia castigatoare. Cu --link-dest=ultimul backup realizat cu succes.
VPS separat pentru backup-uri la un alt provider. Pe VPS-ul de backup am adaugat toate ssh-key-urile VPS-urilor la care trebuie backup. cron pe VPS-ul asta care se conecteaza la VPS-urile live si trimite niste comenzi ssh pe fiecare, printre care si mysqldump. Printr-un API afla daca sunt gata comenzile, si dupa aia, cu rsync-ul de mai sus face backup. VPS-ul de backup are 2TB. Si pentru 5 VPS-uri [in medie, ca au fost si 2 si 14] inca mai am backup-uri din 2014 [cand l-am pornit] pe el.
La procedura de sters backup-uri a trebuit sa tinker-uiesc ceva si am mai updatat-o pe parcurs.
In general backup-urile sunt zilnice, dar le-am facut si la o ora pentru anumite VPS-uri si nu au fost probleme.
+ 500GB pe un volum separat pentru backup-urile laptop-ului. ca deh … mac , si n-as vrea sa raman vreodata fara datele alea. A durat vreo 2 zile backup-ul personal [nu continuu], dar de atunci mai mult de 5 minute nu dureaza.
Ideea e ca si merita, ca paying customers vor sa le fie sigure datele. Daca e / era pentru un proiect personal, te inteleg de ai mers pe principiul “if it’s not important enough to work itself out it’s not important enough”.
Confirm ca dupa ce faci un sistem de backup trebuie sa simulezi recuperarea datelor de cateva ori la inceput si dupa aia din cand in cand.
Între timp am migrat de la DO la Aruba, deci weap pică din start. În plus, chiar dacă n-aș fi făcut-o, mi se pare un pic ciudat să plătesc pentru backup aproape cât plătesc pentru hosting
„strategia” curentă constă într-un bash rulat când îmi aduc aminte (o dată-de două ori pe lună) care face dump la toate bazele de date, arhivează ce trebuie (compresie minimă) și urcat pe B2.
