BorgBackup vs Restic: care îți protejează de fapt datele de pe VPS?

Instrumentul de backup greșit este cel care îți blochează VPS-ul în timpul jobului săptămânal de curățare. BorgBackup și Restic sunt ambele instrumente mature de backup cu deduplicare. Ambele criptează. Ambele deduplică. Ambele trimit date prin SSH către un repository off-site. Diferența este cum se comportă atunci când serverul tău are 2 GB RAM și un buget de CPU limitat. Acest articol le compară pe baza utilizării reale de resurse, a fluxurilor de restaurare și a modurilor de eșec, cu un cadru de decizie pentru dimensiunile tipice de VPS ServerSpan.

Memoria este primul filtru

Pe un VPS KVM cu 2 vCPU și 2 GB RAM, un backup tipic Borg consumă 50 până la 150 MB de memorie. Restic ia de obicei 100 până la 200 MB pentru același set de date. Distanța crește în timpul mentenanței repository-ului. Operația de prune a Restic este cunoscută pentru a depăși 1 GB pe repository-uri multi-terabyte pentru că ține hash-urile de chunk-uri în memorie. Prune-ul Borg rămâne mai economic. Pe un VPS mic, acea diferență contează. O omorâre din lipsă de memorie în timpul unui job cron la ora 3 dimineața te lasă fără backup și cu un proces mort. Dacă VPS-ul tău are 1 GB RAM sau mai puțin, Borg este opțiunea implicită mai sigură. La 4 GB RAM sau mai mult, diferența de memorie devine irelevantă și alți factori preiau controlul.

Viteza de transfer favorizează Borg

Benchmark-uri pe sarcini de fișiere mixte arată Borg atingând 180 până la 220 MB/s local, în timp ce Restic gestionează 120 până la 160 MB/s. Diferența vine din nucleul mai strâns C/Cython al Borg versus overhead-ul runtime-ului Go al Restic. Pe o legătură de rețea, ambele instrumente sunt limitate de bandă, nu de CPU. Pe un LAN sau pe un link de datacenter rapid, Borg își termină fereastra de backup mai repede. Pentru o imagine de VPS de 50 GB, asta înseamnă diferența dintre un backup de douăzeci de minute și unul de patruzeci de minute. Dacă fereastra ta de backup este strâmtă și ținta este un alt server în același rack, Borg câștigă timp.

Restic câștigă la diversitatea platformelor

Restic vorbește nativ S3, Backblaze B2, Azure Blob și Google Cloud Storage. Borg gestionează stocarea locală și SSH/SFTP nativ. Pentru a ajunge la S3 cu Borg, montezi un bucket via rclone și îndrepți Borg către mount-ul local. Funcționează. Este și o altă piesă în mișcare care poate eșua la ora 2 dimineața când mount-ul cade. Dacă ținta ta de backup este un cloud object store, Restic este alegerea mai curată. Dacă ținta este un alt server Linux sau un serviciu de backup care expune Borg prin SSH, Borg este nativ și nu are nevoie de middleware.

Recuperarea unui fișier de config la ora 2 dimineața

Borg îți permite să montezi orice arhivă de backup ca un filesystem. Când îți lipsește un singur fișier de configurație și nu vrei să aștepți o restaurare completă, asta contează. Rulezi comanda de mount, navighezi prin arhivă ca printr-un director normal, copiezi fișierul și demontezi. Restic suportă și el montarea, dar fluxul tipic de restaurare în producție folosește țintire explicită a snapshot-ului cu flag-uri pentru calea țintă și fișierul specific. Într-o panică, navigarea este mai rapidă decât reconstruirea argumentelor de linie de comandă. Fluxul Borg arată așa:

borg mount ssh://user@backup-server/repo /mnt
cp /mnt/backup-2026-05-18/etc/nginx/nginx.conf /etc/nginx/
borg umount /mnt

Pentru o recuperare completă în caz de dezastru, ambele instrumente necesită o restaurare completă într-un director proaspăt. Montarea FUSE nu este un substitut pentru o procedură de restaurare testată. Este o scurtătură pentru greșelile mici care apar mai des decât defecțiunile totale de disc.

Corupția repository-ului și cum o raportează fiecare instrument

Ambele repository-uri se pot corupe. Ambele instrumente pot verifica. Rularea borg check verifică integritatea fiecărei arhive și raportează defecțiuni de segment. Dacă returnează o eroare de integritate cu un offset specific de fișier segment, ai un segment deteriorat. Check-ul Borg poate repara adesea asta cu flag-ul --repair, dar trebuie să accepti că poate elimina chunk-uri deteriorate pentru a restabili consistența. Restic check --read-data-subset 1% eșantionează un procent aleatoriu de 1% din date la fiecare rulare. Este un compromis practic pentru repository-uri mari. Un restic check --read-data complet pe un repository de terabyte durează ore și lovește serverul de backup. Dacă Restic raportează un mismatch de pack ID, ai un fișier pack truncat în timpul transferului. Reparația este de obicei un rebuild-index urmat de un prune. Niciun instrument nu va repara corupția automat fără comanda ta explicită. Ambele necesită să citești ieșirea și să iei o decizie.

Modul append-only și granița de încredere

