Backup nije „imamo snapshot u panelu hostinga“. Backup je dokazana mogućnost vraćanja podataka u roku koji posao može preživjeti. Za male tvrtke na jednom ili nekoliko VPS-ova pravilo 3-2-1 i dalje radi bolje od većine „enterprise“ marketinških paketa, jer je jednostavno i provjerljivo.
Što znači 3-2-1 u praksi
Tri kopije podataka: produkcija plus barem dvije rezervne (npr. lokalni backup volumen i offsite). Dva različita medija ili sustava, npr. lokalni disk i objektni storage drugog providera, ne dva foldera na istom VPS-u. Jedna kopija offsite, izvan istog data centra i po mogućnosti izvan istog računa providera.
Cilj nije savršenstvo. Cilj je da ransomware, greška u rm, pokvaren disk ili nestanak providera ne izbrišu jedinu kopiju istine.
Što snimati na tipičnom VPS-u
Snimajte ono što ne možete ponovno izgenerirati iz Gita i dokumentacije. Baze idu kao logički dumpovi (pg_dump, mysqldump), ne samo datoteke dok baza radi. Uz to volumei i podaci aplikacija (uploadi, mediji, SQLite ako ga koristite, state koji nije u repou), plus konfiguracije: Compose datoteke, Nginx/Traefik config, systemd uniti, firewall pravila. Konfig bolje živi u Gitu, ali backup i dalje pomaže. Tajne držite zasebno i šifrirano; nikad u isti „javni“ tarball bez enkripcije.
Što obično ne treba backupati kao prioritet: OS paketi, Docker image cache, node_modules, build artefakte. To se ponovno instalira. Vrijeme i novac trošite na podatke i konfiguraciju.
Primjer: dump baze prije restic snimke
# PostgreSQL: logički dump (primjer)
sudo -u postgres pg_dump -Fc appdb -f /var/backups/appdb.dump
# MySQL/MariaDB
mysqldump --single-transaction --routines appdb | gzip > /var/backups/appdb.sql.gz
restic ili borg: dovoljno za SMB
Za 1 do 5 servera deduplicirani, šifrirani alati poput restic-a ili BorgBackup-a pokrivaju većinu potreba. Oba rade incremental snimke, enkripciju klijentske strane i više repozitorija (lokalno plus S3-kompatibilni storage).
restic: lokalni repo + remote
export RESTIC_REPOSITORY=/mnt/backup/restic-repo
export RESTIC_PASSWORD_FILE=/root/.restic-password
restic init
restic backup /var/backups /etc /srv/app/data \
--exclude /srv/app/data/cache
# Offsite (S3-kompatibilni endpoint, koncept)
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...
export RESTIC_REPOSITORY=s3:https://s3.example.com/bucket/repo
restic backup /var/backups /etc /srv/app/data
borg: slična ideja
export BORG_REPO=/mnt/backup/borg-repo
export BORG_PASSPHRASE_FILE=/root/.borg-passphrase
borg init --encryption=repokey-blake2 "$BORG_REPO"
borg create --stats "$BORG_REPO"::'{hostname}-{now}' \
/var/backups /etc /srv/app/data
Zakažite snimke preko systemd timer-a ili cron-a. Zadržite politiku zadržavanja (npr. dnevno 7, tjedno 4, mjesečno 6), inače disk i S3 račun rastu bez kontrole.
Offsite: drugi provider ili objektni storage
Offsite nije „drugi folder na istom VPS-u“. To je drugi račun, drugi provider ili barem drugi geografski region. Objektni storage (S3 API) dobro se slaže s restic/borg modelom. Alternativa: drugi VPS kod drugog providera koji prima samo sync/push backupa i nema produkcijski pristup internetu šire nego što treba.
Ako reverse proxy i TLS rješavate s Traefikom, backup konfiguracije i Let's Encrypt stanja treba ući u isti popis. Vidi Traefik kao reverse proxy na VPS-u.
RPO i RTO bez buzzword juhe
RPO kaže koliko podataka smijete izgubiti. Ako je odgovor „do 24 sata“, dnevni backup je dovoljan. Ako je „do 1 sat“, trebaju češći dumpovi i eventualno WAL/binlog. RTO kaže koliko dugo smije biti down dok vraćate: „isti dan“ nije isto što i „u roku sat vremena“.
Za tipičnu malu tvrtku na jednom VPS-u realan start: dnevni backup plus tjedni test restore. Ako netko traži RPO od minuta, to nije „bolji restic“. To je druga arhitektura (replikacija, managed DB, redundantni nodeovi).
Test restore je dio backupa
Backup koji nikad niste vratili nije backup. Jednom mjesečno (ili barem kvartalno) vratite dump na privremeni VPS ili Docker volumen i provjerite da aplikacija radi. Dokumentirajte korake: koji volume, koja naredba, koji secrets.
# restic: lista i restore u privremeni direktorij
restic snapshots
restic restore latest --target /tmp/restore-test
Ransomware kut: što stvarno pomaže
Ako napadač dobije root na produkcijskom VPS-u, može obrisati lokalne backupe. Zato offsite repo treba immutable / append-only politiku gdje je moguće, ili barem credentials koji s produkcije mogu samo pisati nove snimke, ne brisati stare. Odvojite backup credentials od svakodnevnog SSH pristupa.
Zašto same cloud snimke nisu dovoljne
Snimke providera često žive u istom računu i istom failure domainu. Snapshot diska dok baza nije konzistentna može dati nekonzistentne datoteke. Brisanje računa ili kompromitirani API ključ može obrisati i snimke. One ne zamjenjuju logički dump niti offsite 3-2-1.
Snimke providera su dobar dodatni sloj (brzi rollback cijelog diska), ne jedini plan.
Zaključak
Za VPS i male tvrtke: definirajte što je kritično, snimajte dumpove i volume podatke, koristite restic ili borg s enkripcijom, držite jednu kopiju van providera, i testirajte restore. Ako trebate pomoć oko postavljanja i automatizacije, javite se za DevOps usluge ili IT podršku.