BLACKBOXCentru de ajutor

Baze de date: MariaDB/MySQL și PostgreSQL

Instalarea și securizarea MariaDB și PostgreSQL, accesul de la distanță prin tunel SSH și copiile de siguranță.

generalActualizat 2026-10-09~11 min de citit
Pe această pagină

Ghidul arată cum instalați MariaDB (compatibil cu MySQL) sau PostgreSQL pe server, cum creați o bază de date cu utilizatorul ei, cum vă conectați la ea de pe calculator printr-un tunel SSH și cum faceți copii de siguranță. Comenzile se rulează ca root, într-o sesiune SSH (Conectarea la server prin SSH (Windows, macOS, Linux)). Adresa IP a serverului este în panoul app.blackbox.md, „Infrastructură” → „Serverele mele” (app.blackbox.md/my-servers).

Disponibil pentru: titularul unui server VPS cu Ubuntu, Debian, AlmaLinux sau CentOS Stream. Dacă serverul are un panou de control (Planurile „VPS hosting” cu panou de control), bazele de date se creează de regulă din acel panou.

MariaDB sau PostgreSQL

Instalați sistemul pe care îl cere aplicația.

MariaDB PostgreSQL
Folosit de obicei pentru WordPress, Joomla, Drupal, majoritatea aplicațiilor PHP multe aplicații Django, Ruby on Rails, Node.js și cele care cer PostgreSQL
Pachet pe Ubuntu și Debian mariadb-server postgresql
Pachet pe AlmaLinux și CentOS Stream mariadb-server postgresql-server
Port 3306 5432

Pentru majoritatea aplicațiilor, MariaDB înlocuiește MySQL fără modificări. Dacă aplicația cere explicit MySQL, instalați mysql-server pe Ubuntu, AlmaLinux sau CentOS Stream (pe Debian nu este în depozitele standard). Atunci comenzile se numesc mysql și mysql_secure_installation, iar numele serviciului și căile fișierelor de configurare diferă de cele din acest ghid. Nu instalați MySQL și MariaDB pe același server.

MariaDB: instalare și securizare

Ubuntu și Debian

apt update
apt install -y mariadb-server

Serviciul pornește automat și ascultă doar pe 127.0.0.1.

AlmaLinux și CentOS Stream

dnf install -y mariadb-server
systemctl enable --now mariadb

Aici MariaDB ascultă implicit pe toate interfețele. Legați-l la 127.0.0.1 cu fișierul 99-local.cnf de mai jos.

Fișierul cu setările dvs.

Puneți setările dvs. într-un fișier separat, 99-local.cnf, pe care îl creați cu nano sau vi: pe Ubuntu și Debian în /etc/mysql/mariadb.conf.d/, pe AlmaLinux și CentOS Stream în /etc/my.cnf.d/. Pe AlmaLinux și CentOS Stream, începeți-l așa (pe Ubuntu și Debian, bind-address = 127.0.0.1 este deja setat):

[mysqld]
bind-address = 127.0.0.1

După fiecare modificare, reporniți serviciul și verificați că apare 127.0.0.1:3306, nu 0.0.0.0:3306 sau *:3306:

systemctl restart mariadb
ss -tlnp | grep 3306

mariadb-secure-installation

mariadb-secure-installation
Întrebarea Răspunsul
Enter current password for root (enter for none) Enter
Switch to unix_socket authentication [Y/n] n
Change the root password? [Y/n] n, dacă scriptul a scris „You already have your root account protected, so you can safely answer 'n'.”; altfel Y și o parolă puternică
Remove anonymous users?, Disallow root login remotely?, Remove test database and access to it?, Reload privilege tables now? Y la toate

Utilizatorul root al MariaDB folosește autentificarea prin socket (unix_socket): intră doar root-ul sistemului, cu comanda mariadb, fără parolă. Pe Ubuntu 20.04 (MariaDB 10.3), comenzile se numesc mysql_secure_installation și mysql, iar la „Set root password?” răspundeți n.

Baza de date și utilizatorul ei

Fiecare aplicație primește baza ei și un utilizator cu drepturi doar pe acea bază. Generați o parolă puternică, apoi deschideți consola MariaDB:

openssl rand -base64 24
mariadb

Rulați, înlocuind NUME_BAZA, NUME_UTILIZATOR și PAROLA:

