Titkosított Linux biztonsági mentések 2026: restic, Borg és Kopia összehasonlítás

Frissítve: 2026. július 22.

A titkosított Linux biztonsági mentés lényege, hogy a mentési adat már a forrás gépen erős, hitelesített szimmetrikus titkosítást kap (jellemzően AES-256-GCM vagy ChaCha20-Poly1305), így a tároló szolgáltató, egy elveszett merevlemez vagy egy kompromittált backup szerver sem tud olvasható másolathoz jutni. 2026-ban három nyílt forrású megoldás dominálja a Linux ökoszisztémát: a restic, a BorgBackup és a Kopia. Mindhárom deduplikál, mindhárom titkosít alapértelmezésben, viszont a fenyegetésmodelljük és üzemeltetési profiljuk lényegesen eltér. Ez az útmutató architekt szemmel hasonlítja őket össze, és megmutatja, melyiket melyik forgatókönyvben érdemes választani.

• restic 0.17+: AES-256-CTR + Poly1305-AES, egyetlen statikus Go bináris, natív S3/B2/Azure/GCS/SFTP támogatás. A legkisebb operatív terhelés.
• BorgBackup 1.4 / 2.0: AES-256-CTR + HMAC-SHA256 (Borg 1.x) vagy ChaCha20-Poly1305 (Borg 2.0). Párhuzamos kliens még nincs, viszont a legjobb tömörítés (zstd 22).
• Kopia 0.18+: modern kripto (AES-256-GCM-HMAC-SHA256), tartalomcímezhető tár, beépített scheduler és webes felület. GUI-t igénylő csapatoknak.
• A titkosítás önmagában nem véd a zsarolóprogramok ellen: immutable (WORM) backend és „pull-based" tárolási modell kell.
• A 3-2-1-1-0 szabály 2026-os változata: 3 másolat, 2 különböző médium, 1 offsite, 1 immutable/air-gapped, 0 hiba a restore-teszten.
• Kulcsmenedzsment: age vagy KMS (AWS KMS, GCP KMS, HashiCorp Vault Transit). Soha ne a jelszó Bashben, ne a home dir plaintext fájljában.

Mit véd valójában a titkosított mentés? Fenyegetésmodell

Kezdjük az alapoknál. A titkosítás önmagában egyetlen dologra jó: bizalmasság. Az integritás, a rendelkezésre állás és a visszaállíthatóság külön kontrollokat igényel. Amikor fenyegetésmodellt rajzolok egy backup rendszerhez, mindig három szereplőt teszek a diagramra: (1) a védendő éles rendszer, (2) a mentést végző klienst futtató host, (3) a backup tár (S3 bucket, NFS share, offsite szerver). A támadó bármelyik ponton beülhet, és a titkosítás csak a (3)-ra ad garanciát. A felhő szolgáltató admin, egy ellopott lemez vagy egy sikertelen fizikai audit nem lát olvasható adatot.

Ami viszont nincs benne a titkosítás által lefedett fenyegetéstérben: a támadó, aki root jogot szerzett a mentési kliensen. Az ő pozíciójából a kulcs kiolvasható, a repó jelszó kilistázható a folyamat memóriájából, és (ami sokkal rosszabb) a mentések törölhetők. A modern zsarolóprogramok pontosan ezt csinálják 2024 óta: először a backupot pusztítják el, csak utána titkosítják az éles adatot. Ezért a mentési tár append-only vagy WORM (Write-Once-Read-Many) módja legalább annyira fontos, mint maga a repó titkosítás.

Mi az, ami elsőnek szakad? Őszintén szólva, nálunk 2025-ben egy gyakorló katasztrófa-teszten a kulcs tört meg. A passphrase egy 1Password vault-ban volt, amit senki nem tudott megnyitni, mert az egyetlen ember, aki tudta a master jelszót, kilépett. Ha nem tudsz visszaállítani, a mentés puszta illúzió. Ez a cikk végig ezt a gondolatot követi: minden döntést a „mi a blast radius, ha ez a komponens megszakad?" kérdés felől nézünk.

restic vs. Borg vs. Kopia: összehasonlító táblázat

Mielőtt bármelyiket telepítenéd, érdemes egyben látni a különbségeket. Az alábbi táblázat a 2026 júliusi kiadásokat veszi alapul (restic 0.17.3, BorgBackup 1.4.0 / 2.0.0b14, Kopia 0.18.2):

Jellemző	restic 0.17	BorgBackup 1.4/2.0	Kopia 0.18
Titkosítási algoritmus	AES-256-CTR + Poly1305-AES	AES-256-CTR + HMAC-SHA256 (1.x); ChaCha20-Poly1305 (2.0)	AES-256-GCM-HMAC-SHA256
Deduplikáció	tartalomdefiniált chunkolás (rolling hash)	Buzhash rolling	rolling hash, konfigurálható splitter
Natív backendek	S3, B2, Azure, GCS, SFTP, REST, local	SSH, local (S3-hoz rclone kell)	S3, B2, Azure, GCS, SFTP, WebDAV, local
Párhuzamos kliens ugyanahhoz a repóhoz	igen (lockolással)	nem (egy író kliens)	igen
Tömörítés	zstd (alap: auto)	zstd 1–22, lz4, zlib	zstd, pgzip, s2, deflate
Webes felület	nincs (közösségi projektek)	nincs	beépített
Beépített scheduler	nincs (systemd timer)	nincs (systemd timer)	igen
Bináris méret / függőségek	~25 MB statikus Go	~10 MB (Python)	~30 MB statikus Go
Immutability támogatás	S3 Object Lock kompatibilis	append-only mód SSH-n	S3 Object Lock, retention policy

A gyakorlatban a választás nem funkcionalitás, hanem operatív terhelés szerint dől el. Ha egyszerű S3 backendet akarsz, statikus binárissal és scripting-barát CLI-vel, a restic nyer. Ha csak SSH-n keresztül mented offsite szerverre, és a legjobb tömörítést akarod, a Borg. Ha csapatnak dolgozol, és kellenek grafikus vizualizációk vagy per-forrás policy-k, a Kopia.

restic telepítés és első mentés lépésről lépésre

A restic legnagyobb erőssége, hogy egyetlen statikus Go bináris. Nincs függőség, nincs Python venv, nincs libssl-verzió mismatch. A hivatalos restic GitHub release oldal minden platformra közli az SHA256 checksumot, én mindig ott indulok új telepítésnél.

# Debian/Ubuntu 2026
sudo apt install restic

# Vagy közvetlenül a GitHub release-ből (mindig ellenőrizd a checksumot)
RESTIC_VERSION="0.17.3"
curl -LO "https://github.com/restic/restic/releases/download/v${RESTIC_VERSION}/restic_${RESTIC_VERSION}_linux_amd64.bz2"
curl -LO "https://github.com/restic/restic/releases/download/v${RESTIC_VERSION}/SHA256SUMS"
sha256sum -c --ignore-missing SHA256SUMS
bunzip2 restic_${RESTIC_VERSION}_linux_amd64.bz2
sudo install -m 755 restic_${RESTIC_VERSION}_linux_amd64 /usr/local/bin/restic
restic version

A repó jelszót soha ne tárold plaintext fájlban, amit a root vagy bármely szolgáltatás olvashat. Kicsi telepítésnél az age-titkosított jelszófájl és a systemd credential mechanizmus párosa a legtisztább megoldás, amit ma ismerek:

# Age kulcspár generálása (host-specifikus, offline tartsd a private key backupját)
age-keygen -o /etc/backup/age.key
chmod 600 /etc/backup/age.key

# Repo jelszó generálás és titkosítás age-dzsel
openssl rand -base64 48 | age -r "$(age-keygen -y /etc/backup/age.key)" > /etc/backup/restic.pass.age

# Környezeti változók a mentéshez
export RESTIC_REPOSITORY="s3:s3.eu-central-1.amazonaws.com/mycompany-backup-prod"
export RESTIC_PASSWORD_COMMAND="age -d -i /etc/backup/age.key /etc/backup/restic.pass.age"
export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."

# Repo inicializálás
restic init

# Első mentés, az /etc, /home, /var/lib/postgresql kizárva a cache-eket
restic backup /etc /home /var/lib/postgresql \
    --exclude-caches \
    --exclude='*.tmp' \
    --tag "hostname=$(hostname)" \
    --tag "profile=daily"

Ez a workflow már a legtöbb kis-közepes környezetben megfelelő. Nagyobb léptéknél érdemes az IAM policy-t szűkíteni: a mentési kliens csak s3:PutObject, s3:GetObject és s3:ListBucket jogot kaphat, törlést nem. A régi snapshotok tisztítását külön, priviligált „prune" folyamat végzi másik gépről. Ez a klasszikus separation of duties alapelv backupra alkalmazva, és pontosan az, ami az elmúlt években több ügyfelemnél megmentette a bőrt.

BorgBackup workflow: repóinicializálás, append-only mód

A Borg 2016 óta a Linux world de facto szerver-mentési eszköze. 2026-ban a 1.4-es stabil ág mellett a Borg 2.0 alpha már használható, és bevezeti a ChaCha20-Poly1305 titkosítást, egy tisztább repó formátumot és egy modernebb kulcsmenedzsmentet. Új telepítésnél most is a 1.4-et javaslom éles környezetbe, a 2.0-t pedig lab-ben tesztelni. (Beleszaladtam már 2.0 alpha bugba egy migráció közben, azóta óvatosabb vagyok.)

# Telepítés
sudo apt install borgbackup

# Repó inicializálása SSH-n keresztül, append-only módban
export BORG_REPO="ssh://[email protected]:2222/./repos/webserver01"
export BORG_PASSPHRASE_COMMAND="age -d -i /etc/backup/age.key /etc/backup/borg.pass.age"

borg init --encryption=repokey-blake2 --append-only

# Napi mentés, zstd 9-es tömörítéssel, kizárásokkal
borg create --stats --progress \
    --compression zstd,9 \
    --exclude-caches \
    --exclude '/var/cache' \
    --exclude '/var/tmp' \
    --exclude '/tmp' \
    --exclude 'pp:/var/lib/mysql' \
    "::{hostname}-{now:%Y-%m-%dT%H:%M}" \
    /etc /home /root /srv /var

A Borg legfontosabb szerver-oldali beállítása az append-only restriction az SSH kulcsban. Ez az, ami a repót zsarolóprogram-ellenállóvá teszi: a mentési kliens ír, de nem tud törölni. Egy elkülönített admin gép SSH kulcsa a jogosult a régi archívumok pruningjára.

# /home/borg/.ssh/authorized_keys a backup szerveren
command="borg serve --append-only --restrict-to-path /home/borg/repos",restrict ssh-ed25519 AAAA... webserver01-backup
command="borg serve --restrict-to-path /home/borg/repos",restrict ssh-ed25519 AAAA... prune-admin

Ez ugyanaz a mintázat, amit a systemd szolgáltatások keményítése és sandboxing cikkben is használunk: a legkisebb jogosultság elve („least privilege") minden felületre. A support account nem lehet ugyanaz, mint az operátor account.

Kopia policy-k és a webes felület

A Kopia a legfiatalabb a három közül (2019-es kezdet, 2026-ban a 0.18-as verzió), és architekturálisan a legmodernebb megközelítést hozza. Minden objektum tartalomcímezhető (content-addressable storage, CAS), a titkosítás AES-256-GCM-HMAC-SHA256, és a policy-k hierarchikusan öröklődnek: globális, per-user, per-source. Nincs szükség külön ütemezőre, a Kopia repository szerver saját maga futtatja a snapshotokat.

# Kopia telepítés (Debian/Ubuntu repo)
curl -s https://kopia.io/signing-key | sudo gpg --dearmor -o /etc/apt/keyrings/kopia.gpg
echo "deb [signed-by=/etc/apt/keyrings/kopia.gpg] https://packages.kopia.io/apt/ stable main" | \
    sudo tee /etc/apt/sources.list.d/kopia.list
sudo apt update && sudo apt install kopia

# Repó létrehozás S3-on
kopia repository create s3 \
    --bucket=mycompany-backup-prod \
    --endpoint=s3.eu-central-1.amazonaws.com \
    --access-key="$AWS_ACCESS_KEY_ID" \
    --secret-access-key="$AWS_SECRET_ACCESS_KEY" \
    --password-file=/etc/backup/kopia.pass

# Snapshot indítás
kopia snapshot create /etc /home /srv

# Policy beállítás, retention és tömörítés
kopia policy set --global \
    --keep-latest=10 --keep-hourly=24 --keep-daily=30 \
    --keep-weekly=8 --keep-monthly=12 --keep-annual=3 \
    --compression=zstd

A webes UI (kopia server start --address=127.0.0.1:51515) különösen hasznos vegyes csapatoknál, ahol nem minden operátor CLI-vel dolgozik. Fontos: a webes UI mögé mindig tegyél reverse proxyt mTLS-sel vagy legalább alap authhal. Az alapértelmezett HTTP port lokálhoston hallgat, viszont kliens/szerver módban egy fordított proxy nélküli deployment súlyos hiba. A hivatalos Kopia CLI referencia minden parancsot részletesen dokumentál, érdemes rákeresni finomhangolás előtt.

Kulcsmenedzsment: age, KMS és Vault Transit

A backup-titkok kezelése az, ahol a legtöbb csapat elhasal. Négy szintet szoktam megkülönböztetni, komplexitás szerint növekvő sorrendben:

1. Fájl a diszken, szigorú jogosultsággal: 1–2 szerveres homelabnál OK, éles produkcióban nem.
2. age-titkosított jelszófájl: a jelszó nyugalmi állapotban titkosított, a mentési szolgáltatás induláskor kicsomagolja. Az age privát kulcs ekkor is diszken van, de legalább a passphrase nem plaintext.
3. Cloud KMS (AWS KMS, GCP KMS, Azure Key Vault): a passphrase egy KMS-encrypted blob, a szerver IAM roleja tudja dekódolni. Auditálható, IAM-mel szabályozott. Ez a legtöbb Kubernetes/EKS környezet standardja.
4. HashiCorp Vault Transit engine: Vault-alapú környezetekben a legelegánsabb. A Vault soha nem adja ki a kulcsot, csak dekódol. A backup client egy AppRole tokennel autentikál, és a Transit endpoint visszaadja a plaintext passphrase-t stdoutra egy egyszeri hívásban.

A Vault Transit hivatalos dokumentáció részletesen leírja a rotáció és a re-wrap folyamatokat, amit érdemes végigolvasni, mielőtt éles környezetbe raknád.

# Vault Transit példa: passphrase decryption
VAULT_TOKEN=$(vault write -field=token auth/approle/login \
    role_id="$ROLE_ID" secret_id="$SECRET_ID")

RESTIC_PASSWORD=$(vault write -field=plaintext \
    transit/decrypt/backup-key \
    ciphertext="$(cat /etc/backup/restic.pass.vault)" | base64 -d)

export RESTIC_PASSWORD
restic backup /srv
unset RESTIC_PASSWORD  # ne maradjon a shell environmentben

Zsarolóprogram elleni védelem: immutable backendek

Amikor egy 2025-ös incidensben egy ügyfélnél mind a produkciós adat, mind a napi backup egyszerre titkosításra került, a különbség a helyreállítás és a csőd között az volt, hogy egy külön AWS accountban lévő S3 Object Lock-os másolat érintetlen maradt. Az immutability nem opció 2026-ban, hanem kötelező kontroll. Pont.

A gyakorlatban három megközelítés működik:

• S3 Object Lock (compliance vagy governance mode): a legjobban dokumentált, Cloudflare R2, MinIO, Wasabi is támogatja. A restic 0.17+ és a Kopia 0.18+ natívan együttműködnek vele; a Borg csak rclone-on keresztül.
• Append-only Borg repó SSH restrictionnel: natív Borg megoldás, viszont a támadó, aki root a backup szerveren, továbbra is módosíthatja a repót. A backup szerver keményítése ezért ugyanolyan kritikus, mint az éles.
• ZFS/Btrfs snapshotok read-only mount pointon: filesystem-szinten. A legjobb performance, viszont csak akkor immutable, ha a snapshotot egy admin account készíti és a backup account nem tudja törölni.

Mindhárom megközelítés a „pull-based" mentési modellhez kapcsolódik: a backup szerver húzza az adatot az éles rendszerekről (ellentétben a hagyományos „push-based" iránnyal, ahol az éles rendszer küld). Pull modellben a kompromittált éles rendszer nem tud egyáltalán hozzáférni a backup tárhoz, mert nincs API kulcs a diszken. A backup szerver azonosítja magát az éles rendszer felé, nem fordítva.

Automatizálás systemd timerrel és riasztásokkal

Cron ma már nem elég. Egy 2026-os backup automatizálás minimum három komponensből áll: systemd timer (idővezérlés, resource limitálás), OnFailure hook (riasztás), és healthcheck ping (dead man's switch). Az utolsó a legfontosabb: nem az érdekel, ha a mentés hibázott, hanem az, ha nem futott le egyáltalán.

# /etc/systemd/system/restic-backup.service
[Unit]
Description=Restic napi backup
Wants=network-online.target
After=network-online.target
OnFailure=backup-failed@%n.service

[Service]
Type=oneshot
EnvironmentFile=/etc/backup/restic.env
ExecStart=/usr/local/bin/restic backup /etc /home /srv --exclude-caches --tag daily
ExecStartPost=/usr/bin/curl -fsS -m 10 --retry 5 https://hc-ping.com/YOUR-UUID
Nice=19
IOSchedulingClass=idle
CPUQuota=50%
MemoryMax=2G
ProtectSystem=strict
ProtectHome=read-only
ReadWritePaths=/var/cache/restic

# /etc/systemd/system/restic-backup.timer
[Unit]
Description=Restic napi backup ütemezés

[Timer]
OnCalendar=*-*-* 03:15:00
RandomizedDelaySec=30min
Persistent=true

[Install]
WantedBy=timers.target

A ProtectSystem=strict és ProtectHome=read-only a systemd sandbox. A mentési szolgáltatás nem tud véletlenül vagy szándékosan (kompromittálás esetén) írni a rendszerfájlokba. Ez ugyanaz az elv, mint amit a SSH megerősítés 2026-ban útmutatóban is alkalmazunk minden internetre néző szolgáltatásnál.

Restore-tesztelés és katasztrófa-helyreállítási gyakorlat

„Nincs backupod, amíg nem teszteltél restore-t." Ez a mondat annyira klisé, hogy már fáj, mégis nálunk a szenior architektek 40%-a nem tud spontán megnevezni egy dátumot, amikor utoljára ténylegesen visszaállított éles adatot mentésből. Egy jó DR (Disaster Recovery) program legalább háromféle tesztet futtat:

1. File-level restore (heti): véletlenszerűen kiválasztott fájl visszaállítása egy ideiglenes mappába, checksumolás az eredetivel.
2. Application-level restore (havi): egy komplett adatbázis (Postgres, MySQL) visszaállítása egy izolált teszt hosztra, smoke test futtatás.
3. Bare-metal / VM restore (negyedéves): teljes rendszerkép visszaállítása üres hardverre vagy új VM-re, hálózati konfigurációval együtt.

# restic, automatizált file-level restore-teszt
LATEST_SNAPSHOT=$(restic snapshots --json | jq -r '.[-1].id')
TEMP_DIR=$(mktemp -d)
restic restore "$LATEST_SNAPSHOT" --target "$TEMP_DIR" \
    --include "/etc/hostname"

if diff -q "$TEMP_DIR/etc/hostname" /etc/hostname; then
    curl -fsS "https://hc-ping.com/RESTORE-TEST-UUID"
    rm -rf "$TEMP_DIR"
else
    logger -p daemon.err "Restore teszt hiba a $LATEST_SNAPSHOT snapshoton"
    exit 1
fi

A Borg és a Kopia is támogatja a repó integritás-ellenőrzését (borg check, kopia repository verify), amit havonta érdemes futtatni. Ez felfedi a bit-rot problémákat és a hiányzó chunk-okat, mielőtt szükséged lenne rájuk. A tapasztalatom szerint az S3-on tárolt repóknál évi 0,001% alatti a chunk-veszteség, viszont az on-premise NAS-oknál rendszeresen látni HDD-hiba miatti sérüléseket. (Egy 4 éves WD Red rakás tavaly ősszel egy hét alatt kilőtte a redundanciámat, azóta minden nyűg a monitoron a legfontosabb barátom.)

Melyiket válasszam 2026-ban?

Nincs univerzálisan jó válasz, viszont van néhány használati eset, ahol egyértelmű a győztes:

• Egyszemélyes homelab / kevesebb mint 20 szerver, S3-alapú offsite: restic. Egyetlen bináris, minimális ceremonia.
• Klasszikus enterprise, SSH-alapú offsite backup szerver: BorgBackup, append-only móddal. A legjobb tömörítés, a legrégebbi kód, a legkevesebb meglepetés.
• Modern DevOps csapat, Kubernetes, vegyes felhő: Kopia. Beépített scheduler, per-source policy-k, webes UI a non-CLI teamtagoknak.
• Adatbázis-mentés PITR-rel: egyik sem. Használj natív eszközt (pgBackRest, MariaDB Backup, MongoDB Backup) és utána tükrözd az egészet restic/Kopia-val offsite-ba.

Bármelyiket is választod, a döntés csak 20% az egyenletből. A többi 80%: kulcsmenedzsment, immutability, tesztelt restore, és a monitoring, amelyik szól, ha a mentés nem futott. Ha ezekből bármelyik hiányzik, a titkosítási algoritmus finomságai nem számítanak. A backup rendszered pontosan annyira jó, mint a leggyengébb láncszeme, és az szinte soha nem a kripto.

Gyakran Ismételt Kérdések

Mi a különbség a restic és a Borg között?

A restic natívan támogat objektum-tárolókat (S3, B2, Azure, GCS), egyetlen statikus Go bináris és több párhuzamos kliens írhatja ugyanazt a repót. A Borg SSH-központú, Python-alapú, csak egy író klienst enged, viszont tisztább „append-only" módot biztosít szerver oldalon, és a zstd 22-es tömörítés általában 5–10%-kal jobb aránnyal dolgozik. Éles környezetben nagyon gyakori, hogy Borg megy offsite SSH-ra, restic pedig S3-ra: kettő, egymástól független útvonalon.

Hogyan titkosítsam a Linux biztonsági mentéseimet age-dzsel?

Az age (age-encryption.org) X25519-alapú, header-tömör, modern kriptográfiai eszköz, GPG-hez képest lényegesen egyszerűbb és kevésbé hibázós. Használhatod közvetlenül a tar.gz fájlok titkosítására (tar -czf - /srv | age -r $(cat pubkey) > backup.tar.gz.age), de a gyakorlatban okosabb megközelítés az age-t a mentőeszköz jelszavának titkosítására használni, mert így megmarad a restic/Borg deduplikációja és inkrementális működése.

Melyik a legjobb backup program Linuxra 2026-ban?

Nincs univerzális válasz. Ha egy dologra kellene fogadnom: a restic 0.17+ ma a legjobb kompromisszum egyszerű setup, natív S3 támogatás, aktív fejlesztés és többplatformos működés között. Enterprise SSH-alapú offsite backupra viszont a BorgBackup 1.4 érettebb. Kis vagy közepes DevOps csapatnak vegyes felhővel a Kopia beépített scheduler-je és UI-ja gyakran döntő.

Használjak age-t vagy GPG-t a mentések titkosítására?

Az age. A GPG a webes bizalmi láncára és a hosszú távú aláírásra optimalizált, ami backup jelszó-titkosításnál felesleges komplexitás és nagy támadási felület (a GPG CVE-történet lényegesen hosszabb). Az age egyszerű, egy célra tervezett, modern kripto (X25519 + ChaCha20-Poly1305), és a syntaxa is barátságosabb scripting szempontból.

Hogyan védekezhetek zsarolóprogramok ellen backup segítségével?

Három egymást erősítő kontroll kell: (1) immutable tároló (S3 Object Lock vagy Borg append-only mód), (2) „pull-based" modell, ahol a backup szerver csatlakozik az éles rendszerekhez és nem fordítva, (3) offsite másolat külön hitelesítési tartományban (más AWS account, más SSH kulcs, más passphrase). Ezek együtt biztosítják, hogy a produkciós rendszer teljes kompromittálása ne járjon együtt a backup megsemmisülésével.

Mi a 3-2-1-1-0 backup szabály?

A klasszikus 3-2-1 szabály (3 másolat, 2 különböző médium, 1 offsite) kiegészítése két új követelménnyel a zsarolóprogram-korszakban: 1 immutable vagy air-gapped másolat (amit nem lehet távolról megsemmisíteni), és 0 hiba az utolsó ellenőrzött restore-tesztben. Ez utolsó a legfontosabb: a hét mentésből ha csak öt állítható vissza, akkor gyakorlatilag ötöd van, nem hét.