Strategia de backup pentru serverul dvs.

BLACKBOX nu face copii de rezervă automate ale serverului dvs. Butonul „Backup” de pe cardul serverului, în pagina „Serverele mele” a panoului app.blackbox.md (app.blackbox.md/my-servers; din blackbox.md: „Contul meu” → „Panou de administrare” → „Serverele mele”), nu este activ. Ghidul arată ce salvați, unde păstrați copiile, cum le automatizați și cum verificați că le puteți restaura. Toate comenzile se rulează pe server, prin SSH, ca root.

Disponibil pentru: titularul unui VPS sau al unui server dedicat BLACKBOX, cu acces root prin SSH: Conectarea la server prin SSH (Windows, macOS, Linux). Comenzile sunt pentru Ubuntu, Debian, AlmaLinux și CentOS Stream.

Cine răspunde de copiile de rezervă

Pe server aveți acces root și controlați tot ce rulează pe el, deci răspundeți și de copiile de rezervă ale datelor: Responsabilitatea pentru datele de pe server și backup. Capitolul 9 „Limitarea răspunderii” din Termenii și condițiile prevede că „BLACKBOX nu răspunde pentru daune indirecte, pierdere de profit, pierderi de date sau întreruperi de activitate suferite de Client sau terți”.

În panou nu există copii automate și nici snapshot-uri. Dacă apăsați „Backup” pe cardul serverului, apare „Se încarcă…”, apoi mesajul backup_extra_disabled: serviciul de backup automat nu este disponibil. Serverul și datele de pe el nu sunt afectate. Vedeți Pagina „Serverele mele”: cardul serverului.

Important Un server șters cu „Șterge definitiv” sau prin anularea comenzii nu mai poate fi recuperat. Singurele copii ale datelor sunt cele pe care le-ați făcut dvs., în afara serverului.

Regula 3-2-1

O copie într-un alt director al aceluiași server nu este backup: dispare odată cu serverul dacă acesta este șters, compromis sau nu mai pornește.

Ce salvați

Nu copiați fișierele bazei de date (/var/lib/mysql, /var/lib/postgresql, /var/lib/pgsql) cât timp baza rulează: copia poate fi inconsistentă și baza nu mai pornește din ea. La fel pentru volumele Docker ale bazelor de date: faceți dump cu comanda bazei, rulată în container. Exemplu pentru PostgreSQL, ca rând în scriptul de la pasul 1:

docker exec NUME_CONTAINER pg_dump -U NUME_UTILIZATOR -Fc NUME_BD > "$DIR/NUME_BD-$DATA.dump"

Pentru MariaDB sau MySQL din container, folosiți la fel mysqldump (în imaginile MariaDB recente, mariadb-dump), cu utilizatorul și parola din .env. Vedeți și Instalarea Docker și Docker Compose.

Nu este nevoie să salvați /proc, /sys, /dev, /run, /tmp, cache-urile, imaginile Docker (se descarcă sau se construiesc din nou) și pachetele sistemului (se reinstalează). Codul aflat într-un depozit Git extern nu cere o copie separată, dacă verificați că modificările ajung acolo.

Unde păstrați copiile

Pentru copia offsite din regula 3-2-1, alegeți cel puțin o destinație la alt furnizor sau la dvs. în birou. Pentru un server de backup la BLACKBOX, planurile din familia Basic au discuri mari, de până la 400 GB: Planurile VPS: cum alegeți.

BLACKBOX Cloud Storage nu se comandă online. Pe pagina blackbox.md/hosting/cloud-storage („Găzduire” → „Cloud Storage”), butonul „Comandați stocare” duce la pagina „Contacte”. Volumul, prețul și metodele de acces le primiți în oferta echipei; întrebați ce metode de acces are spațiul, ca să alegeți între restic și rsync. Vedeți Produse și configurații disponibile la cerere.

Pasul 1: dump-ul zilnic al bazelor de date, din cron

Scriptul de mai jos exportă baza de date în /var/backups/db în fiecare noapte și șterge de acolo dump-urile mai vechi de 7 zile. Pasul 2 le copiază apoi în afara serverului. Instalarea bazelor de date: Baze de date: MariaDB/MySQL și PostgreSQL.

Fișierele se editează cu nano. Dacă lipsește (AlmaLinux, CentOS Stream), instalați-l:

dnf install -y nano

1. Creați scriptul:

   nano /usr/local/sbin/db-dump.sh

2. Lipiți conținutul de mai jos, înlocuiți NUME_BD cu numele bazei, salvați cu Ctrl+O și Enter, apoi ieșiți cu Ctrl+X:

   #!/bin/bash
   set -euo pipefail
   umask 077
   cd /
   DIR=/var/backups/db
   DATA=$(date +%F)
   mkdir -p "$DIR"
   mysqldump --single-transaction --routines NUME_BD | gzip > "$DIR/NUME_BD-$DATA.sql.gz"
   find "$DIR" -type f -mtime +7 -delete

   Pentru PostgreSQL, înlocuiți rândul cu mysqldump cu acesta:

   sudo -u postgres pg_dump -Fc NUME_BD > "$DIR/NUME_BD-$DATA.dump"

   Pentru mai multe baze, repetați rândul pentru fiecare. Pe MariaDB, comanda se numește și mariadb-dump.

3. Faceți scriptul executabil, rulați-l o dată și verificați fișierul creat:

   chmod 700 /usr/local/sbin/db-dump.sh
   /usr/local/sbin/db-dump.sh
   ls -lh /var/backups/db

   Dacă apare Access denied for user 'root'@'localhost', utilizatorul root al bazei cere parolă. Puneți-o în fișierul /root/.my.cnf, cu conținutul de mai jos, apoi restrângeți accesul la fișier:

   [client]
   user=root
   password=PAROLA_BD

   chmod 600 /root/.my.cnf

4. Programați scriptul în fiecare noapte la 02:00 (ora serverului). Creați fișierul:

   nano /etc/cron.d/db-dump

   și lipiți rândul:

   0 2 * * * root /usr/local/sbin/db-dump.sh >> /var/log/db-dump.log 2>&1

Fișierele din /etc/cron.d au coloana utilizatorului (root), numele lor nu conține puncte, iar ultimul rând se termină cu Enter. Caracterul % nu poate fi scris direct în rândul cron; de aceea data se calculează în script. Dacă sarcina nu rulează, verificați că serviciul cron este instalat și pornit.

Ubuntu și Debian:

apt update
apt install -y cron
systemctl enable --now cron

AlmaLinux și CentOS Stream:

dnf install -y cronie
systemctl enable --now crond

Dump-urile ocupă spațiu pe disc. Dacă discul este mic, păstrați mai puține zile (de exemplu -mtime +3): Discul serverului este plin.

Pasul 2: copia în afara serverului cu restic

restic criptează datele pe server, înainte de trimitere, păstrează un istoric de copii (snapshot-uri) și la fiecare rulare transferă doar ce s-a schimbat. Exemplul folosește o stocare de obiecte compatibilă S3; varianta cu un alt server, prin SFTP, este în secțiunea despre rsync. Documentația oficială: restic.readthedocs.io.

Instalarea

Ubuntu și Debian:

apt update
apt install -y restic

AlmaLinux și CentOS Stream (restic vine din depozitul EPEL):

dnf install -y epel-release
dnf install -y restic

Depozitul și parola

1. La furnizorul de stocare, creați un bucket și o pereche de chei de acces. Notați adresa serviciului (endpoint), numele bucket-ului, ID-ul cheii și cheia secretă.

2. Generați parola depozitului și afișați-o:

   mkdir -p /etc/restic
   chmod 700 /etc/restic
   openssl rand -base64 32 > /etc/restic/password
   chmod 600 /etc/restic/password
   cat /etc/restic/password

3. Copiați parola afișată în managerul dvs. de parole.

4. Creați fișierul cu setări:

   nano /etc/restic/env

   RESTIC_REPOSITORY=s3:https://ENDPOINT_S3/NUME_BUCKET/NUME_SERVER
   RESTIC_PASSWORD_FILE=/etc/restic/password
   AWS_ACCESS_KEY_ID=ID_CHEIE
   AWS_SECRET_ACCESS_KEY=CHEIE_SECRETA

   NUME_SERVER este un folder din bucket; dați fiecărui server folderul lui. Dacă furnizorul cere o regiune, adăugați rândul AWS_DEFAULT_REGION=REGIUNE.

5. Restrângeți accesul la fișier, încărcați setările în sesiunea curentă și inițializați depozitul (o singură dată):

   chmod 600 /etc/restic/env
   set -a
   . /etc/restic/env
   set +a
   restic init

   Răspunsul începe cu created restic repository.

Risc Fără parola depozitului, copiile nu mai pot fi decriptate de nimeni, nici de BLACKBOX. Păstrați-o și în afara serverului: dacă serverul se pierde, fără ea nu puteți restaura nimic.

Scriptul de backup

nano /usr/local/sbin/restic-backup.sh

#!/bin/bash
set -euo pipefail
set -a
. /etc/restic/env
set +a
restic backup /etc /root /var/www /var/spool/cron /var/backups/db --exclude-caches
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --keep-tag manual --prune

Faceți scriptul executabil, rulați-l o dată și vedeți lista de copii:

chmod 700 /usr/local/sbin/restic-backup.sh
/usr/local/sbin/restic-backup.sh
restic snapshots

Rularea zilnică cu un timer systemd

1. Creați serviciul:

   nano /etc/systemd/system/restic-backup.service

   [Unit]
   Description=Backup restic
   Wants=network-online.target
   After=network-online.target
   
   [Service]
   Type=oneshot
   Environment=HOME=/root
   ExecStart=/usr/local/sbin/restic-backup.sh

2. Creați timerul:

   nano /etc/systemd/system/restic-backup.timer

   [Unit]
   Description=Backup restic zilnic
   
   [Timer]
   OnCalendar=*-*-* 03:00:00
   RandomizedDelaySec=30min
   Persistent=true
   
   [Install]
   WantedBy=timers.target

3. Activați timerul și verificați următoarea rulare, în coloana NEXT:

   systemctl daemon-reload
   systemctl enable --now restic-backup.timer
   systemctl list-timers restic-backup.timer

4. Rulați serviciul o dată și citiți jurnalul:

   systemctl start restic-backup.service
   journalctl -u restic-backup.service -n 50

Copia pornește în fiecare zi între 03:00 și 03:30 (ora serverului), după dump-urile de la 02:00. Cu Persistent=true, o rulare ratată cât serverul a fost oprit se face la următoarea pornire.

Varianta simplă: rsync pe alt server

Dacă aveți un al doilea server, rsync copiază directoarele pe el prin SSH. rsync trebuie să fie instalat pe ambele servere. Instalarea și opțiunile lui: Transferul fișierelor pe server (scp, rsync, SFTP).

1. Pe serverul principal, creați o cheie SSH folosită doar pentru copii, fără parolă, ca s-o poată folosi cron:

   ssh-keygen -t ed25519 -f /root/.ssh/backup_ed25519 -N ""
   cat /root/.ssh/backup_ed25519.pub

2. Adăugați linia afișată în /root/.ssh/authorized_keys pe serverul de backup. Dacă și acesta este la BLACKBOX, folosiți „Adaugă cheie SSH” de pe cardul lui: Adăugarea și ștergerea cheilor SSH pe server.

3. Creați directorul de destinație și rulați prima copiere de mână. La prima conectare, confirmați cheia serverului de backup cu yes:

   ssh -i /root/.ssh/backup_ed25519 root@IP_BACKUP "mkdir -p /backups/NUME_SERVER"
   rsync -aR --delete -e "ssh -i /root/.ssh/backup_ed25519" /etc /var/www /var/backups/db root@IP_BACKUP:/backups/NUME_SERVER/

   Cu -R, căile se păstrează complet: pe serverul de backup apar /backups/NUME_SERVER/etc, /backups/NUME_SERVER/var/www și așa mai departe.

4. Programați copierea zilnic la 03:30, în fișierul /etc/cron.d/backup-rsync:

   30 3 * * * root rsync -aR --delete -e "ssh -i /root/.ssh/backup_ed25519" /etc /var/www /var/backups/db root@IP_BACKUP:/backups/NUME_SERVER/ >> /var/log/backup-rsync.log 2>&1

rsync păstrează doar ultima stare: cu --delete, un fișier șters sau stricat pe server dispare și din copie la rularea următoare. În plus, fișierele de pe serverul de backup nu sunt criptate. Pentru istoric și criptare, folosiți restic prin SFTP pe același server. Adăugați în /root/.ssh/config:

Host backup
    HostName IP_BACKUP
    User root
    IdentityFile /root/.ssh/backup_ed25519

Fișierul /etc/restic/env conține atunci doar aceste două rânduri:

RESTIC_REPOSITORY=sftp:backup:/backups/NUME_SERVER-restic
RESTIC_PASSWORD_FILE=/etc/restic/password

Restul pașilor sunt cei din secțiunea despre restic: instalarea, parola, inițializarea, scriptul și timerul.

Criptarea copiilor din afara serverului

• restic criptează totul cu parola depozitului înainte de trimitere. Furnizorul de stocare vede doar date criptate.
• SSH, deci și rsync și scp, criptează datele doar pe drum. Dacă destinația nu vă aparține, criptați fișierele înainte de copiere, de exemplu cu gpg și o parolă păstrată într-un fișier (pachetul gnupg pe Ubuntu și Debian, gnupg2 pe AlmaLinux și CentOS Stream):

openssl rand -base64 32 > /root/.backup-pass
chmod 600 /root/.backup-pass
gpg --batch --yes --pinentry-mode loopback --passphrase-file /root/.backup-pass --symmetric --cipher-algo AES256 -o FISIER.gpg FISIER

Decriptarea:

gpg --batch --pinentry-mode loopback --passphrase-file /root/.backup-pass -o FISIER -d FISIER.gpg

Păstrați și conținutul lui /root/.backup-pass în managerul de parole.

Securitate Fișierele /etc/restic/env, /etc/restic/password și cheia /root/.ssh/backup_ed25519 dau acces la copii; cheia dă chiar acces root la serverul de backup. Dacă serverul este compromis, atacatorul le poate folosi ca să șteargă copiile. Păstrați și o copie pe care serverul nu o poate șterge, de exemplu descărcată periodic pe calculatorul dvs.