CREATE DATABASE NUME_BAZA CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'NUME_UTILIZATOR'@'localhost' IDENTIFIED BY 'PAROLA';
GRANT ALL PRIVILEGES ON NUME_BAZA.* TO 'NUME_UTILIZATOR'@'localhost';
EXIT;

NUME_BAZA.* limitează drepturile la această bază, iar 'localhost' permite conectarea doar de pe server și prin tunel SSH. Nu folosiți ON *.* și nici '%'. Testați conectarea cu noul utilizator:

mariadb -u NUME_UTILIZATOR -p NUME_BAZA

În configurația aplicației scrieți gazda localhost, portul 3306, numele bazei, utilizatorul și parola.

PostgreSQL: instalare și utilizatori

Ubuntu și Debian

apt update
apt install -y postgresql

Serviciul pornește automat și ascultă doar pe localhost.

AlmaLinux și CentOS Stream

dnf install -y postgresql-server
postgresql-setup --initdb
systemctl enable --now postgresql

Deschideți /var/lib/pgsql/data/pg_hba.conf. Dacă pe liniile host pentru 127.0.0.1/32 și ::1/128 scrie ident, înlocuiți-l cu md5 (acceptă și parolele salvate ca SCRAM). Altfel aplicațiile primesc eroarea Ident authentication failed. Aplicați modificarea:

systemctl reload postgresql

Utilizatorul și baza de date

sudo -u postgres createuser --pwprompt NUME_UTILIZATOR
sudo -u postgres createdb --owner=NUME_UTILIZATOR NUME_BAZA

La „Enter password for new role:” și „Enter it again:” introduceți parola. Utilizatorul nu este superutilizator: are drepturi depline doar în baza pe care o deține. Avertismentul could not change directory to "/root": Permission denied este inofensiv; nu apare dacă rulați comenzile din /tmp. Testați conectarea (ieșiți cu \q):

psql -h 127.0.0.1 -U NUME_UTILIZATOR NUME_BAZA

Accesul de la distanță prin tunel SSH (recomandat)

Ca să lucrați cu baza din DBeaver, HeidiSQL, MySQL Workbench, pgAdmin sau alt client de pe calculator, nu deschideți portul bazei de date. Tunelul SSH trece prin portul 22, deja deschis, criptează traficul, iar baza rămâne legată la 127.0.0.1.

  1. Pe calculator, în Terminal (macOS, Linux) sau PowerShell (Windows), porniți tunelul. Pentru MariaDB:

    ssh -N -L 3306:127.0.0.1:3306 root@IP_SERVER

    Pentru PostgreSQL:

    ssh -N -L 5432:127.0.0.1:5432 root@IP_SERVER
  2. Lăsați fereastra deschisă: tunelul funcționează cât rulează comanda. Îl închideți cu Ctrl + C.

  3. În client, conectați-vă la gazda 127.0.0.1, portul 3306 sau 5432, cu utilizatorul și parola bazei de date.

Tunelul folosește aceeași autentificare ca o conexiune SSH obișnuită: pe un server „Doar cheie”, dacă cheia nu este în locul implicit, indicați-o cu -i. Dacă pe calculator portul este ocupat de o bază locală, folosiți alt port local, de exemplu -L 13306:127.0.0.1:3306, și conectați-vă la 127.0.0.1:13306. Scrieți 127.0.0.1, nu localhost: clientul mariadb/mysql tratează localhost ca socket local și ocolește tunelul. Mulți clienți grafici au tunelul SSH încorporat în setările conexiunii: gazda SSH IP_SERVER, portul 22, utilizatorul root și cheia sau parola, apoi gazda bazei 127.0.0.1.

Deschiderea portului bazei de date (nerecomandat)

O bază de date expusă în internet este scanată permanent, iar parolele ei sunt atacate prin încercări repetate. Dacă un serviciu extern trebuie totuși să se conecteze direct, portul trebuie deschis pe ambele niveluri:

  1. Filtrarea din rețea, administrată de BLACKBOX, lasă să treacă implicit doar SSH (22), HTTP (80), HTTPS (443) și ping, deci 3306 și 5432 sunt închise. Panoul nu are setări de firewall: scrieți suportului adresa IP a serverului și portul (Cum contactați suportul BLACKBOX).

  2. Firewall-ul sistemului trebuie să fie activ (vedeți nota de mai jos) și să permită portul doar de la adresa dvs. IP, aflată cu Instrumentul „Adresa ta IP”. Pentru PostgreSQL, înlocuiți 3306 cu 5432. Cu ufw (Ubuntu, Debian):

    ufw allow from IP_DVS to any port 3306 proto tcp

    Cu firewalld (AlmaLinux, CentOS Stream):

    firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="IP_DVS/32" port port="3306" protocol="tcp" accept'
    firewall-cmd --reload
  3. MariaDB: în 99-local.cnf, sub [mysqld], puneți bind-address = 0.0.0.0, reporniți serviciul și creați utilizatorul 'NUME_UTILIZATOR'@'IP_DVS' cu aceleași comenzi CREATE USER și GRANT.

  4. PostgreSQL: în pg_hba.conf (Ubuntu și Debian: /etc/postgresql/VERSIUNE/main/pg_hba.conf; AlmaLinux și CentOS Stream: /var/lib/pgsql/data/pg_hba.conf) adăugați linia host NUME_BAZA NUME_UTILIZATOR IP_DVS/32 METODA, cu metoda de pe liniile pentru 127.0.0.1/32 (scram-sha-256 sau md5), apoi:

    sudo -u postgres psql -c "ALTER SYSTEM SET listen_addresses = '*'"
    systemctl restart postgresql

Dacă adresa dvs. IP se schimbă, regula trebuie actualizată. Fără TLS configurat în baza de date, datele circulă necriptat: încă un motiv pentru tunel.

Atenție Pe un server nou, ufw și firewalld nu sunt activate. Înainte să le activați, permiteți SSH și păstrați deschisă o a doua sesiune SSH: nu există consolă web sau VNC pentru clienți. Pașii: Firewall: filtrarea din rețea și ufw/firewalld pe server. Dacă v-ați blocat accesul, scrieți suportului.

Baza de date pe alt server BLACKBOX

Serverele BLACKBOX nu sunt legate între ele printr-o rețea privată: aplicația ajunge la baza de pe alt server prin adresa IP publică a acestuia, ca orice calculator din internet. Nu presupuneți că portul bazei de date este accesibil de pe celălalt server. Soluția recomandată este un tunel SSH permanent, pornit pe serverul aplicației ca serviciu systemd: baza rămâne legată la 127.0.0.1, iar traficul trece criptat prin portul 22.

Tunel SSH permanent (recomandat)

Comenzile sunt pentru MariaDB; pentru PostgreSQL înlocuiți peste tot 3306 cu 5432.

  1. Pe serverul aplicației, creați o cheie SSH folosită doar pentru tunel, fără parolă, ca s-o poată folosi serviciul:

    ssh-keygen -t ed25519 -f /root/.ssh/db_tunnel_ed25519 -N "" -C db-tunnel
    cat /root/.ssh/db_tunnel_ed25519.pub
  2. Pe serverul bazei de date, creați un utilizator separat, fără shell, și deschideți-i fișierul authorized_keys:

    useradd -m -s /usr/sbin/nologin dbtunnel
    mkdir -p /home/dbtunnel/.ssh
    nano /home/dbtunnel/.ssh/authorized_keys

    Scrieți o singură linie: restricțiile, un spațiu, apoi cheia afișată la pasul 1.

    restrict,port-forwarding,permitopen="127.0.0.1:3306" ssh-ed25519 AAAA... db-tunnel

    Setați drepturile:

    chown -R dbtunnel:dbtunnel /home/dbtunnel/.ssh
    chmod 700 /home/dbtunnel/.ssh
    chmod 600 /home/dbtunnel/.ssh/authorized_keys

    Pe AlmaLinux și CentOS Stream, refaceți și etichetele SELinux:

    restorecon -R /home/dbtunnel/.ssh

    Cu aceste restricții, cheia deschide doar tunelul spre portul bazei: nu primește shell și nu ajunge la alte porturi. Nu o adăugați cu „Adaugă cheie SSH” din panou: panoul o pune la root, fără restricții.

  3. Pe serverul aplicației, porniți tunelul o dată de mână. La prima conectare, confirmați cheia serverului bazei cu yes. Cât tunelul este deschis, comanda nu afișează nimic; opriți-o cu Ctrl + C:

    ssh -N -i /root/.ssh/db_tunnel_ed25519 -L 3306:127.0.0.1:3306 dbtunnel@IP_SERVER_BD
  4. Creați serviciul:

    nano /etc/systemd/system/db-tunnel.service
    [Unit]
    Description=Tunel SSH spre baza de date
    Wants=network-online.target
    After=network-online.target
    
    [Service]
    ExecStart=/usr/bin/ssh -N -i /root/.ssh/db_tunnel_ed25519 -o BatchMode=yes -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -o ServerAliveCountMax=3 -L 3306:127.0.0.1:3306 dbtunnel@IP_SERVER_BD
    Restart=always
    RestartSec=10
    
    [Install]
    WantedBy=multi-user.target
  5. Activați serviciul și verificați că tunelul ascultă pe 127.0.0.1:3306:

    systemctl daemon-reload
    systemctl enable --now db-tunnel
    systemctl status db-tunnel
    ss -tlnp | grep 3306
  6. În configurația aplicației scrieți gazda 127.0.0.1 (nu localhost), portul 3306, numele bazei, utilizatorul și parola. Pe serverul bazei, utilizatorul creat pentru 'localhost' este suficient.