Modul append-only previne ca un VPS compromis să își șteargă propriile backup-uri. Cu Borg, impui asta la nivelul SSH. Restricționezi utilizatorul de backup la borg serve --append-only în fișierul authorized_keys. Clientul poate crea arhive noi, dar nu poate curăța sau șterge arhive vechi. O mașină separată, de încredere, trebuie să ruleze jobul real de prune. Cu Restic, modul append-only necesită să rulezi backend-ul rest-server cu --append-only. Clientul Restic care trimite către o țintă SFTP simplă nu poate fi restricționat astfel. Trebuie să instalezi binarul rest-server pe host-ul tău de backup. Este un serviciu suplimentar de mentenat. Dacă faci backup către un cont SFTP generic pe un host partajat, restricția la nivel SSH a Borg este mai ușor de impus fără a instala software nou pe țintă.

Configurarea fiecărui instrument

Comenzile de inițializare stabilesc tonul pentru fluxul de lucru. Borg îți cere să alegi un mod de criptare de la început. Restic are nevoie de o cale de repository și o parolă. Ambele necesită ca directorul țintă să existe înainte să rulezi init.

# BorgBackup
borg init --encryption=repokey-blake2 ssh://user@backup-server/repo

# Restic
restic init -r sftp:user@backup-server:/repo

Borg folosește arhive denumite. Creezi o arhivă numită backup-{now} și Borg o stochează în repository. Restic folosește ID-uri de snapshot. Rulezi backup și Restic atribuie un hash. Arhivele denumite ale Borg sunt mai ușor de citit într-o panică. Hash-urile Restic sunt mai greu de tastat greșit, dar mai greu de reținut. Pentru automatizare, ambele instrumente citesc variabile de mediu sau fișiere de parolă. Niciun instrument nu îți stochează fraza de acces server-side. Pierderea ei înseamnă pierderea backup-ului. Stocheaz-o într-un manager de parole, nu în scriptul de backup.

Cifrele care decid

Indicator	BorgBackup	Restic
Viteză backup local	180-220 MB/s	120-160 MB/s
Memorie folosită (tipic)	50-150 MB	100-200 MB
Memorie la prune (repo mare)	Rămâne jos	Poate depăși 1 GB
Backends cloud native	Nu (via rclone)	Da (S3, B2, Azure, GCS)
SSH/SFTP nativ	Da	Da
Montare FUSE	Da	Da

Când să alegi care

Alege BorgBackup dacă VPS-ul tău are 2 GB RAM sau mai puțin, ținta ta de backup este un alt server Linux prin SSH, și vrei cel mai rapid flux de restaurare pentru salvări de fișiere unice. Alege Restic dacă ai nevoie de suport nativ S3 sau B2, faci backup de pe multiple sisteme de operare, sau VPS-ul tău are 4 GB RAM și preferi un singur binar static fără dependență Python. Ambele instrumente sunt exagerate pentru un site de 500 MB. Ambele sunt necesare pentru un server de bază de date de 500 GB. Niciun instrument nu înlocuiește un plan de recuperare în caz de dezastru. Pentru asta, ai nevoie de proceduri de restaurare testate și stocare off-site separată fizic de VPS-ul principal. Ghidul ServerSpan despre recuperare în caz de dezastru pe VPS detaliază construirea acelui plan. Dacă încă comparativ opțiuni de backup, articolul despre strategii automate de backup pentru VPS acoperă rsync și Restic în amploare.

Dacă preferi să nu gestionezi asta singur

Infrastructura de backup este utilă doar dacă joburile cron rulează, repository-urile rămân sănătoase, și cineva testează o restaurare la fiecare trimestru. Asta este muncă continuă. Dacă nu vrei să gestionezi scripturi de backup, ținte de stocare off-site și testări de restaurare la ora 2 dimineața, serviciul ServerSpan de administrare Linux include deploy automat BorgBackup sau Restic cu testare de restaurare monitorizată. Noi configurăm repository-ul, restricțiile append-only, planificările cron și verificările de integritate. Tu primești protecția fără serviciul de gardă.

Întrebări frecvente

Pot migra de la un instrument la celălalt fără să re-uploadez totul?

Nu. Formatele de repository sunt incompatibile. O migrație înseamnă inițializarea unui repository nou cu instrumentul țintă și rularea unui backup inițial proaspăt. Planifică banda și timpul.

Va rula vreunul pe un VPS de 1 GB RAM?

Borg va rula. Restic ar putea, în funcție de dimensiunea setului de date. Pentru un VPS de 1 GB, adaugă un fișier swap și monitorizează logurile OOM killer. Mai bine, folosește un VPS mai mare pentru orice critic de producție.

Ce se întâmplă dacă pierd parola repository-ului?

Pentru ambele instrumente, parola este cheia de criptare. Nu există mecanism de recuperare. Backup-urile sunt irecuperabile. Stochează fraza de acces într-un manager de parole care nu este pe serverul care face backup.

Pot face backup pe același VPS?

Poți, dar nu ar trebui. Un backup pe aceeași mașină protejează împotriva ștergerii accidentale, nu împotriva defecțiunii hardware sau ransomware. Mută datele de pe server.