Câteva sfaturi despre cum să faceți copii de siguranță ale bazelor de date
La prima vedere, realizarea unei copii de rezervă a bazei de date a unui site este extrem de ușoară, dacă aveți acces la utilitarul mysqldump și programatorul pentru cron de locuri de muncă. Adăugăm la planificator o înregistrare a formularului:
și totul, în fiecare zi, la 3 ore și 14 minute, va fi aruncat. Timpul de salvare ar trebui să fie ales astfel încât, în acest moment, sarcina pe server să fie minimă pentru zi.
Dar această soluție nu este suficient de fiabilă. Dacă baza de date este deteriorată, să zicem, la 3:12, memoria va fi suprascrisă cu fișierul gol.
Pentru a proteja împotriva acestui lucru, este logic să salvați vechea înainte de a face o copie nouă și, de asemenea, să faceți copii individuale la anumite intervale. De exemplu, salvez săptămânal și lunar și pentru a încărca un server SQL mai mic, trebuie doar să copiați fișierele de memorie:
Întârzierile pe oră sunt efectuate astfel încât depozitul să aibă timp să fie creat / copiat complet.
Aceste copii sunt bune când trebuie să restaurați întreaga bază de date. Dar uneori există situații în care trebuie să restabiliți numai o parte din conținut și astfel să salvați ceea ce a fost adăugat după eliminarea copiei de rezervă. De exemplu, acest lucru poate fi necesar dacă o secțiune a fost ștearsă pe forum. În acest caz, dumpul efectuat cu setările de mai sus nu va funcționa, deoarece are comenzi SQL pentru a șterge și a crea din nou toate tabelele bazei de date. Prin urmare, este logic să procedați după cum urmează: să faceți o copie de rezervă a structurii tabelului într-un fișier, iar datele în sine. În plus, astfel încât atunci când importați date într-o tabelă deja existentă nu au existat erori, este logic să le inserați prin INSERT IGNORE. În acest caz, comanda dump ia forma:
În acest caz, dacă este necesar, baza de restaurare parțială pot fi importate numai backup.sql, și va vosstanovley doar acele înregistrări care au fost șterse (și să nu fie afectate de cei care au apărut mai târziu), și, dacă este necesar, recuperarea completă - prima backup.struct.sql , și apoi backup.sql deja. De asemenea, în unele cazuri, este logic să utilizeze opțiunea --replace, în acest caz, în loc de instrucțiunea INSERT REPLACE va fi utilizat, care va aduce toate înregistrările din baza de date în minte, care a fost la momentul îndepărtarea de rezervă, iar mai târziu - a rămas neschimbată.
Dacă aveți servicii de root-acces pe server, este recomandat să faceți o copie de rezervă a acestuia, ca root, și de a salva într-un director care nu este disponibilă pentru utilizatorii obișnuiți. Acest lucru este util în cazul în care atacatorul va uyavzvimost pe server, permițându-i să efectueze codul prozivolny în numele aceluiași utilizator, din care script-urile sunt rulate site-ul, caz în care el nu va fi capabil de a șterge backup-uri. Și nu uitați să încărcați periodic copiile de siguranță pe propriul computer (sau pe un alt server, dacă este disponibil).
Adăugat mai târziu: a scris un mic script, în care a implementat toate ideile descrise aici într-o formă mai convenabilă pentru aplicație și a postat-o pe GitHub.
Chudnenko! Sau poate puteți spune unei alte echipe să copieze dump-ul la un FTP la distanță? (conexiune cu login / parola)
Articole similare
-
Câteva sfaturi simple pentru a lucra cu, de ce aveți nevoie de un top
-
Cum se desfasoara nunta, ce trebuie facut sfaturile de nunta despre asta
Trimiteți-le prietenilor: