Backup Homelab: strategia 3-2-1 cu Restic, Borg și Kopia

Un homelab poate începe cu un Raspberry Pi și câteva containere Docker și poate ajunge foarte repede la zeci de servicii: Nextcloud, Home Assistant, Jellyfin, Immich, Vaultwarden, Grafana, baze de date, reverse proxy, DNS, servere virtuale și mașini Proxmox.

Problema apare atunci când unul dintre disk-uri moare, o bază de date se corupe, un upgrade greșit șterge datele sau un administrator execută comanda potrivită pe serverul greșit.

În acel moment nu mai contează cât de elegant este dashboard-ul homelab-ului. Contează un singur lucru: poți restaura datele?

În ghidul nostru despre backup pentru homelab și self-hosting am introdus problema. În acest articol mergem mult mai departe și construim o strategie reală de backup, folosind aplicații gratuite și open-source precum Restic, BorgBackup, Kopia, Proxmox Backup Server, UrBackup și Duplicati.

Vom discuta și despre Docker, baze de date, fișiere de configurare, snapshot-uri, retenție, backup off-site, automatizare și, cel mai important, testarea restaurării.

Backup-ul nu începe cu alegerea unei aplicații

Una dintre cele mai frecvente greșeli este să începem prin întrebarea:

Care este cea mai bună aplicație de backup?

Întrebarea corectă este:

Ce date trebuie să pot recupera și cât timp îmi permit să pierd?

Abia după ce răspundem la această întrebare alegem instrumentele.

RPO și RTO: două concepte importante

Chiar și într-un homelab merită să înțelegem două concepte folosite în infrastructurile profesionale.

RPO — Recovery Point Objective

RPO descrie câtă informație ne permitem să pierdem.

Dacă facem backup o dată pe zi, în cel mai rău caz putem pierde aproape 24 de ore de modificări.

Backup la 03:00
Incident la 02:55 în ziua următoare

Pierdere posibilă:
aproape 24 ore

RTO — Recovery Time Objective

RTO reprezintă timpul în care vrem să readucem serviciul în funcțiune.

Pentru un server DNS intern poate vrem un restore în câteva minute. Pentru biblioteca Jellyfin probabil putem accepta câteva ore.

Strategia 3-2-1

Regula clasică este simplă:

3 copii ale datelor;
pe cel puțin 2 tipuri sau sisteme de stocare;
cel puțin 1 copie off-site.

Pentru un homelab putem implementa regula astfel:

Copie 1
Datele active
Server principal

        ↓

Copie 2
Backup local
NAS / HDD / alt server

        ↓

Copie 3
Backup off-site
altă locație / object storage / server remote

3-2-1-1-0

O variantă mai modernă extinde ideea:

3 copii;
2 medii sau sisteme diferite;
1 copie off-site;
1 copie offline sau immutable;
0 erori detectate la verificarea backup-ului.

Ultimele două puncte sunt foarte importante în contextul ransomware-ului și al erorilor administrative.

Un disk USB conectat permanent nu este neapărat protecție suficientă

Dacă serverul compromis poate scrie și șterge direct backup-ul, un atacator sau un script greșit poate distruge atât datele originale, cât și copiile de siguranță.

Din acest motiv, pentru date importante merită să existe cel puțin una dintre variantele următoare:

un disk conectat doar în timpul backup-ului;
un server remote cu acces restrictiv;
snapshot-uri protejate pe NAS;
object storage cu versioning sau immutability;
o copie păstrată fizic în altă locație.

Backup, snapshot și sincronizare nu sunt același lucru

Este important să facem diferența.

Sincronizare

Instrumente precum rsync sau Syncthing pot replica foarte bine datele.

Dar dacă ștergem accidental un fișier și ștergerea este sincronizată imediat pe destinație, avem două copii identice ale aceleiași probleme.

Vezi și rsync: backup și sincronizare eficientă în Linux.

Snapshot

Un snapshot ZFS, Btrfs, LVM sau Proxmox este excelent pentru recuperare rapidă.

Dar dacă snapshot-ul se află pe același storage care moare fizic, snapshot-ul dispare împreună cu datele originale.

Backup

Un backup real păstrează istoricul datelor într-o locație separată și permite revenirea la un punct anterior în timp.

Ce trebuie salvat într-un homelab?

Nu toate datele au aceeași valoare.

De regulă, cele mai importante sunt:

fișiere personale;
fotografii și documente;
baze de date;
configurațiile aplicațiilor;
fișiere Docker Compose;
fișiere .env;
certificate și chei private;
configurații reverse proxy;
configurații DNS;
configurații VPN;
automatizări și scripturi;
configurații Home Assistant;
datele aplicațiilor self-hosted;
configurația hypervisorului;
VM-uri și containere importante.

Ce nu trebuie neapărat salvat?

Unele date pot fi reconstruite mai ușor decât restaurate.

cache-uri;
imagini Docker care pot fi descărcate din nou;
fișiere temporare;
loguri fără valoare istorică;
package cache;
date generate automat.

Un backup mai mic este mai rapid, mai ieftin și mai simplu de verificat.

Inventarul înaintea backup-ului

Înainte de alegerea aplicației, merită să vedem unde se află efectiv datele.

lsblk
findmnt
df -h
du -sh /srv /opt /home /etc 2>/dev/null

Pentru Docker:

docker ps
docker volume ls
docker system df

Exemplu de arhitectură de backup pentru homelab

Să luăm următorul exemplu:

Server principal
homelab01
192.168.10.10

Date:
  /srv
  /opt/stacks
  /etc
  baze de date

Backup local:
  /mnt/backup

Backup remote:
  backup02.example.net
  SFTP / SSH

Copie offline:
  HDD USB păstrat separat

Strategia rezultată:

                  +----------------+
                  | homelab01      |
                  | date active    |
                  +-------+--------+
                          |
                 +--------+--------+
                 |                 |
                 v                 v
          +-------------+    +-------------+
          | Backup      |    | Backup      |
          | local       |    | off-site    |
          | /mnt/backup |    | SFTP/cloud  |
          +-------------+    +-------------+
                 |
                 v
          +-------------+
          | HDD offline |
          +-------------+

Aplicații gratuite pentru backup în homelab

Aplicație	Interfață	Potrivită pentru	Punct forte
Restic	CLI	Linux, servere, cloud	simplu, criptat, deduplicat
BorgBackup	CLI	servere Linux și SSH	deduplicare foarte eficientă
Kopia	CLI + GUI	servere și desktop	multe backend-uri și GUI
Proxmox Backup Server	Web	Proxmox VE	VM și LXC
UrBackup	Web + agent	PC-uri și servere	file și image backup
Duplicati	Web/GUI	desktop și homelab	ușor de configurat cu cloud

Restic

Restic este una dintre alegerile mele preferate pentru un server Linux deoarece are o filozofie simplă: repository criptat, snapshot-uri, deduplicare și suport pentru mai multe tipuri de storage.

Este potrivit mai ales pentru backup-uri automate de fișiere și directoare.

Instalare Restic

Ubuntu și Debian:

sudo apt update
sudo apt install restic

AlmaLinux și Rocky Linux:

sudo dnf install restic

Primul repository Restic local

Să presupunem că avem un disk de backup montat în:

/mnt/backup

Creăm directorul:

sudo mkdir -p /mnt/backup/restic-homelab

Creăm un fișier separat pentru parola repository-ului:

sudo mkdir -p /etc/restic
sudo chmod 700 /etc/restic

sudo nano /etc/restic/local-password

sudo chmod 600 /etc/restic/local-password

Parola trebuie păstrată și separat de server. Dacă pierdem parola unui repository Restic criptat, pierdem accesul la backup.

Inițializarea repository-ului

sudo restic \
  -r /mnt/backup/restic-homelab \
  --password-file /etc/restic/local-password \
  init

Primul backup Restic

sudo restic \
  -r /mnt/backup/restic-homelab \
  --password-file /etc/restic/local-password \
  backup \
  /etc \
  /srv \
  /opt/stacks

La următoarele execuții Restic nu trebuie să păstreze din nou toate datele identice. Repository-ul folosește deduplicare, iar backup-urile sunt reprezentate prin snapshot-uri.

Verificarea snapshot-urilor

sudo restic \
  -r /mnt/backup/restic-homelab \
  --password-file /etc/restic/local-password \
  snapshots

Backup off-site cu Restic prin SFTP

Un repository aflat pe același server nu ne protejează împotriva pierderii întregului sistem.

Putem crea un utilizator dedicat pe un server remote:

[email protected]

și folosi un repository de forma:

sftp:[email protected]:/srv/restic/homelab01

Inițializare:

sudo restic \
  -r sftp:[email protected]:/srv/restic/homelab01 \
  --password-file /etc/restic/remote-password \
  init

Pentru automatizare este recomandată autentificarea SSH cu cheie dedicată, nu introducerea parolei interactive la fiecare backup.