ExitOnForwardFailure închide conexiunea dacă tunelul nu se poate deschide, iar ServerAliveInterval observă o conexiune căzută; în ambele cazuri systemd repornește serviciul după 10 secunde. BatchMode=yes împiedică serviciul să aștepte o confirmare sau o parolă. Dacă pe serverul aplicației portul 3306 este ocupat de o bază locală, folosiți alt port local, de exemplu -L 13306:127.0.0.1:3306, și scrieți-l în configurația aplicației. Dacă serviciul nu pornește, citiți jurnalul:

journalctl -u db-tunnel -n 50

Portul deschis doar pentru serverul aplicației

Dacă tunelul nu vi se potrivește, cereți suportului să deschidă portul 3306 sau 5432 al serverului bazei și urmați pașii din secțiunea „Deschiderea portului bazei de date (nerecomandat)”, cu adresa IP a serverului aplicației în loc de IP_DVS: în regula ufw sau firewalld, în utilizatorul MariaDB ('NUME_UTILIZATOR'@'IP_SERVER_APLICATIE') și în linia din pg_hba.conf. Fără TLS, datele circulă necriptat între servere. Înainte să activați firewall-ul, păstrați deschisă a doua sesiune SSH: nu există consolă web (vedeți nota de mai sus).

Copii de siguranță

Nu copiați fișierele unei baze care rulează: copia poate fi inconsistentă. Faceți un export (dump) cu mysqldump sau pg_dump, comprimat cu gzip.

  1. Creați scriptul /usr/local/bin/backup-db.sh și păstrați doar linia pentru sistemul dvs.:

    #!/bin/bash
    set -euo pipefail
    cd /tmp
    DIR=/var/backups/db
    DATE=$(date +%F)
    mkdir -p "$DIR"
    chmod 700 "$DIR"
    # MariaDB / MySQL
    mysqldump --single-transaction --routines NUME_BAZA | gzip > "$DIR/mariadb-NUME_BAZA-$DATE.sql.gz"
    # PostgreSQL
    sudo -u postgres pg_dump NUME_BAZA | gzip > "$DIR/pg-NUME_BAZA-$DATE.sql.gz"
    # șterge exporturile mai vechi de 7 zile
    find "$DIR" -name '*.sql.gz' -mtime +7 -delete
  2. Faceți-l executabil, rulați-l o dată și verificați fișierele:

    chmod 700 /usr/local/bin/backup-db.sh
    /usr/local/bin/backup-db.sh
    ls -lh /var/backups/db
  3. Deschideți lista de sarcini cron cu comanda de mai jos și adăugați linia care rulează scriptul în fiecare noapte la 02:30, ora serverului (o vedeți cu timedatectl):

    crontab -e
    30 2 * * * /usr/local/bin/backup-db.sh

--single-transaction exportă tabelele InnoDB într-o stare consistentă, fără să le blocheze. Scriptul rulează ca root, care intră în MariaDB prin socket. Dacă ați setat o parolă pentru root-ul MariaDB, puneți-o în /root/.my.cnf, secțiunea [client], cu drepturile 600. Dacă crontab lipsește, instalați pachetul cron (Ubuntu, Debian) sau cronie (AlmaLinux, CentOS Stream) și porniți serviciul. Exporturile ocupă spațiu: urmăriți discul cu df -h (Discul serverului este plin).

Important Exporturile din /var/backups/db sunt pe același disc cu baza: dacă discul se defectează sau serverul este șters, le pierdeți și pe ele. BLACKBOX nu face copii automate ale serverului, iar butonul „Backup” de pe cardul serverului nu este activ. Copiați exporturile regulat în alt loc: Strategia de backup pentru serverul dvs.

