Server căzut: ce verifici mai întâi și în ce ordine

Acest ghid este despre serverul însuși: un VPS, un server dedicat sau cloud pe care îl administrezi. Dacă un singur site eșuează și restul de pe mașină funcționează sau site-ul tău se află pe hosting partajat, începe în schimb cu ghidul Site căzut: ce faci. Aici ne uităm la mașină: răspunde deloc, poți intra și ce s-a oprit.

Pasul 1: ce anume este căzut?

„Serverul e căzut” poate însemna trei lucruri foarte diferite, iar fiecare are propria remediere. Află mai întâi din exterior, dintr-o rețea care nu este a ta. Pentru site-urile de pe server, website down checker îți spune în câteva secunde dacă numele se rezolvă, dacă portul răspunde și ce cod de status revine. Pentru mașină, folosește ping și un test de port de pe propriul calculator:

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

Citește rezultatele împreună:

• Niciun ping, niciun SSH, niciun port web: mașina este oprită, înghețată sau rețeaua din fața ei este căzută. Treci la pasul 2.
• Ping răspunde, SSH nu: mașina rulează, dar SSH este blocat, oprit sau serverul este prea suprasolicitat ca să răspundă. Treci la pasul 3.
• SSH funcționează, site-ul nu: serverul este în regulă, un serviciu nu. Treci la pasul 4.

Unele servere ignoră intenționat ping-ul. Dacă ping-ul nu a funcționat niciodată, bazează-te pe testele de port.

Pasul 2: nu răspunde nimic

Deschide panoul de control al furnizorului sau consola cloud înainte de orice altceva. Trei întrebări lămuresc majoritatea cazurilor într-un minut:

1. Rulează serverul? O instanță oprită, un cont suspendat sau o plată eșuată arată exact ca o cădere din exterior.
2. Există un incident cunoscut? Verifică pagina de status a furnizorului pentru regiunea sau centrul tău de date.
3. Ce arată consola? Consola web sau serială arată ecranul mașinii chiar și fără rețea. O panică de kernel, „Out of memory: Killed process” în buclă sau o pornire blocată la verificarea sistemului de fișiere îți arată fiecare unde este problema.

Dacă mașina este înghețată, o repornire din consolă o readuce de obicei. Înainte să repornești, fă o captură de ecran a consolei: odată repornită, dovezile dispar. Dacă nu pornește, majoritatea furnizorilor oferă un sistem de salvare din care poți monta discul, citi logurile și repara /etc/fstab sau o configurație de rețea defectă.

Pasul 3: ping răspunde, SSH nu

Mașina este vie, deci cauza se află pe ea. Folosește consola ca să te autentifici, apoi verifică suspecții obișnuiți:

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

O regulă de firewall adăugată în grabă, propria adresă IP interzisă după câteva parole greșite sau o modificare a configurației SSH care a eșuat la test sunt cele mai frecvente blocaje. Deblochează-ți adresa cu sudo fail2ban-client set sshd unbanip YOUR_IP și rulează întotdeauna sudo sshd -t înainte să repornești SSH. Dacă SSH rulează, dar este doar foarte lent, serverul este suprasolicitat: treci la pasul 4.

Pasul 4: ai intrat, citește acum patru cifre

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• Încărcare (uptime): mult peste numărul de nuclee CPU înseamnă că mașina este suprasolicitată. top sau htop arată ce proces este responsabil.
• Memorie (free -m): fără memorie liberă și fără swap, plus „Killed process” în dmesg, înseamnă că nucleul a oprit un proces ca să supraviețuiască. De obicei a fost baza de date sau PHP.
• Disc (df -h): un disc plin este cea mai frecventă cauză a problemelor de server. Bazele de date nu mai scriu, logurile se opresc, sesiunile eșuează. df -i verifică inode-urile: un disc poate fi „plin” cu gigaocteți liberi dacă milioane de fișiere mici consumă toate inode-urile.
• Erori de I/O sau un sistem de fișiere doar pentru citire în dmesg: discul însuși are o problemă. Nu mai scrie, fă o copie de siguranță dacă încă poți și contactează furnizorul.

Ca să eliberezi spațiu în siguranță, începe cu jurnalul sistemului și arhivele vechi:

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

Nu șterge niciodată fișiere de baze de date sau fișiere ale site-ului ca să faci loc.

Pasul 5: ce serviciu s-a oprit și de ce

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed listează fiecare serviciu care s-a oprit cu o eroare. Jurnalul acelui serviciu numește motivul: un port deja folosit, o eroare de sintaxă într-un fișier de configurație, un certificat lipsă, nu mai este spațiu. Testează configurația înainte de fiecare repornire (nginx -t, apachectl configtest, php-fpm -t), apoi pornește-l cu sudo systemctl restart SERVICE. O repornire fără test poate doborî un serviciu care încă funcționa pe jumătate.

Pasul 6: ce s-a schimbat?

Căderile au cauze, iar cauza este de obicei ultima modificare. Caută-o:

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

Actualizări automate, un kernel nou care așteaptă o repornire, un deploy, un cron job care a umplut discul cu backup-uri, un certificat expirat sau o modificare de configurație făcută de altcineva: dacă una dintre aceste linii coincide cu momentul în care a început căderea, ai o pistă.

Când aceleași probleme de server revin

Un server care a căzut o dată din cauza unui disc plin sau a unei baze de date oprite o va face din nou. Verificarea din exterior îți spune când e căzut; verificarea din interior îți spune înainte. Agentul de server raportează încărcarea, memoria, discurile și serviciile din interiorul mașinii și te alertează când un disc depășește pragul tău sau un serviciu bifat de tine se oprește, cât mai e timp să acționezi. Monitorizarea serverului cu agent face parte din planurile plătite.

Când nu vrei să faci asta la 3 dimineața

Dacă serverul tău e căzut și preferi să fie reparat decât să-l depanezi singur, un Quick Fix rezolvă cauzele frecvente la preț fix: repornește un serviciu oprit după ce testul configurației trece, eliberează un disc plin și reînnoiește un certificat expirat, cu o copie de siguranță înainte. Când nu ajunge, preia un Deep Fix, non-stop, facturat în blocuri de 15 minute, cu prețul afișat înainte să comanzi. Ambele funcționează prin Responder, SSH ca root sau acces SSH la spațiul tău de hosting. Detalii pe pagina reparare server căzut și suport de urgență.