Nu folosi root pe serverul de backup dacă nu este necesar

Pe serverul remote este mai sigur să existe un utilizator dedicat:

backup

care are acces doar la repository-ul său.

În acest fel compromiterea unui server din homelab nu oferă automat privilegii administrative complete asupra serverului de backup.

Politica de retenție

Nu avem nevoie neapărat de câte un backup complet pentru fiecare zi din ultimii cinci ani.

O politică rezonabilă pentru un homelab poate fi:

7 backup-uri zilnice;
5 backup-uri săptămânale;
12 backup-uri lunare;
3 backup-uri anuale.

Cu Restic:

sudo restic \
  -r /mnt/backup/restic-homelab \
  --password-file /etc/restic/local-password \
  forget \
  --keep-daily 7 \
  --keep-weekly 5 \
  --keep-monthly 12 \
  --keep-yearly 3

După politica de retenție putem recupera spațiul neutilizat prin:

sudo restic \
  -r /mnt/backup/restic-homelab \
  --password-file /etc/restic/local-password \
  prune

prune poate fi o operație intensă, deci nu este obligatoriu să fie executată după fiecare backup.

Verificarea repository-ului Restic

Un backup care nu a raportat eroare nu este automat un backup verificat.

sudo restic \
  -r /mnt/backup/restic-homelab \
  --password-file /etc/restic/local-password \
  check

Această verificare trebuie executată periodic.

Cel mai important test: restore

Cea mai bună metodă de a verifica backup-ul este să restaurăm efectiv ceva.

sudo mkdir -p /tmp/restic-restore-test

sudo restic \
  -r /mnt/backup/restic-homelab \
  --password-file /etc/restic/local-password \
  restore latest \
  --target /tmp/restic-restore-test

Apoi verificăm conținutul:

ls -lah /tmp/restic-restore-test

Primul restore nu trebuie făcut în ziua în care ai pierdut datele.

Backup-ul bazelor de date

Bazele de date necesită mai multă atenție decât un director cu fotografii.

Copierea directă a fișierelor unei baze de date aflate în funcțiune poate produce o copie inconsistentă.

Pentru multe homelab-uri este mai sigur să generăm mai întâi un dump logic și apoi să salvăm dump-ul cu Restic, Borg sau Kopia.

MariaDB / MySQL

mkdir -p /var/backups/databases

mysqldump \
  --single-transaction \
  --quick \
  --routines \
  --events \
  --triggers \
  --all-databases \
  | gzip > /var/backups/databases/mysql-all.sql.gz

Pentru automatizare, credentialele bazei de date nu ar trebui puse direct în linia de comandă și nici într-un script world-readable.

PostgreSQL

mkdir -p /var/backups/databases

sudo -u postgres pg_dumpall \
  | gzip \
  > /var/backups/databases/postgresql-all.sql.gz

Backup Docker: nu salva doar docker-compose.yml

Fișierul Compose ne permite să recreăm containerele, dar nu conține automat datele persistente.

Un stack poate avea:

/opt/stacks/nextcloud/
├── compose.yml
├── .env
└── config/

/srv/nextcloud-data/

/var/lib/docker/volumes/...

Pentru un restore complet avem nevoie de:

Compose YAML;
fișierele de configurare;
variabilele și secretele necesare;
datele persistente;
baza de date;
documentația privind versiunea aplicației.

Nu copia orbește un volum cu o bază de date live

Dacă un volum Docker conține PostgreSQL, MariaDB sau alt motor de baze de date în execuție, simpla arhivare a directorului nu garantează consistența.

Preferă una dintre abordările:

dump logic al bazei de date;
mecanismul oficial de backup al aplicației;
snapshot consistent al storage-ului;
oprirea temporară a serviciului înaintea copiei.

Exemplu de structură de staging

/var/backups/homelab-staging/
├── databases/
│   ├── mysql-all.sql.gz
│   └── postgresql-all.sql.gz
├── configs/
└── inventory/

Restic salvează apoi atât datele aplicațiilor, cât și acest staging:

restic backup \
  /etc \
  /opt/stacks \
  /srv \
  /var/backups/homelab-staging

Un script real de backup Restic

Putem automatiza procesul într-un script.

sudo nano /usr/local/sbin/homelab-backup.sh

#!/bin/bash

set -euo pipefail

exec 9>/run/lock/homelab-backup.lock

if ! flock -n 9; then
    echo "Un alt backup ruleaza deja."
    exit 1
