Mentenanța site-ului: actualizări, copii, securitate și cum verificați că se fac
Ce trebuie să acopere lunar mentenanța site-ului firmei: actualizări, copii de rezervă păstrate în afara serverului, restaurare testată și securitate.
- Nº
- 24
- Publicat
- Lectură
- 10 min
- Categorie
- Notes
- Scris de
- Revylio
Mentenanța site-ului înseamnă trei rutine: actualizări, copii testate, supraveghere
Mentenanța site-ului: actualizări, copii, securitate. Acestea sunt cele trei rutine care țin site-ul firmei funcțional după lansare. Prima este actualizarea nucleului, a temei și a pluginurilor. A doua sunt copiile de rezervă păstrate în afara serverului și verificate printr-o restaurare.
A treia este supravegherea semnelor de compromitere. Verificați fiecare rutină cerând dovezi, nu citind contractul.
Mentenanța site-ului este munca regulată de după lansare prin care cineva aplică actualizările, face și verifică copiile de rezervă și urmărește securitatea. Munca se face după un calendar, nu doar când apare o problemă. Nucleul este codul de bază al platformei. Un plugin este un modul care adaugă o funcție, de exemplu un formular sau un sistem de cache.
Exemplele din acest ghid folosesc WordPress. Motivul este simplu: documentația oficială WordPress descrie pașii în detaliu, cu nume de fișiere și ecrane pe care le puteți verifica singur. Principiile se aplică însă oricărei platforme.
Diferența dintre o mentenanță făcută și una doar scrisă în contract nu se vede din afară. Site-ul arată la fel în ambele cazuri, până în ziua în care o actualizare eșuează sau site-ul este spart. De aceea, restul ghidului spune pentru fiecare rutină ce trebuie să se întâmple și ce dovadă puteți cere.
Actualizările nucleului, temei și pluginurilor: ce se face automat și ce nu
Actualizările WordPress se fac pe două căi, potrivit documentației oficiale despre actualizarea WordPress. Cea mai simplă este actualizarea dintr-un clic. Dacă aceasta nu funcționează, se poate urma procesul manual.
Ce se aplică singur
De la versiunea 3.7, cele mai multe site-uri WordPress aplică automat, în fundal, actualizările minore și de securitate ale nucleului. Condiția este ca site-ul să poată face actualizarea dintr-un clic fără să ceară date de conectare FTP. Lansările majore, cele cu funcții noi, nu se aplică singure. Cineva trebuie să apese butonul „Update Now”.
Ce rămâne în grija cuiva
Actualizarea automată descrisă mai sus privește nucleul. Tema și pluginurile stau în dosarul wp-content și trebuie urmărite separat. Cereți furnizorului să vă spună explicit cine le actualizează și cât de des.
Ce se pierde la actualizare
Procesul de actualizare înlocuiește toate fișierele din instalarea principală WordPress. Orice modificare făcută direct în fișierele nucleului se pierde. Dacă un dezvoltator a „reparat” ceva acolo, reparația dispare la prima actualizare. Întrebați, deci, dacă site-ul are modificări în nucleu, înainte să aprobați o actualizare majoră.
Exemplu lucrat: o actualizare WordPress majoră făcută corect, pas cu pas
O actualizare majoră WordPress făcută corect urmează o ordine fixă. Exemplul de mai jos descrie un site de prezentare cu cache activ. Fiecare pas vine din documentația oficială WordPress.
- Copia de rezervă întâi. Manualul WordPress cere copia bazei de date regulat și întotdeauna înaintea unei actualizări.
- Actualizarea dintr-un clic. Din
Dashboard > Updatesse apasă „Update Now”. - Cererea de date de conectare. Dacă apare o fereastră care cere date de conectare, WordPress a detectat o problemă de proprietate a fișierelor. WordPress nu creează fișiere noi direct dacă acestea nu ar avea proprietarul corect. Problemele actualizării dintr-un clic țin, cel mai probabil, de permisiunile din sistemul de fișiere.
- Mesajul „failed update”. Dacă actualizarea se oprește și rămâne mesajul de eșec, se șterge prin FTP fișierul
.maintenancedin dosarul WordPress. - Actualizarea manuală, dacă e nevoie. Se înlocuiesc fișierele nucleului, dar dosarul
wp-contentnu se șterge niciodată. Acolo stau temele și pluginurile. - Baza de date. Dacă e necesară o actualizare a bazei de date, WordPress o detectează și oferă un link spre o adresă de tipul
wp-admin/upgrade.php. - Golirea cache-ului. Fără acest pas, vizitatorii, inclusiv dumneavoastră, văd versiunea veche până se reîmprospătează cache-ul.
Un raport de actualizare serios menționează acești pași. Dacă primiți doar „am actualizat site-ul”, cereți detaliile.
Copiile de rezervă au două părți: baza de date și fișierele
O copie de rezervă completă a unui site WordPress are două părți, baza de date și fișierele, iar pentru o restaurare completă aveți nevoie de amândouă. Așa o descrie manualul WordPress despre copiile de rezervă. Mulți proprietari de site află asta abia când încearcă o restaurare.
Baza de date
Baza de date conține fiecare articol, fiecare comentariu și fiecare link de pe site. Ea stă într-un sistem separat, de obicei MySQL sau MariaDB. Copia ei este un fișier de export, de exemplu .sql, .gz sau .bz2, care trebuie importat înapoi pentru restaurare.
Fișierele
Fișierele sunt tot ce se află în dosarul WordPress de pe server: nucleul, temele, pluginurile, imaginile încărcate, wp-config.php și .htaccess. Copierea fișierelor nu copiază baza de date. O copie „a site-ului” care conține doar fișierele nu vă readuce conținutul.
Setul de copii
Un set de copii înseamnă fișierele și baza de date tratate ca o singură unitate, create aproximativ în același moment. Astfel, cele două părți se potrivesc la restaurare. Ordinea obișnuită la copiere este întâi baza de date, apoi fișierele. La restaurare, ordinea se inversează: întâi fișierele, apoi baza de date.
Cât de des se fac copiile de rezervă și unde se păstrează
Frecvența copiilor de rezervă depinde de cât de des se schimbă site-ul. Manualul WordPress recomandă o copie pe săptămână pentru site-urile mici, cu puține articole. Pentru site-urile cu activitate mare și multe articole, recomandarea este o copie pe zi.
Numărul de copii contează la fel de mult ca frecvența. Manualul recomandă cel puțin 3-5 copii recente, păstrate în locuri diferite. Motivul este practic: una dintre ele se poate corupe sau pierde. Dacă păstrați o singură copie, pe același server cu site-ul, o defecțiune a serverului le ia pe amândouă.
Firma de găzduire face, de obicei, copii ale întregului server, inclusiv ale site-ului dumneavoastră. Manualul WordPress avertizează însă că cererea unei copii din acele arhive durează. Copiile găzduirii sunt o plasă de siguranță în plus, nu rutina principală.
Copiile automate se pot programa cu pluginuri dedicate bazei de date. Manualul adaugă o precauție: o copie manuală făcută din când în când confirmă că procesul automat chiar funcționează. Un plugin care raportează „copie reușită” în fiecare noapte nu dovedește, singur, că fișierul poate fi folosit.
Sursa: developer.wordpress.org
Restaurarea de probă dovedește că o copie de rezervă funcționează
O copie de rezervă este bună doar dacă din ea se poate reconstrui site-ul. Restaurarea de probă înseamnă readucerea unui set de copii pe un server separat și verificarea faptului că site-ul pornește și arată ca originalul. Este singurul test care arată că baza de date și fișierele sunt complete și se potrivesc.
La Svennis, când preluăm un site în mentenanță, prima lucrare este o restaurare de probă a ultimei copii pe un server separat, înainte de orice actualizare. Abia după ce site-ul restaurat pornește și arată ca originalul considerăm copia bună și trecem la actualizări.
O restaurare de probă răspunde la întrebări pe care un raport automat nu le acoperă:
- Copia conține și baza de date, nu doar fișierele?
- Fișierele și baza de date provin din același moment?
- Imaginile încărcate și fișierul
wp-config.phpsunt incluse? - Cât durează, în realitate, readucerea site-ului?
Ultima întrebare contează pentru planificare. Dacă restaurarea durează o zi întreagă, aflați asta acum, nu în ziua în care site-ul cade. Cereți furnizorului data ultimei restaurări de probă și o captură a site-ului restaurat. Răspunsul „nu a fost nevoie până acum” înseamnă că nimeni nu știe dacă copiile funcționează.
Site-ul spart: de ce nu se vede și ce faceți în primele ore
Un site spart arată adesea normal pentru vizitatori și pentru proprietar. Ghidul web.dev pentru site-urile care cred că au fost atacate spune că atacatorii pătrund zilnic în mii de site-uri. Tot acolo scrie că utilizatorii nu văd de obicei atacul, dar acesta afectează pe oricine vizitează pagina, inclusiv proprietarul.
Pagubele nu sunt doar de imagine. Potrivit web.dev, atacatorii pot introduce în site cod rău intenționat care înregistrează tastele apăsate de vizitatori. Așa pot fura date de conectare, inclusiv bancare sau financiare. De aceea supravegherea de securitate nu se poate baza pe „am fi observat noi”.
Ce faceți când bănuiți un atac
- Anunțați imediat persoana responsabilă de mentenanță și cereți confirmarea scrisă că a început investigația.
- Dacă atacul a putut expune date personale ale vizitatorilor sau clienților, de exemplu date din formulare sau de conectare, evaluați imediat dacă trebuie să notificați ANSPDCP. Regulamentul (UE) 2016/679, art. 33, cere notificarea fără întârzieri nejustificate și, dacă este posibil, în cel mult 72 de ore de la constatare. Excepția este cazul în care încălcarea nu este susceptibilă să genereze un risc pentru persoane. Furnizorul de mentenanță trebuie să vă anunțe fără întârziere când află de incident. Dacă riscul pentru persoane este ridicat, art. 34 cere și informarea lor. Documentați incidentul în orice caz.
- Stabiliți data ultimei copii curate. Aici contează cele 3-5 copii păstrate: cea mai recentă poate conține deja codul infectat.
- Restaurați setul ales în ordinea corectă: fișierele, apoi baza de date.
- Aplicați imediat actualizările nucleului, temei și pluginurilor, pentru că restaurarea readuce versiunile vechi.
- Cereți un raport care spune ce s-a găsit, ce s-a restaurat și ce s-a schimbat.
Fără copii testate, pasul al patrulea nu există. Securitatea și copiile de rezervă sunt, practic, aceeași rutină.
Lista de verificare lunară: ce dovadă cereți pentru fiecare rutină
Lista de mai jos vă arată, pentru fiecare rutină de mentenanță, cât de des trebuie făcută și ce dovadă puteți cere. Frecvențele pentru copii vin din manualul WordPress. Dovezile sunt cele pe care un furnizor care chiar face munca le are la îndemână.
| Rutina | Cât de des | Dovada pe care o cereți | Semnal de alarmă |
|---|---|---|---|
| Actualizări minore și de securitate ale nucleului | Automat, în fundal, pe site-urile care permit actualizarea dintr-un clic | Versiunea curentă a nucleului, în raport | Site-ul cere date FTP la fiecare actualizare |
| Actualizări majore, temă, pluginuri | La fiecare lansare, după o copie de rezervă | Lista pluginurilor actualizate și data | Raportul spune doar „am actualizat” |
| Copia bazei de date | Săptămânal la site-uri mici, zilnic la cele active | Numele și data fișierului de export | Nimeni nu știe unde e baza de date |
| Copia fișierelor | Odată cu baza de date, ca set | Confirmarea că include imaginile și wp-config.php | Copie doar a fișierelor, fără bază de date |
| Păstrarea copiilor | Permanent, cel puțin 3-5 copii recente | Locurile unde stau copiile, în afara serverului | O singură copie, pe serverul site-ului |
| Restaurarea de probă | Periodic, plus o copie manuală din când în când | Data ultimei restaurări și o captură a site-ului restaurat | „Nu a fost nevoie până acum” |
| Supravegherea de securitate | Continuu | Cine primește alertele și ce face cu ele | Nimeni nu poate numi persoana responsabilă |
Nu trebuie să înțelegeți fiecare detaliu tehnic ca să folosiți lista. Contează dacă furnizorul răspunde concret și repede.
Ce înseamnă mentenanța site-ului pentru o firmă din România
Pentru o firmă din România, primul pas este un contract de mentenanță care numește cele trei rutine și frecvența lor. Formulări precum „mentenanță lunară” sau „suport tehnic” nu spun nimic despre copii sau restaurări. Cereți ca raportul lunar să conțină aceleași rubrici ca lista de verificare din acest ghid.
Multe site-uri de firmă stau pe găzduire partajată, adică pe un server împărțit cu alți clienți. Documentația WordPress avertizează că, pe unele platforme partajate, este un risc de securitate ca fișierele să aparțină utilizatorului serverului web și nu unui utilizator FTP. Întrebați furnizorul cum sunt setați proprietarii fișierelor pe site-ul dumneavoastră.
Accesul este a doua problemă frecventă. Firma trebuie să dețină conturile de administrare, găzduire și FTP, nu doar furnizorul de mentenanță. Altfel, o schimbare de furnizor devine o negociere pentru propriul site. Ghidul despre rolurile și aprobările pentru editarea site-ului după lansare vă ajută să stabiliți cine are ce acces.
Dacă alegeți acum un furnizor, puneți aceste întrebări înainte de semnare. Lista de întrebări pentru agenția care vă face site-ul acoperă și partea de după lansare. Un răspuns vag acum va fi un răspuns vag și în ziua unui incident.
Pașii următori pentru mentenanța site-ului firmei
Puteți verifica starea mentenanței site-ului în cursul unei singure săptămâni, fără cunoștințe tehnice. Pașii de mai jos merg în ordinea în care riscul scade cel mai repede.
- Cereți ultimul raport de mentenanță. Comparați-l cu lista de verificare din acest ghid și notați rubricile care lipsesc.
- Întrebați unde sunt copiile de rezervă. Cereți locurile, numărul copiilor și data celei mai recente, separat pentru baza de date și fișiere.
- Cereți o restaurare de probă. Stabiliți un termen și cereți o captură a site-ului restaurat pe alt server.
- Verificați conturile. Confirmați că firma deține accesul la administrare, găzduire și FTP.
- Scrieți procedura pentru incident. O pagină cu persoana de contact, termenul de răspuns și ordinea restaurării ajunge. Adăugați cine evaluează notificarea către ANSPDCP, în cel mult 72 de ore, dacă atacul a putut expune date personale, și cine documentează incidentul.
Uneori verificarea arată că site-ul nu mai poate fi actualizat fără să se strice. În acest caz merită să citiți despre când merită refacerea site-ului. Dacă bugetați un site nou, ghidul despre ce ar trebui să includă prețul unui site de prezentare arată unde se încadrează mentenanța în costul total.