Testați restaurarea

O copie neîncercată poate să nu funcționeze. Cel puțin o dată pe lună, restaurați exportul într-o bază de test, verificați tabelele și ștergeți baza. MariaDB:

mariadb -e "CREATE DATABASE test_restore"
gunzip -c /var/backups/db/mariadb-NUME_BAZA-2026-10-09.sql.gz | mariadb test_restore
mariadb -e "SHOW TABLES" test_restore
mariadb -e "DROP DATABASE test_restore"

PostgreSQL:

cd /tmp
sudo -u postgres createdb test_restore
gunzip -c /var/backups/db/pg-NUME_BAZA-2026-10-09.sql.gz | sudo -u postgres psql -q test_restore
sudo -u postgres psql -d test_restore -c '\dt'
sudo -u postgres dropdb test_restore

Pentru o restaurare reală, opriți întâi aplicația. La PostgreSQL, restaurați într-o bază goală, creată cu createdb --owner=NUME_UTILIZATOR.

Memoria pe planurile mici

Valorile implicite, 128 MB pentru innodb_buffer_pool_size (MariaDB) și pentru shared_buffers (PostgreSQL), sunt potrivite pentru 1 GB de RAM. Pe serverele mai mari le puteți crește prudent, mai ales când pe același server rulează și serverul web sau aplicația. Memoria o vedeți cu free -h.

RAM Exemple de planuri innodb_buffer_pool_size shared_buffers
1 GB Basic XS 128M (implicit) 128MB (implicit)
2 GB Basic S, CPU S, Standard S 256M 256MB
4 GB Basic M, CPU M, Standard M 512M 512MB
8 GB Basic L, CPU L, Standard L 1G 1GB

Pe un server folosit doar pentru baza de date, puteți aloca până la jumătate din RAM pentru innodb_buffer_pool_size și un sfert pentru shared_buffers. Fiecare conexiune consumă și ea memorie: nu măriți max_connections fără motiv.

MariaDB: scrieți valoarea în 99-local.cnf (dacă fișierul există, adăugați doar a doua linie sub [mysqld]), apoi reporniți și verificați:

[mysqld]
innodb_buffer_pool_size = 256M
systemctl restart mariadb
mariadb -e "SELECT @@innodb_buffer_pool_size/1024/1024 AS MB"

PostgreSQL (shared_buffers se aplică doar după repornire):

sudo -u postgres psql -c "ALTER SYSTEM SET shared_buffers = '256MB'"
systemctl restart postgresql
sudo -u postgres psql -c "SHOW shared_buffers"

Pe planurile cu 1–2 GB de RAM adăugați și swap: Adăugarea memoriei swap. Dacă baza de date se oprește singură, verificați dacă sistemul a închis-o din lipsă de memorie:

journalctl -k | grep -i "out of memory"

Dacă se repetă, serverul are nevoie de mai mult RAM: Upgrade server: trecerea la un plan mai mare.

Întrebări frecvente

Aplicația primește „Access denied for user”. Ce verific? Numele bazei, utilizatorul, parola și gazda: un utilizator creat pentru 'localhost' se conectează doar de pe server sau prin tunel. Dacă mesajul arată 'NUME_UTILIZATOR'@'127.0.0.1', creați utilizatorul și pentru '127.0.0.1', cu aceleași comenzi CREATE USER și GRANT.

Am uitat parola utilizatorului bazei de date. Cum o schimb? Ca root pe server. În consola mariadb:

ALTER USER 'NUME_UTILIZATOR'@'localhost' IDENTIFIED BY 'PAROLA_NOUA';

În PostgreSQL, comanda de mai jos vă cere parola nouă de două ori:

sudo -u postgres psql -c "\password NUME_UTILIZATOR"

Actualizați apoi parola în configurația aplicației.

Cum descarc un export pe calculator? Rulați pe calculator comanda de mai jos, cu numele fișierului dorit. Alte metode: Transferul fișierelor pe server (scp, rsync, SFTP).

scp root@IP_SERVER:/var/backups/db/FISIER.sql.gz .

Pot rula MariaDB și PostgreSQL pe același server? Da, folosesc porturi diferite. Împart însă memoria, așa că alegeți pentru amândouă valori mai mici decât cele din tabel.

N-ați găsit răspunsul?Scrieți-ne și echipa de suport vă răspunde. support@blackbox.md
Deschideți un tichet