fi

REPO="/mnt/backup/restic-homelab"
PASSWORD="/etc/restic/local-password"
STAGE="/var/backups/homelab-staging"

mkdir -p "$STAGE/databases"

echo "[$(date)] Incep backup-ul"

# MariaDB/MySQL
if command -v mysqldump >/dev/null 2>&1; then
    mysqldump \
        --single-transaction \
        --quick \
        --routines \
        --events \
        --triggers \
        --all-databases \
        | gzip \
        > "$STAGE/databases/mysql-all.sql.gz"
fi

# PostgreSQL
if command -v pg_dumpall >/dev/null 2>&1; then
    sudo -u postgres pg_dumpall \
        | gzip \
        > "$STAGE/databases/postgresql-all.sql.gz"
fi

restic \
    -r "$REPO" \
    --password-file "$PASSWORD" \
    backup \
    /etc \
    /opt/stacks \
    /srv \
    "$STAGE"

restic \
    -r "$REPO" \
    --password-file "$PASSWORD" \
    forget \
    --keep-daily 7 \
    --keep-weekly 5 \
    --keep-monthly 12 \
    --keep-yearly 3

echo "[$(date)] Backup terminat"

După creare:

sudo chmod 700 /usr/local/sbin/homelab-backup.sh

Automatizare cu systemd

Pentru servere Linux prefer systemd timers în locul unor intrări cron uitate prin sistem.

sudo tee /etc/systemd/system/homelab-backup.service > /dev/null <<'EOF'
[Unit]
Description=Homelab Restic Backup
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/homelab-backup.sh
EOF

Timer:

sudo tee /etc/systemd/system/homelab-backup.timer > /dev/null <<'EOF'
[Unit]
Description=Daily Homelab Backup

[Timer]
OnCalendar=*-*-* 03:15:00
Persistent=true
RandomizedDelaySec=10m

[Install]
WantedBy=timers.target
EOF

Activare:

sudo systemctl daemon-reload
sudo systemctl enable --now homelab-backup.timer

Verificare:

systemctl list-timers | grep homelab
systemctl status homelab-backup.timer

Verificarea ultimului backup

journalctl \
  -u homelab-backup.service \
  -n 100 \
  --no-pager

Un job automat fără monitorizare este doar o presupunere că backup-ul funcționează.

Monitorizarea generală a serverului este explicată și în ghidul nostru pentru diagnosticarea și monitorizarea unui Linux Server.

BorgBackup

BorgBackup este o alternativă excelentă pentru administratori Linux. Oferă deduplicare, compresie, criptare și repository-uri locale sau accesibile prin SSH.

Este foarte potrivit atunci când ai mai multe servere Linux și un server dedicat pentru backup.

Instalare Borg

sudo apt install borgbackup

sau, în funcție de distribuție și repository-uri:

sudo dnf install borgbackup

Repository Borg local

sudo mkdir -p /mnt/backup/borg-homelab

sudo borg init \
  --encryption=repokey-blake2 \
  /mnt/backup/borg-homelab

Crearea unui backup Borg

sudo borg create \
  --stats \
  --compression zstd,3 \
  /mnt/backup/borg-homelab::homelab-{now:%Y-%m-%d_%H-%M} \
  /etc \
  /srv \
  /opt/stacks

Retenție cu Borg

Înainte de ștergerea arhivelor vechi este o idee bună să executăm mai întâi un dry-run:

sudo borg prune \
  --dry-run \
  --list \
  --keep-daily 7 \
  --keep-weekly 5 \
  --keep-monthly 12 \
  --keep-yearly 3 \
  /mnt/backup/borg-homelab

Dacă rezultatul este cel așteptat, eliminăm --dry-run.

După prune, spațiul poate fi recuperat prin compactarea repository-ului:

sudo borg compact /mnt/backup/borg-homelab

Kopia

Kopia este foarte interesantă pentru un homelab mixt deoarece oferă atât CLI, cât și interfață grafică și poate salva snapshot-uri criptate pe storage local, NAS, SFTP sau object storage.

Un repository local poate fi creat cu:

kopia repository create filesystem \
  --path=/mnt/backup/kopia

Apoi:

kopia snapshot create /srv
kopia snapshot create /opt/stacks

kopia snapshot list

Kopia este o alegere bună și pentru utilizatorii care vor un produs modern, dar nu vor să administreze întregul sistem exclusiv din shell.

Proxmox Backup Server

