Backup podataka Linux: rsync, Borg i Restic u praksi

Article Image

Zašto treba da imaš pouzdan backup na Linuxu odmah — i šta gubiš ako ga nemaš

Na Linux sistemima čuvanje podataka često deluje kao jednostavan zadatak dok sve radi kako treba. Međutim, kvar hardvera, ljudska greška ili ransomware mogu u jednom trenutku da izbrišu bitne fajlove. Ako želiš da minimizuješ rizik i ubrzaš oporavak, moraš da uspostaviš dosledan proces bekapa. U ovom delu naučićeš osnovne koncepte i razloge zašto izabrati alatke poput rsync, Borg ili Restic u zavisnosti od cilja: brzog kopiranja, efikasnog deduplikovanja ili enkryptovanih snimaka.

Koji problemi se rešavaju pravilnim backupom

  • Prevencija gubitka podataka usled greške korisnika ili sistema.
  • Smanjenje vremena oporavka (RTO) i gubitka podataka (RPO).
  • Zaštita od zlonamernih napada kroz offline ili deduplikovane arhive.
  • Efikasno korišćenje prostora zahvaljujući deduplikaciji i kompresiji.

Pregled alata: kad koristiš rsync, a kada da pređeš na Borg ili Restic

Ne postoji univerzalni alat; svaki ima svoje prednosti. Ti trebaš da razumeš osnovne razlike kako bi odabrao najbolju strategiju za svoj slučaj upotrebe.

rsync — brzo sinhronizovanje fajlova

rsync je odličan za jednostavne, brze kopije između lokalnih direktorijuma ili preko mreže. Koristi delta-prenos koji šalje samo promene u fajlovima, što je efikasno za velike fajlove koji se retko menjaju. Međutim, rsync ne pruža ugrađenu istoriju verzija, deduplikaciju na nivou blokova ili enkritpiju arhiva — te funkcionalnosti moraš da dodaš eksterno ili da kombinuješ rsync sa drugim alatima.

Borg i Restic — snapshoti, deduplikacija i sigurnost

Borg i Restic su moderne rešenja za sigurnosne kopije koje uključuju verzionisanje, deduplikaciju i opcionu enkripciju. Ako ti treba pouzdan remote backup sa manjim zauzećem prostora i snažnom zaštitom podataka, ova dva alata su često bolji izbor od samog rsync-a.

  • Borg: poznat po brzim operacijama i snažnoj deduplikaciji na nivou blokova; pogodan za servere i velike arhive.
  • Restic: ima slične osobine, jednostavniji je za početak i dobre su mu integracije sa cloud providerima.

U narednom delu ćeš videti konkretne komande, primer konfiguracije i primer scenarija kada kombinovati rsync sa Borgom ili Restic kako bi ostvario balans između brzine, bezbednosti i efikasnosti skladištenja.

Praktični primeri: rsync komande koje često koristiš

Evo nekoliko konkretnih rsync komandi koje su korisne za svakodnevni rad i brzo rešenje pre nego što pređeš na snapshot alat poput Borga ili Restica.

– Osnovna sinhronizacija lokalno (preslikavanje direktorijuma):
rsync -av –delete /home/user/ /mnt/backup/home/user/

– Sa rudimentarnom kompresijom preko SSH i limitom bita:
rsync -avz –bwlimit=5000 -e “ssh -T -c aes128-ctr” /data/ [email protected]:/data-backup/

– Bezbedno kopiranje velikih fajlova — zadržava delimične transfere:
rsync -av –partial –progress /large/image.img /mnt/backup/images/

– Izuzimanje privremenih i cache fajlova:
rsync -av –exclude=’*.cache’ –exclude=’/tmp/’ /home/user/ /mnt/backup/home/user/

– Korišćenje snapshot stila imena (timestamped):
DEST=/mnt/backup/home/user-$(date +%F_%H%M)
rsync -a –link-dest=/mnt/backup/home/current /home/user/ $DEST
rm -f /mnt/backup/home/current && ln -s $DEST /mnt/backup/home/current

Objašnjenje: –link-dest omogućava da se stvore “snapshot” direktorijumi sa hard linkovima za nepromenjene fajlove — to daje izgled verzionisanja bez dodatnog prostora za nekorišćene fajlove. Ipak, ovo nije enkriptovano i ne pruža deduplikaciju na nivou blokova.

Za automatizaciju koristi cron ili systemd timers. Primer crontab zapisa koji svakodnevno pokreće rsync u 2:30:
30 2 * /usr/bin/rsync -a –delete /home/user/ /mnt/backup/home/user/

Ne zaboravi test restore: povremeno kopiraj nekoliko fajlova iz bekapa na lokaciju za test i proveri integritet i dozvole.

Article Image

Primena Borg-a i Restic-a — inicijalizacija, backup, održavanje i kombinacije sa rsync-om

Borg i Restic rade drugačije od rsync-a: repo je verzionisan, deduplikovan i može biti enkriptovan. Osnovni tok rada: inicijalizacija repozitorijuma, redovan backup, rotacija (prune/forget), i testovi restauracije.

