TITLE=Mentés ROUTE=/infrastructure/backup LOCALE=hu MODIFIED=1792352739 URL=https://wiki.teletypegames.org/hu/infrastructure/backup q│ Két lánc: egy Makefile-alapú mentés az adatbázis-dumpokhoz és a Gitea-repók q│ tükréhez, utána egy rsync-alapú teljes állomány-tükör egy távoli NAS-ra. q│ 2026-10-16 óta ez a rend. Előtte a második lánc restic volt, ezt kivezettük: q│ a mentés egyszerűbb lett, cserébe nincs verziózás. 1Napi menetrend 1══════════════ t┌───────┬─────────────────────────────────┬──────────────────────────────────┐ t│h Idő t│h Mi t│h Eszköz t│ t├───────┼─────────────────────────────────┼──────────────────────────────────┤ t│0 04:00 t│0 Redmine (MariaDB), katalógus és t│0 cmake backup0 (cron, t│ t│0 t│0 Gitea (MySQL) dump → minden t│0 cinfra/backup-scripts0) t│ t│0 t│0 Gitea-repó tükrözése → 7 napnál t│0 t│ t│0 t│0 régebbi dumpok törlése t│0 t│ t├───────┼─────────────────────────────────┼──────────────────────────────────┤ t│0 05:00 t│0 Matomo, ResourceSpace és Uptime t│0 cvps-backup-sync0 (systemd timer, t│ t│0 t│0 Kuma dump → Woodpecker és t│0 cinfra/host-config0) t│ t│0 t│0 Grafana SQLite-másolat → t│0 t│ t│0 t│0 csomaglista → teljes t│0 t│ t│0 t│0 állomány-tükör a NAS-ra t│0 t│ t└───────┴─────────────────────────────────┴──────────────────────────────────┘ A tükör azért fut egy órával később, hogy a friss dumpokat és repótükröket is vigye. A 04:00-s lánc nem szinkronizál külön, a NAS-ra minden a 05:00-s tükörrel megy át. 11. lánc: dumpok és repótükrök (Makefile) 1════════════════════════════════════════ Környezeti változók a cMakefile0-ban: t┌───────────────────────────┬────────────────────────────────────────────────┐ t│h Változó t│h Jelentés t│ t├───────────────────────────┼────────────────────────────────────────────────┤ t│0 cBACKUP_BASE0 t│0 Minden mentés gyökere (alapérték c/srv/backup0) t│ t├───────────────────────────┼────────────────────────────────────────────────┤ t│0 cBACKUP_KEEP_DAYS0 t│0 Az adatbázisdumpok megőrzési ideje (alapérték t│ t│0 t│0 c70) t│ t├───────────────────────────┼────────────────────────────────────────────────┤ t│0 cDATABASE_BACKUP_BASE0 t│0 Ide kerülnek az SQL-dumpok t│ t├───────────────────────────┼────────────────────────────────────────────────┤ t│0 cREPOSITORY_BACKUP_BASE0 t│0 Ide kerülnek a tükrözött repók t│ t├───────────────────────────┼────────────────────────────────────────────────┤ t│0 cGITEA_SERVER0, cGITEA_TOKEN0 t│0 Gitea API a repók listázásához; a token egy t│ t│0 t│0 c.envrc0 fájlból jön, amit a Makefile maga olvas t│ t│0 t│0 be (c-include0), így cron alatt is működik t│ t└───────────────────────────┴────────────────────────────────────────────────┘ 2Célok 2───── p make backup # db_redmine -> db_catalog -> db_gitea » p -> repos -> db_cleanup p make db_redmine db_catalog db_gitea # csak az adatbázisok p make repos # a git-tükrök frissítése p make db_cleanup # a lejárt dumpok törlése 2Adatbázismentések 2───────────────── Minden dump a szolgáltatás konténerén belül fut. A dumpok időbélyeggel a konténer c/db_backup0 könyvtárába kerülnek, amely a hoszt cDATABASE_BACKUP_BASE könyvtárára van csatolva. t┌────────────────────────┬─────────────────────────┬─────────────────────────┐ t│h Szolgáltatás t│h Hogyan t│h Megjegyzés t│ t├────────────────────────┼─────────────────────────┼─────────────────────────┤ t│0 Redmine (MariaDB) t│0 cdatabase/mariadb_0 t│0 cMARIADB_USER0, t│ t│0 t│0 cbackup.sh0 t│0 cMARIADB_PASSWORD0, t│ t│0 t│0 t│0 cMARIADB_DATABASE0 a t│ t│0 t│0 t│0 konténerben t│ t├────────────────────────┼─────────────────────────┼─────────────────────────┤ t│0 Katalógus (MySQL, t│0 cdatabase/mysql_backup.0 t│0 cMYSQL_ROOT_PASSWORD0, t│ t│0 csoftwares0) t│0 csh0 t│0 cMYSQL_DATABASE0 a t│ t│0 t│0 t│0 konténerben t│ t├────────────────────────┼─────────────────────────┼─────────────────────────┤ t│0 Gitea (MySQL, cgitea0) t│0 cdb_gitea0 a t│0 b2026-10-16 óta.0 Előtte t│ t│0 t│0 Makefile-ban: cmysqldump0 t│0 a Gitea adatbázisa t│ t│0 t│0 c--single-transaction0 t│0 (felhasználók, t│ t│0 t│0 c--routines --triggers0 t│0 jogosultságok, issue-k, t│ t│0 t│0 t│0 PR-ek, t│ t│0 t│0 t│0 OAuth-alkalmazások, t│ t│0 t│0 t│0 registry-metaadatok) t│ t│0 t│0 t│0 sehol nem volt mentve. t│ t├────────────────────────┼─────────────────────────┼─────────────────────────┤ t│0 Wiki (PostgreSQL) t│0 cdatabase/pg_backup.sh0 t│0 bKivezetve 2026-09-110 – t│ t│0 t│0 t│0 a Wiki.js adatbázisa t│ t│0 t│0 t│0 megszűnt, a szkript t│ t│0 t│0 t│0 csak örökség. t│ t└────────────────────────┴─────────────────────────┴─────────────────────────┘ 2Repómentések 2──────────── A cmake repos0 a Gitea API-ból kilistázza az összes privát és publikus repót, majd repónként: cfetch --all --prune0 + cpull0, ha helyben már megvan, cgit clone0, ha még nincs. 2Takarítás 2───────── A cmake db_cleanup0 adatbázis-előtag szerint csoportosítja a dumpokat, és törli a cBACKUP_KEEP_DAYS0-nél régebbi fájlokat. Egy biztonsági ellenőrzés adatbázisonként legalább egy mentést mindig meghagy, akkor is, ha az régebbi a megőrzési ablaknál. 12. lánc: állomány-tükör (vps-backup-sync) 1═════════════════════════════════════════ A c/usr/local/sbin/vps-backup-sync0 szkript (forrása az cinfra/host-config repóban) rootként fut a cvps-backup-sync.timer0 indítására. bDumpok a szkript elején:0 Matomo (cmariadb-dump0), ResourceSpace (c--all-databases0), Uptime Kuma (csqlite3 .backup0). A futó Woodpecker és Grafana SQLite-adatbázisról csqlite3 .backup0 készít konzisztens másolatot a fájl mellé (cwoodpecker-backup.sqlite0, cgrafana-backup.db0). A telepített csomagok listája a c/srv/backup/system/0 alá kerül (cdpkg --get-selections0, capt-mark showmanual0). bMit tükröz:0 a c/srv/stacks0, c/srv/stacks_disabled0, c/srv/backup0, c/srv/host-config0, c/srv/presentation0, c/srv/dockge0 könyvtárat, a hoszt c/etc0, c/root0, c/home0, c/usr/local/sbin0, c/var/spool/cron0 és c/var/www0 könyvtárát, valamint a ResourceSpace fájltár és a Matomo Docker-volume-ját. Összesen kb. 27 GB. bMit nem:0 az élő adatbázis-könyvtárakat (helyettük a dumpok, mert egy futó DB fájljai nem konzisztensek), cnode_modules0, ctmp0, clog0, Gitea keresőindexek, cache-ek. bHogyan:0 crsync -aH --numeric-ids --relative --delete0 a NAS egy 700-as jogosultságú könyvtárába, abszolút útvonalakkal. A NAS-on egy nem-root felhasználó fogad, ezért a tulajdonos, a jogosultság és az eszközadat xattr-ban tárolódik (c-M--fake-super0). Visszafelé is ezzel a kapcsolóval kell másolni, különben minden fájl a NAS-felhasználóé lesz. bVerziózás nincs.0 A NAS-on mindig a legutóbbi állapot van. Ha valami törlődik vagy elromlik a szerveren, a következő éjjel a NAS-on is törlődik vagy elromlik. Az adatbázisoknál a 7 napos dump-rotáció ad némi visszamenőleges védelmet. 1Távoli tükör 1════════════ A cél egy külső Synology NAS (DS212j, DSM 6.2, ext4). Csak cssh-rsa0 kulcsot fogad, nincs SFTP-alrendszere, és Btrfs-snapshotot sem tud, ezért NAS-oldali verziózás csak hardlinkes másolatokkal volna megoldható. bNyitott kérdés:0 a tükör a szerverről írható, tehát egy kompromittált hoszt a mentést is törölhetné. A titkok (c/root0, c/etc/shadow0, c.env0 fájlok, tanúsítványkulcsok) titkosítatlanul vannak a NAS-on. 1Visszaállítás új szerverre 1══════════════════════════ A pontos parancsok az cinfra/host-config0 README „Mentés és visszaállítás” részében vannak. Röviden: 1. A teljes állomány visszamásolása rootként, c-M--fake-super0 kapcsolóval, egy ideiglenes könyvtárba. 2. Csomagok telepítése a c/srv/backup/system/apt-manual.txt0 alapján, majd az c/etc0 válogatva a helyére, és a c/srv0, c/home0, c/root0, c/var/www0, c/var/spool/cron0, c/usr/local/sbin0 vissza. 3. csudo /srv/host-config/install.sh0 a hoszt saját fájljaihoz. 4. A stackek indítása üres adatbázissal, majd a legfrissebb dumpok betöltése (credmine_production0, csoftwares0, cgitea0, cmatomo0, cresourcespace0). 5. SQLite: a c*-backup.*0 másolatok a helyükre, leállított stack mellett. 6. Docker-volume-ok: a ResourceSpace fájltár és a Matomo volume tartalma vissza. 1Fájlszerkezet 1═════════════ A mentőrepó (cinfra/backup-scripts0): p . p ├── Makefile # az 1. lánc minden feladata p └── database/ p ├── mariadb_backup.sh p ├── mysql_backup.sh p └── pg_backup.sh # örökség, már nem fut A 2. lánc az cinfra/host-config0 repóban van: cfiles/usr/local/sbin/vps-backup-sync0, cfiles/etc/systemd/system/vps-backup-sync.{service,timer}0, cfiles/etc/logrotate.d/vps-backup-sync0. Telepítés: csudo ./install.sh0. A szerveren (cBACKUP_BASE=/srv/backup0): p /srv/backup/ p ├── database/ # dumpok, 7 nap p │ ├── gitea-2026-10-16-02-00.sql p │ ├── redmine_production-2026-10-16-02-00.sql p │ ├── softwares-2026-10-16-02-00.sql p │ ├── matomo-2026-10-16-05-03.sql p │ └── resourcespace-2026-10-16-05-03.sql p ├── repositories/ # az összes Gitea-repó tükre p ├── system/ # csomaglista (dpkg, apt-mark) p └── archive-2026-10-15/ # a takarításkor törölt volume-ok tar.gz a» p rchívjai 1Ellenőrzés 1══════════ • A tükör naplója a hoszton (c/var/log/vps-backup-sync.log0): minden lépés cOK vagy cHIBA0 sorral zárul. • Hibátlan futás után a szkript Uptime Kuma pusht küld; ha 26 óráig nem jön jelzés, riasztás megy a Discord Alert csatornára. • Grafana: a bVPS: Backup0 dashboard mutatja az utolsó futás állapotát, a dumpok korát és méretét, a tükör méretét és a mentés naplósorait. A metrikákat a szkript a node-exporter textfile collectorának írja (c/srv/stacks/observability/textfile/vps_backup.prom0), a naplósorok a Lokiban vannak (c{service_name="cron-jobs", program="vps-backup-sync"}0). A Grafana: https://grafana.teletypegames.org (belépés Gitea-fiókkal). • Ha egy adatbázis legfrissebb dumpja elavul, a Grafana bDatabase dump stale riasztása szól Discordra. • A dumpkönyvtárban minden adatbázisnak minden napra kell lennie friss fájljának; ha egy előtag eltűnik vagy megáll, a lánc elakadt. 1Repók 1═════ • https://git.teletypegames.org/infra/backup-scripts • https://git.teletypegames.org/infra/host-config