Dacă homelab-ul este construit în jurul Proxmox VE, Proxmox Backup Server este una dintre cele mai naturale soluții.

Este proiectat pentru backup-ul mașinilor virtuale și containerelor și oferă funcții precum:

backup incremental;
deduplicare;
compresie;
verificarea backup-urilor;
retenție;
criptare client-side;
integrare directă cu Proxmox VE.

O arhitectură foarte bună poate arăta astfel:

Proxmox VE
    |
    |
    v
Proxmox Backup Server
    |
    +---- datastore local
    |
    +---- sync / copie off-site

PBS nu trebuie să fie singura copie

Chiar dacă Proxmox Backup Server este excelent, un singur PBS aflat în același rack și alimentat de aceeași infrastructură nu satisface singur strategia 3-2-1.

Un incendiu, furt, supratensiune sau eroare administrativă poate afecta atât hypervisorul, cât și serverul de backup.

UrBackup

UrBackup folosește o arhitectură client-server și este util mai ales atunci când în homelab avem mai multe desktop-uri și laptopuri.

Poate realiza backup-uri de fișiere și, pentru sistemele suportate, backup-uri de tip image. Administrarea se face printr-o interfață web.

Este o opțiune interesantă pentru:

PC-urile familiei;
stații Windows;
desktop-uri Linux;
backup centralizat într-un NAS sau server.

Duplicati

Duplicati este potrivit în special pentru utilizatorii care preferă o interfață grafică și vor să trimită backup-uri criptate către servicii cloud, SFTP, WebDAV sau diverse platforme de object storage.

Ca pentru orice soluție de backup, nu este suficient să configurăm job-ul și să uităm de el. Trebuie verificate periodic logurile și restaurarea.

Restic vs Borg vs Kopia

	Restic	Borg	Kopia
CLI	Da	Da	Da
GUI oficial	Nu este principalul model	Nu este principalul model	Da
Criptare	Da	Da	Da
Deduplicare	Da	Da	Da
NAS/local	Da	Da	Da
SFTP/remote	Da	SSH	Da
Object storage	Foarte bun	Mai puțin orientat direct spre cloud	Foarte bun

Ce aș alege pentru diferite homelab-uri?

Pentru un server Linux simplu:

Restic

Pentru mai multe servere Linux și repository remote prin SSH:

BorgBackup

Pentru CLI + GUI și mai multe tipuri de storage:

Kopia

Pentru Proxmox VE:

Proxmox Backup Server

Pentru PC-uri Windows/Linux administrate central:

UrBackup

Pentru utilizatori care preferă GUI și backup către cloud:

Duplicati

Snapshot-urile ZFS și Btrfs

Dacă serverul folosește ZFS sau Btrfs, snapshot-urile sunt extrem de utile pentru recuperarea rapidă după o modificare greșită.

Exemplu ZFS:

sudo zfs snapshot tank/data@before-upgrade

Exemplu Btrfs:

sudo btrfs subvolume snapshot \
  -r /srv/data \
  /snapshots/data-$(date +%F)

Dar repetăm regula importantă: un snapshot păstrat pe același disk nu înlocuiește un backup separat.

Backup înainte de upgrade

Pentru aplicațiile self-hosted, un backup înainte de upgrade este una dintre cele mai simple măsuri de protecție.

1. dump baza de date
2. backup configurație
3. backup date
4. verificare backup
5. upgrade
6. test aplicație

Nu presupune că rollback-ul aplicației va fi posibil dacă schema bazei de date a fost deja modificată.

Backup-ul secretelor

În infrastructura self-hosted există multe fișiere mici care pot fi mult mai importante decât un director de 2 TB cu media:

chei SSH;
chei WireGuard;
certificate private;
token-uri API;
fișiere .env;
parole de baze de date;
configurații DNS;
secrete de automatizare.

Acestea trebuie incluse într-un backup criptat și accesul la backup trebuie protejat foarte strict.

Pentru hardening general vezi și Securizarea unui Linux Server după instalare.

Nu păstra parola repository-ului doar pe server

Dacă serverul este distrus și singura copie a parolei Restic/Kopia/Borg era pe acel server, poți ajunge într-o situație absurdă: backup-ul există, dar nu îl mai poți decripta.

Păstrează informațiile de recovery într-o locație separată și sigură.

Documentează procedura de disaster recovery

Un fișier simplu precum:

DISASTER-RECOVERY.md

poate salva ore întregi de muncă.

Documentul ar trebui să conțină:

unde sunt backup-urile;
ce aplicație le-a creat;
cum se instalează clientul de backup;
cum se obține cheia/parola;
ordinea de restaurare;
dependențele dintre servicii;
configurația de rețea;
procedura de verificare.

Ordinea unui restore complet

Pentru un server self-hosted, restaurarea poate arăta astfel:

1. instalează sistemul de operare
2. configurează storage-ul
3. configurează rețeaua
4. instalează Docker / runtime
5. restaurează /opt/stacks
6. restaurează secretele
7. restaurează volumele de date
8. restaurează baza de date
9. pornește serviciile
10. verifică aplicațiile
11. verifică DNS/TLS
12. verifică integritatea datelor

Cât de des testăm restore-ul?

Pentru un homelab important, un test lunar sau trimestrial este mult mai bun decât niciun test.

Nu trebuie neapărat să reconstruim întregul datacenter în fiecare lună.

Putem testa:

restaurarea unui fișier;
restaurarea unui director;
importul unui dump SQL;
pornirea unei VM restaurate într-o rețea izolată;
restaurarea unei aplicații Docker de test.

Monitorizează și backup-ul

Un job care a funcționat timp de un an poate începe să eșueze pentru că:

disk-ul s-a umplut;
credentialele au expirat;
serverul remote nu mai este disponibil;
DNS-ul nu funcționează;
repository-ul a fost mutat;
un script s-a schimbat;
backup-ul durează mai mult decât intervalul dintre job-uri.

De aceea trebuie monitorizate cel puțin:

last successful backup
backup duration
backup size
repository free space
repository check
restore test

Checklist pentru backup-ul unui homelab

Fă inventarul tuturor datelor importante.
Definește RPO pentru serviciile importante.
Definește un RTO realist.
Nu confunda sincronizarea cu backup-ul.
Nu considera snapshot-ul local singura copie.
Folosește cel puțin strategia 3-2-1.
Păstrează o copie off-site.
Pentru date importante, păstrează și o copie offline sau immutable.
Salvează configurațiile Docker Compose.
Salvează fișierele .env în mod securizat.
Fă dump logic pentru bazele de date.
Nu copia orbește fișierele unei baze de date live.
Configurează retenția.
Monitorizează ultimul backup reușit.
Verifică periodic repository-ul.
Testează efectiv restore-ul.
Păstrează separat parola și cheile de recovery.
Documentează procedura de disaster recovery.
Testează backup-ul înainte de upgrade-uri majore.
Reevaluează strategia atunci când homelab-ul crește.

O configurație pe care aș folosi-o într-un homelab real

Pentru un homelab Linux cu Docker și câteva VM-uri, o arhitectură echilibrată ar putea fi:

Docker / Linux
    |
    +-- Restic zilnic
    |      |
    |      +-- repository local pe NAS
    |      |
    |      +-- repository off-site prin SFTP
    |
    +-- dump MariaDB/PostgreSQL
    |
    +-- snapshot înainte de upgrade

Proxmox VE
    |
    +-- Proxmox Backup Server
             |
             +-- datastore separat
             |
             +-- copie / sync off-site

Lunar
    |
    +-- test restore

Periodic
    |
    +-- copie offline

Nu este singura soluție corectă, dar separă suficient de bine datele active de backup și oferă mai multe niveluri de recuperare.

Resurse oficiale

Concluzie

Într-un homelab, backup-ul nu trebuie tratat ca o aplicație instalată o dată și uitată. Este un proces format din mai multe elemente: identificarea datelor importante, alegerea repository-urilor, automatizare, retenție, verificare și restaurare.

Restic, BorgBackup și Kopia sunt opțiuni excelente pentru fișiere și servere. Proxmox Backup Server este foarte potrivit pentru infrastructura Proxmox, iar UrBackup și Duplicati acoperă bine alte scenarii în care avem nevoie de administrare centralizată sau interfață grafică.

Instrumentul ales este însă doar jumătate din soluție. Un repository de backup aflat pe același disk, o bază de date copiată într-o stare inconsistentă sau un job automat care nu a mai funcționat de trei luni nu reprezintă o strategie de backup.

Un backup devine valoros abia în momentul în care ai demonstrat că îl poți restaura.

Dacă ești la început, citește mai întâi ghidul introductiv pentru backup în homelab și self-hosting, apoi construiește treptat o arhitectură 3-2-1 și testează restaurarea înainte ca aceasta să devină o urgență.

Backup pentru Homelab și Self-hosting: strategia 3-2-1 cu Restic, Borg, Kopia și Proxmox