Borg — primeri:
– Inicijalizacija (lokalno, repokey enkripcija):
borg init –encryption=repokey /srv/backup/borg-repo

– Kreiranje snapshot-a:
borg create –stats –compression lz4 /srv/backup/borg-repo::home-{now:%Y-%m-%d} /home/user

– Rotacija čuvanja (primer: čuvaj 7 dnevnih, 4 nedeljna, 6 mesečnih):
borg prune -v –list /srv/backup/borg-repo –keep-daily=7 –keep-weekly=4 –keep-monthly=6

– Provera repoa:
borg check /srv/backup/borg-repo

Restic — primeri:
– Inicijalizacija s lozinkom iz okruženja:
export RESTIC_PASSWORD=”tajna”
restic init –repo s3:https://s3.example.com/bucket

– Backup:
restic -r s3:https://s3.example.com/bucket backup /home/user –exclude /home/user/Downloads

– Politika zadržavanja i pranje:
restic -r s3:https://s3.example.com/bucket forget –keep-daily 7 –keep-weekly 4 –keep-monthly 6 –prune

– Provera i restore:
restic -r s3:… check
restic -r s3:… restore latest –target /tmp/restore-test

Kombinovanje rsync + Borg/Restic — praktičan scenario:
– Koristi rsync kao brz lokalni mirror dnevno (niska latencija, brz pristup), a zatim jednom dnevno push-uj taj mirror u Borg/Restic repo. Prednost: rsync brzo sinhronizuje promene sa radne stanice na lokalni NAS, a Borg/Restic na NAS-u radi deduplikovane, enkriptovane snimke koje šalješ dalje (remote/van-lokacijski).
– Primer skripte (schematic):
1) rsync -> /mnt/backup/current
2) borg create /srv/backup/repo::host-{now:%Y-%m-%d} /mnt/backup/current
3) borg prune …

Saveti:
– Uvek čuvaj kopiju privatnog ključa/lozinke za repo (offline).
– Testiraj restore redovno; bez provere, backup je samo iluzija.
– Prilagodi kompresiju i chunk veličinu ako radiš sa velikim binarnim fajlovima (Borg opcije chunker-config; Restic automatski funguje ali ima flags za performance).
– Ako koristiš cloud (S3, Backblaze B2), prati troškove izlaznog saobraćaja i broj GET/PUT operacija.

U sledećem delu pokazaćemo konkretne skripte za automatizaciju, systemd timer primer i najbolje prakse za testiranje i verifikaciju restauracije.

Article Image

Kako nastaviti i održavati sistem bekapa

Nakon što uspostaviš osnovni tok bekapa (rsync za brze mirror-e i Borg/Restic za verzionisane, deduplikovane snimke), važno je da to pretvoriš u proces, a ne u jednokratnu radnju. Postavi raspored, beleži procedure za restore, čuvaj pristupne podatke offline i testiraj povremeno kompletan oporavak. Praćenje logova, alarmi za neuspehe i redovna provera integriteta repozitorijuma dramatično smanjuju rizik da ćeš otkriti problem tek kada bude prekasno.

  • Automatizuj zadatke pomoću cron/systemd timer-a i dodaj notifikacije (e‑mail, Slack) za greške.
  • Čuvaj offline i offsite kopije ključeva/lozinki i dokumentuj proceduru vraćanja podataka.
  • Planiraj periodične test-restore operacije i verifikuj aplikativni rad nakon vraćanja fajlova.
  • Prati troškove i ograničenja cloud provajdera ako koristiš S3/B2 — možeš optimizovati frekvenciju i veličine snimaka.

Ako ti treba dodatna tehnička referenca za brzi start sa jednim od alata, pogledaj Restic zvaničnu dokumentaciju.

Frequently Asked Questions

Kako često treba da pokrećem backup?

Frekvencija zavisi od tvojih RPO/RTO zahteva: za radne stanice dnevni backup često je dovoljan, za baze podataka ili kritične servise razmisli o čestim inkrementalnim snapshot-ima (satno ili na nivou transakcija). Kombinuj brze lokalne rsync mirror-e sa periodicnim snapshot-ima u Borg/Restic za balans između brzine restore-a i sigurnosti.

Da li mogu da koristim rsync umesto Borga/Restica ako imam dovoljno prostora?

Možeš, ali rsync sam po sebi ne daje deduplikaciju, enkripciju repozitorijuma ni jednostavan rollback na ranije verzije. Ako ti prostor i sigurnost nisu problem, rsync radi za osnovne mirror-e; za verzionisane i efikasne remontačne arhive bolje su rešenja kao Borg ili Restic.

Gde i kako da čuvam ključeve i lozinke za repozitorijume?

Ključeve i lozinke čuvaj van mreže (offline), u trezoru za lozinke ili na šifrovanom USB uređaju, uz fizičku rezervnu kopiju na sigurnoj lokaciji. Nikada ih ne ostavljaj u plain‑text skriptama. Takođe dokumentuj proceduru povraćaja pristupa i testiraj je povremeno kako bi bio siguran da možeš da obnoviš repozitorijum u slučaju gubitka glavnog pristupa.