Una din provocările administratorilor de servere este aceea de a avea întotdeauna copii de siguranță actualizate pentru a face posibilă restaurarea fiecărui website găzduit. De ce backup VPS Ubuntu? Pentru că mulți dintre noi, cei care nu lucrăm (încă) în domeniu, avem servere virtuale private cu Ubuntu, așa că ne punem problema copiilor de rezervă. Deși Systemback (descris aici) face de fiecare dată câte o imagine a întregului server, restaurarea fiind posibilă dintr-o singură apăsare de tastă, folosirea lui zilnică în mod manual devine obositoare (nu am găsit nicio modalitate de a-l rula automat cu un script prin intermediul cron).
De asemenea, panoul de control Sentora pe care îl am instalat pe VPS-ul administrat de mine și pe care l-am descris în articolele precedente, are un modul de backup al websiteurilor (fișiere plus baze de date) care funcționează defectuos - dezvoltatorii au promis că va fi remediat în versiunea următoare.
Deci, cum facem backup unui server VPS cu Ubuntu? Cele de mai jos au fost testate pe o distribuție Ubuntu server, dar ele funcționează, cu adaptări minore, pe toate distribuțiile Linux existente.
Așa că este indicat să avem un backup al întregului server cu toate fișierele de configurare (nu trebuie actualizat decât în momentul în care modificăm ceva important pe server) și copii zilnice de siguranță pentru website-urile găzduite. Realizarea acestor copii de siguranță poate fi automatizată prin intermediului unei acțiuni cron.
Mergând mai departe, este recomandat ca stocarea acestor copii de siguranță să fie făcută pe alte servere, astfel încât dacă se întâmplă ceva cu serverul actual, să putem accesa fișierele backup din altă parte. Fiecare poate muta aceste fișiere backup oriunde dorește (de exemplu, se poate folosi rclone pentru sincronizarea fișierelor și directoarelor pe Google Drive, Hubic, One Drive, Yandex, Dropbox și altele). Eu voi prezenta modul de realizare automată a backup-ului unui server VPS și mutarea fișierelor obținute direct pe spațiul de stocare Digi Storage (montat cum am descris în cele două articole anterioare).
Vom face două scripturi care, apelate printr-o sarcină cron, vor face zilnic backup la fișierele fiecărui domeniu găzduit pe servere, dar și la bazele de date MySQL aferente.
Crearea scripturilor de backup
Pentru a face scriptul care permite backup-ul fișierelor din public_html, dăm comanda:
nano /etc/cron.daily/backup
În interiorul noului fișier care se deschide vom scrie următoarele (voi explica în rândurile următoare ce face fiecare linie):
#!/bin/bash
cd /var/sentora/hostdata/zadmin/
tar cvfz backup.tgz public_html
curlftpfs -o user="adresa-email-conectare-Digi-Storage:parola-conectare-Digi-Storage" ftps://storage.rcs-rds.ro/"Digi Cloud"/backup/server /mnt/digi
find /mnt/digi/ -type f -mtime +4 -exec rm -- {} \;
mv backup.tgz /mnt/digi/backup_`date +"%d-%m-%Y"`.tgz
fusermount -uz /mnt/digi
Scriptul arată că mergem în folderul /var/sentora/hostdata/zadmin (unde ține Sentora folderele domeniilor găzduite), arhivăm cu comanda tar
folderul public_html care conține fișierele tuturor domeniilor și subdomeniilor de pe server, montăm spațiul de stocare Digi Storage (numai un singur folder, unde vom ține backup-urile) așa cum am descris aici, mutăm folosind comanda mv fișierul de backup în Digi Storage și-i adăugăm și data când a fost făcut pentru identificare ulterioară ușoară.
Linia find /mnt/digi/ -type f -mtime +4 -exec rm -- {} \; este explicată în acest articol - șterge automat fișierele mai vechi de 4 zile.
La final, se demontează sistemul de fișiere montat în /mnt/digi.
Setăm permisiunile și facem fișierul executabil:
sudo chmod +x /etc/cron.daily/backup
sudo chmod 755 /etc/cron.daily/backup
Pentru a face scriptul care permite backup-ul bazelor de date, dăm comanda:
nano /etc/cron.daily/database
În fișierul gol care se deschide vom scrie:
#!/bin/bash
mkdir -p /var/sentora/hostdata/zadmin/database
mysql -u root -p*PAROLA_ROOT_MYSQL* -e "FLUSH TABLES WITH READ LOCK;"
mysqldump -u *UTILIZATOR_BAZĂ_DE_DATE* -p*PAROLĂ_UTILIZATOR_BAZĂ_DEDATE* *NUME_BAZĂ_DE_DATE* > /var/sentora/hostdata/zadmin/database/*NUME_BAZĂ_DE_DATE*.sql
#*Se repeta linia de deasupra pentru fiecare bază de date la care vrem să-i facem copie de siguranță*
mysql -u root -p*PAROLA_ROOT_MYSQL* -e "UNLOCK TABLES;"
cd /var/sentora/hostdata/zadmin/
zip -r database.zip database
rm -rf /var/sentora/hostdata/zadmin/database
curlftpfs -o user="adresa-email-conectare-Digi-Storage:parola-conectare-Digi-Storage" ftps://storage.rcs-rds.ro/"Digi Cloud"/backup/server /mnt/digi
mv database.zip /mnt/digi/database_`date +"%d-%m-%Y"`.zip
fusermount -uz /mnt/digi
ATENȚIE! Când veți scrie parola și utilizatorul NU veți copia și caracterul *; -p*PAROLA_ROOT_MYSQL* devine -pparolăroot, în niciun caz -p*parolăroot*.
Prima linie creează directorul database unde vor fi stocate toate bazele de date MySQL la care facem backup. Opțiunea FLUSH TABLES WITH READ LOCK trece temporar MySQL în read only.
Următoarea linie exportă baza de date selectată (*NUME_BAZĂ_DE_DATE*) - echivalentul opțiunii EXPORT din PhpMyAdmin. Se repetă această linie pentru fiecare bază de date exportată.
Opțiunea UNLOCK TABLES eliberează tabelele bazei de date de procesele care ar putea să le țină blocate, cum ar fi opțiunea FLUSH TABLES WITH READ LOCK de mai sus.
Mergem în folderul /var/sentora/hostdata/zadmin unde avem și folderul database cu bazele de date exportate anterior. Arhivăm cu comanda zip
acest folder, după care îl ștergem. Cu comanda curlftpfs
montăm spațiul de stocare Digi Storage, după care, cu comanda mv, mutăm arhiva zip cu bazele de date în Digi Storage și îi adăugăm și data când a fost făcut, pentru o identificare ulterioară ușoară.
La final, se demontează sistemul de fișiere montat în /mnt/digi.
Setăm permisiunile fișierului și îl facem executabil:
sudo chmod +x /etc/cron.daily/database
sudo chmod 755 /etc/cron.daily/database
Setare cron job
După ce avem aceste două scripturi, nu ne rămâne decât să mai scriem două linii pentru a automatiza întregul proces de backup.
Scriem comenzile:
$sudo su
#crontab -e
În fișierul care se deschide adăugăm la final:
#rulare_backup_databases
01 01 * * * /etc/cron.daily/database | mail -s "s-a realizat backup-ul zilnic la bazele de date" adresa-voastră-de-email#rulare-backup-public_html
01 02 * * * /etc/cron.daily/backup | mail -s "s-a realizat backup-ul zilnic public_html" adresa-voastră-de-email
Backup-ul bazelor de date se va face în fiecare noapte la ora 01:01, iar backup-ul public_html se va face în fiecare noapte la ora 02:01. După terminarea fiecărei sarcini se va trimite câte un mesaj pe adresa de email indicată.
După cum se observă, spațiul cloud Digi Storage îl avem mapat strict doar pe perioada scrierii fișierelor de backup, după care îl demontăm.
Cam asta a fost tot. Prefer spațiul de la Digi Storage pentru că e mare, nu costă mult, este ușor de accesat și oferă viteză foarte bună la descărcarea arhivelor de câțiva GB. Spațiul fiind mare, în Digi Storage puteți stoca câte versiuni ale fișierelor și bazelor de date doriți - totuși, nu cred că are rost păstrarea backup-ului mai mult de 4-5 zile. În acest mod, putem reveni pentru fiecare site la o versiune din orice zi dorită (și salvată, bineînțeles).
Remus a zis
Salut! Eu am adăugat la începutul comenzii de arhivare niște parametri pentru a preveni consumul exagerat de resurse. Acum pt un backup de 10 min/ 1.5gb, CPU load nu mai depășește 1.05, iar înainte era 1.90 sau chiar mai mult. Adică pot folosesc la maxim "lungimea plapumei", dar nimic mai mult :))
ionice -c2 -n7 nice -n19 tar cvfz backup.tgz public_html
De fapt trebuie adăugat la fel și la cea pentru mutat în folderul DIGI, văd că și asta consumă resurse.
De mult căutam un astfel de tutorial. Thanks!
Bobses a zis
Ma bucur ca ti-a fost de folos.