Testați restaurarea cel puțin o dată pe lună

O copie pe care nu ați restaurat-o niciodată nu este o garanție. O dată pe lună și după orice modificare a scripturilor, restaurați într-un director temporar, nu peste datele în uz.

1. Încărcați setările, verificați lista de copii și integritatea depozitului:

   set -a
   . /etc/restic/env
   set +a
   restic snapshots
   restic check

   Ultima copie trebuie să fie din ultimele 24 de ore, iar restic check trebuie să se termine cu no errors were found.

2. Restaurați configurația și dump-urile într-un director temporar:

   restic restore latest --target /root/restore-test --include /etc --include /var/backups/db
   ls -lh /root/restore-test/var/backups/db

3. Încărcați dump-ul într-o bază de test și verificați tabelele și câteva înregistrări recente (de exemplu ultima comandă sau ultimul articol publicat). Rulați ultima comandă din bloc abia după verificare: ea șterge baza de test. Înlocuiți AAAA-LL-ZZ cu data din numele fișierului.

   MariaDB și MySQL:

   mysql -e "CREATE DATABASE restore_test"
   gunzip < /root/restore-test/var/backups/db/NUME_BD-AAAA-LL-ZZ.sql.gz | mysql restore_test
   mysql -e "SHOW TABLES" restore_test
   mysql -e "DROP DATABASE restore_test"

   PostgreSQL:

   sudo -u postgres createdb restore_test
   sudo -u postgres pg_restore -d restore_test < /root/restore-test/var/backups/db/NUME_BD-AAAA-LL-ZZ.dump
   sudo -u postgres psql -d restore_test -c "\dt"
   sudo -u postgres dropdb restore_test

4. Ștergeți directorul temporar:

   rm -rf /root/restore-test

Restaurarea ocupă spațiu pe disc, de aceea restaurați doar ce verificați (--include). Testul cel mai sigur este restaurarea completă pe un alt server, cu pornirea aplicației: este și repetiția pentru un incident real. Cu varianta rsync, copiați dump-ul înapoi de pe serverul de backup și încărcați-l la fel.

Copie suplimentară înainte de operațiile riscante

Faceți un dump nou și o copie restic cu eticheta manual, pe care forget nu o șterge:

/usr/local/sbin/db-dump.sh
set -a
. /etc/restic/env
set +a
restic backup /etc /root /var/www /var/spool/cron /var/backups/db --exclude-caches --tag manual
restic snapshots --tag manual

Când nu mai aveți nevoie de ea, ștergeți-o cu ID-ul din coloana ID:

restic forget ID_COPIE --prune

Înainte de a șterge un server, salvați în afara lui parola depozitului și setările din /etc/restic/env: fără ele nu mai ajungeți la copii. Descărcați și o copie pe calculator, cu rsync sau scp.

Întrebări frecvente

BLACKBOX poate restaura serverul dacă am șters ceva din greșeală? Nu. Panoul nu face copii automate și nu are snapshot-uri, iar un server șters nu mai poate fi recuperat. Restaurați din copiile dvs.

Ce înseamnă mesajul backup_extra_disabled de sub butonul „Backup”? Înseamnă că serviciul de backup automat nu este disponibil. Nu este o defecțiune a serverului, iar datele nu sunt afectate.

Cum restaurez un singur fișier șters? Încărcați setările restic, ca la pasul 1 din testul de restaurare. Restaurați fișierul într-un director temporar, apoi copiați-l la loc. Nu restaurați direct cu --target /: suprascrieți fișierele în uz. O copie mai veche o alegeți cu ID-ul ei din restic snapshots, în locul lui latest.

restic restore latest --target /root/restore-test --include /var/www/site/config.php
cp -a /root/restore-test/var/www/site/config.php /var/www/site/config.php

Am un plan „VPS hosting” cu panou de control. Ce fac? Panoul de control instalat poate avea propria funcție de backup; întrebați suportul ce oferă: Planurile „VPS hosting” cu panou de control. Oricum, copia trebuie să ajungă în afara serverului.

Am pierdut parola depozitului restic. Ce fac? Dacă fișierul /etc/restic/password mai există pe server, parola este acolo: salvați-o din nou în managerul de parole. Dacă parola nu mai există nicăieri, copiile din acel depozit nu mai pot fi citite. Creați atunci un depozit nou, cu altă parolă și alt folder în RESTIC_REPOSITORY, și faceți imediat o copie completă.

Pot cere echipei să configureze copiile? Dacă preferați să nu le configurați dvs., întrebați suportul despre administrarea serverului la cerere, cu ofertă separată: Servicii profesionale la cerere: administrare, DevOps, migrare.