Backup megoldások, ötleteljünk

Segédprogramok

Viszonylag nagy iskola, több telephely, sok windowsos gép. Szükségünk lenne backup megoldásra. Természetesen csak ingyenes megoldásokban gondolkozhatunk.

Ami adott:

- 1 db hp szerver rajta Proxmox VE. A rendszer egy Raid10 tömbben két diszken, az adatoknak 2.7T tárhely van RAID5 tömbben.  Sok szolgáltatás, fájlszerver, dns szerver, media szerver, stb. A fájlszerver feladatokat egy VM-ban futó  OpenMediaVault látja el. ZFS nincs, ext4 van.

- 1 db ugyanilyen hp szerver, rajta semmi. A kérdésem,hogy mi legyen?

Adja magát ugye a friss ropogós Proxmox Backup Server. Ezzel tudnám a virtuális gépeket, és proxmox szervert backupolni. A probléma a windowsos gépek backupja lenne. A proxmox ugye nem alkalmas erre, ahogyan olvastam. Itt szeretnék segítséget kérni, mit is használjak. Jó lenne, ha lenne GUI, ahol adminisztrálhatom a backupokat, jó lenne GUI a windows kliensre is, ahol beállíthatom a mentést is. Nem ismerem a PBS-t annyira, de gondolom van lehetőség akár virtuális gépre, akár hostra telepíteni valamilyen programot. 

Alapvetően inkrementális mentésekre lenne szükségem szerintem, de várom az okosabbak tanácsait, hogy mit és merre lenne érdemes csinálni.

Köszönöm!

  • 2288 megtekintés

( gemnon v | 2025. 08. 21., cs – 12:25 )

Urbackup ?

Nálunk ez menti a windowsos gépeket, a szervernek van webgui-ja , de a windows klienseken is be lehet állítani mit mentsen. 

Ez nagyon szimpatikus. Még db mentést is tud és teljesen ingyenes. Érdemes a hostra telepíteni a servert, vagy inkább önálló VM-be pakoljam? Jó lesz a Proxmox Backup Server alapnak?

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Nem teljesen ingyenes, a CBT funkció pénzbe kerül. Barátkoztam urbackup-al is, jelenleg Veeam Agent-et használok azokon a gépeken amiket érdemes menteni. Teljes gépet mentek, nem csak adatot, mert ezekre nem 10 perc visszavarázsolni az alkalmazásokat.

( gyuri23 | 2025. 08. 21., cs – 12:46 )

A sok windowsos gépet, hogyan kell érteni? Szerverek vagy kliensek, esetleg mindkettő? Van AD? Ha jól értem ezek nem VM-ek. 

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Jogos a kérdés. A sok windowsos gép mind asztali gép, fájlszinten kell mentés és nincs AD.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Hááát...

  • HA  lehet linuxos szerver
  • HA eléri az összes gépet
  • HA tényleg csak fájlszintű mentés kell
  • HA ... passz...

Akkor a https://backuppc.github.io/backuppc/ is jó lehet. Használom olyan tíz éve, de csak linuxokhoz, egyszer beállítod, és megy (ha meg nem, az tipikusan a kliens miatt van, pl. ki van kapcsolva).

Akkor mindenképp valamilyen kliens-szerver megoldás kell, mert AD nélkül nem tudsz egyszerűen futtatni semmit sem. A telepítés vélhetőleg így is "kézimunka" lesz.

Erre több ingyenes megoldás van, de én is az UrBackup-ra szavazok, esetleg Bareos, vagy Bacula.

Ha éjszak nincs munka én a HP-ra mindenképp egy PBS-t tennék (ZFS-el a deduplikáció miatt), az UrBackup meg egy VM, ami NFS vagy esetleg iSCSI módon PBS szerverre ment. A PBS egy Debian, bármit rá lehet tenni, persze ami nem vágja szét a PBS-t, viszont az UrBackup-t nem tenném rá.

Én asszem így csinálnám. 

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Akkor mindenképp valamilyen kliens-szerver megoldás kell, mert AD nélkül nem tudsz egyszerűen futtatni semmit sem. A telepítés vélhetőleg így is "kézimunka" lesz.

Az nem is nagy baj, mert annyira sok gépről nem is kell a mentés... Sokat gondolkodom, hogy érdemes lenne-e AD szolgáltatást telepíteni, de alapvetően azt egy windows serveres dolognak tartom, amihez nem konyítok. Ha pedig feltennék mondjuk egy Zentyal-t félek nem boldogulnék azzal sem. Szerintem nem elég hozzá a tudásom...

Ha éjszak nincs munka én a HP-ra mindenképp egy PBS-t tennék (ZFS-el a deduplikáció miatt), az UrBackup meg egy VM, ami NFS vagy esetleg iSCSI módon PBS szerverre ment. A PBS egy Debian, bármit rá lehet tenni, persze ami nem vágja szét a PBS-t, viszont az UrBackup-t nem tenném rá.

Köszönöm ez így kivitelezhetőnek tűnik, észszerű és viszonylag kevés munka. Érdekes kérdés, hogy NFS vagy iSCSI mód legyen-e. Szerintem NFS lesz.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Én is az NFS-t választanám, két okból is. Ez egyik, hogy akkor ott is megy a dedup, a másik, meg ha valamiért esetleg bele kell piszkálni a fájlokba, az iSCSI csatolgatás macerásabb.

Nem tudom milyen HP, de ha ZFS-t akarsz tedd HBA-módba a RAID kontrollert. Ha jól rémlik, a P440-től simán bekapcsolod, meg mintha a P420-ra valami firmware vacakolás kellett volna hozzá.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Akkor Bacula Community (szerver és kliensek) + Bacularis (web admin és monitozás)!

Fájl szintű mentésre, ingyenes, központilag menedzselt módon nem tudok jobbat.

Viszont azt el kell mondjam, hogy nagyon kellene az AD jogosultság kezelésre, és nagyon nem kellene a desktop gépeken semmit tarani, aminek értéke van. Ez a kettő külön külön értendő.
Sok iskolai rendszert üzemeltetünk, és az a tapasztalat, hogy az AD hiányából mindig illetéktelen hozzáférés és általános káosz keletkezik. A desktop gépen tartott adat pedig semmi módon nincs biztonságban és nagyon nehezen menedzselhető, hogy tényleg mentve legyen ami fontos és ne legyen, ami nem kell, ráadásul bazi sok tárhelyet igényel.

Iskolaként tisztaszoftverben kapsz Windows Server 2022-t  "ingyen", még csak Linux alapú megoldást sem kell használnod az AD-re, és a meglévő Proxmox-ra nagyon gyorsan fel lehet tenni.

Szívesen osztok meg tapasztalatokat mára nagyjából beérett iskolai felállásokról, ha érdekel, és rámírsz pm-ben.

P.s.: A maradék üres HP szerverre egy (másik) Proxmox VE, abba mehet egy CT-be a PBS és egy másik CT-be a Bacula (vagy más mentő szoftver), és a PVE hosztról lehet adni bind mount-tal ZFS tárhelyet mindkettőnek amennyi kell, és könnyen bővíthetően. ZFS dedup-ot nem erőltetném, ha nincs nagyon sok RAM abban a gépben, a PBS dedupol magától ZFS nélkül is, a másik fájlszintű megoldás meg vagy tudja vagy nem (Bacula tudja pl.).

Nem szoktam ennyire low cost megoldásokat összerakni, de ez tényleg jó.

Van ismerős suliban, ők annyira nem tárolnak semmit a klienseken, hogy amin tanulnak a srácok, naponta (vagy hétvégenként, nem emlékszem) újrahúzzák hálózatról, image-ből az összeset.

Ti is szoktatok ilyet csinálni?

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Hát, mi is az iskolai "igények" (lehetőségek) okán foglalkozunk ilyen olcsó megoldásokkal is... Attól, hogy nincs pénzük, még valami megbízható mentés nekik is kell. Céges ügyfeleknél szerencsére (bár ott sem minden esetben...) kövérebb a buxa, jobb a rendszer.

Igen, van olyan suli, ahol havi újrahúzás van image-ből (ez most szeretnénk több intézményben egységesíteni és sűríteni), van könyvtár, ahol deepfreeze fut és naponta visszaállítja a gépeket "alapállapotra" (olvasótermi publikus gépek), és van, ahol napi profil törlés van a tanulói gépeken (mert csak oda tudnak telepíteni, de oda telepítenek is...). Persze van olyan hely is, ahol csak akkor történik valami a géppel, ha baja lesz, egyébként gyűlik rajta a szemét.

Mi általában csak a szerver-router-hálózat résszel foglalkozunk sulikban, a desktopokkal jellemzően a helyi rendszergazda, mi meg besegítünk, ötletelünk, támogatjuk amennyire kell/lehet. Sajnos az iskolák java részének nincs pénze, ha véletlenül van is, akkor is csak a méregdrága DFÜ vagy DKÜ vagy mi rendszerben költheti el elképesztően túlárazott és versenymentes módon. Ráadásul a nem túl busás fizetéselk miatt sok intézmény egyáltalán nem is talál főállású rendszergazdát, így valamelyik infótanár foglalkozik a témakörrel ahogy ideje meg kedve kiadja. A helyzet szerintem eléggé lesujtó általános és középiskolai szinten.

Én nem gondolom hogy csak a drága lehet jó, sőt. Az, hogy a PBS és a másik választott szoftver VM legyen egy gépen és kapjanak helyi lemezt, eszembe se jutott, de jó megoldásnak gondolom és ha a mentések valahol máshol is meglesznek, meg a mentő VM-ek mentve/replikálva vannak a másik host gépre, egy mentő szerver hiba esetén az egész mentő rendszer egy pillanat alatt visszaállítható. 

Ráadásul ahogy a mesék szólnak, a menő tech cégeket a sok olcsó gép és saját megoldások tették naggyá :D

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Így van! Nem is a szoftveres részére értettem, hogy olcsó megoldások, mert szerintem a legjobbak függetlenül attól, hogy FOSS. Hanem arra, hogy újrahasznosított és/vagy nem server-grade hardverre valósítjuk meg, amit esetleg a kukából húzunk ki, mert Windows-ra már rég nem jó még suli szinten sem, de Linux alá még szuperszámítógép.

Mi használjuk offsite mentési megoldásra ezt a felállást. Minden ügyfél kap egy CT-t, benne az általa használt backup szoftverrel (jellemzően PBS, kopia vagy egy rsync cél), és bind mount-tal kapnak a host-ról tárhelyet, ami jól kvótázható (ZFS), jól bővíthető (úgy CT mint host szinten), tömörített, stb. Mivel unprivileged a konténer, uid/gid mappinggal szépen el vannak szeparálva a hosttól és egymástól egyaránt. Majdnem mindre titkosítottan kerül a mentési adat (ez ügyfél döntés, nekünk mind1).

Nagyjából mind wireguard-dal van összekötve a forrásával (CT szinten, nem a router kezeli ezeket), pl. a PBS-ek pull módban működnek, a forráson csak egy read only user-ük van, a VPN-en keresztül pedig nem elérhetőek a forrás felől, csak a válaszok jutnak vissza. Így aránylag jól védett a forrás oldali károkozókkal, támadásokkal szemben az offsite mentés.

Maga a hardver két egyforma "storage szerver", ZFS replikációval vannak szinkronban tartva. Ugye amikor az ügyfél összes helyi mentése elveszik valamiért, és jön az offsite példányért, nem mondhatjuk, hogy pont elrolmott az a szerver, mert nem lenne boldog...

Jól értem, a bind mount-ra mentett adatok is replikálva vannak? Egyáltalán ki lehetne hagyni a replikából?

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Ezt miért így csináljátok? Nem lenne egyszerűbb simán a ct lemezére tenni a mentést? 

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

a ct lemeze mashol/maskepp kezelodik. a host-rol bind mount flexibilisebb megoldas es a ct-tol fuggetlenul azt csinalsz vele, amit akarsz. fel is gyujthatod a ct-t, megmarad. akar tobb ct-nek is odaadhatod... stb.
hint: containers vs. persistent storage.

Ok, köszi.

Nem kötekszem, tényleg érdekel, hogy volt-e már gyakorlati példa arra, hogy ki kellett, vagy lehetett használni ezt az előnyét, vagy inkább csak "biztonsági" okból van?

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

tegykfelhogy:
upgrade-elned a CT-det
csinalsz rola egy mentest
mokuskalsz vele, nem jon ossze

nagyon nem mindegy, hogy az egesz sok teras mentesed [insert any data here] kell mentesbol visszaallitani, vagy csak azt a par megat, ami a CT rendszere.

ez csak egy a sok elonybol, lasd, amit irtam is fentebb, persisztens tar vs. kontener.

a mountpoint lehet barmi a hoston, akar egy koszos USB drive is, nem kell pve storage-t csinalni belole, stb. "csak egy mappa"

Én az update előtt mindig snapshoot-al indítok, az megoldja, ha félresikerül az update.

Hát az USB az oké, de az meg elég perverz :D

Én elég kevés esetben látom az előnyét, de persze biztos van még amire nem gondoltam :)

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

12 éve használok konténereket százas, de de azóta lehet hogy ezres nagyságrendben és még nem szívtam be semmit. Soha  nem veszett el semmim, nem hogy éles adat. Az OpenVz-ről LXC-re átállást is megugrottam hiba nélkül.

Talán az az oka, hogy elolvasom a doksikat :D

Ja és javaslom, hogy ne próbálj orákulum lenni, inkább kérdezd meg, hogy egy másik ember mit csinált eddig :D

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

teljesen mindegy mit csinaltal eddig, nem perzisztens sztoridzsen tarolni perzisztensnek szant adatot: ontokonloves :)
egy kontener by design eldobhato, ujrateremtheto. az adatok nem.
mindenkinek addig van szerencseje, amig a korso a kutra... vagy hogy volt :)

Egyetértek. De lehet, hogy én sem olvasom rendesen a dokumentációt. :D

Edit. Úgy gondolom, hogy bármennyit is tanulom és értem a konténerekkel való tevékenységeket, soha nem sikerült magát a szemléletet elsajátítanom. És ez egyáltalán nem a konténerek hibája. Sokkal inkább az én hiányosságom. De amig pl az lxc működését és szemléletét nagyon gyorsan sikerült magamévá tennem a docker sohasem lett számomra kézenfekvő. És még egyszer: ez csakis az én korlátoltságom miatt van.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Te szerencsének hívod én tudásnak :)

Egy vm is pont annyira eldobható, mint egy ct. Egy nagy terhelésű, dinamikus weboldalnál érthető a dobálódzás, de egy kisebb cégnél, mondjuk  dns, smaba, nextcloud, postfix, stb ct-n mi a bánatot dobálsz el? Semmit. Az meg, hogy az adat az /rpool/data/mappa vagy az /srv/mappa helyen van nem igazán különbség. Egy ct mitől hibásodna meg jobban, mint egy vm? Ha meg szükséges, ott a varázs utasítás az adatoknak, az mv :)
Ráadásul a dobálódzás sokkal inkább docker mint lxc szokás.

Én megelégedéssel használom a konténereket, (nekem) könnyebb velük a munka, lényegesen kisebb overhead, 1 sec reboot a gyakorlatban a legtöbb lxc újraindítást a felhasználók észre sem veszik, közvetlen fájlhozzáférés. Nekem az egyetlen komoly hátrány, hogy nincs live migration. Az nekem nem hátrány, hogy egy host os verzióváltásnál észnél kell lenni, mert az a vm-re is igaz.

ggallo érve, a bind mount-ra, adminisztrálás miatt érthető, de egyből jönnek vele a problémák is, pl a replikációnál. Ugyanazon a gépen a bind mount inkább rugalmasságot és könnyebb menedzsmentet ad, nem biztonságot.

Az hogy hol jobb az adat erősen környezet függő, nem pedig a ct szar.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

egy kontener jarhat akar geprol gepre is. ez a lenyege. van egy "playbook","template", nevezd aminek akarod, amibol elo tud allni, barhol, barmikor.
az adat olyankor megy a levesbe ami benne volt: bele sem kerul.
az, hogy te vm-kent hasznalod a kontenereket, az egy dolog :)

Ott "nézed be", "nézitek be mindketten" az egész szálat, hogy Te a konténerezés alatt annak modern formáját érted, ami a Docker-Kubernetes vonal. Ahol a konténer eldobható, csereszabatos kell legyen a felhaszálási mód, filozófia miatt, teljesen külön választott adatkezeléssel. Gyuri23 pedig a klasszikus egyszerű Linux konténer irányából jön, ahol a konténer csak egyfajta magasabb szintű szeparáció azonos hoszton, és kevesebb erőforrást visz el, mint egy VM (ami még magasabb szintű szeparáció, magasabb overhead-del).

Szerintem mind a kettő valid, de teljesen más filozófia mentén történő felhasználása a konténerezésnek.

Azért használja gyuri23 "vm-ként" a konténereket (merthogy eredetileg arra voltak, nem az eldobhatóságra, azt a Docker hozta a köztudatba), Te pedig (szerintem) azért állsz bele, mert a modern felhasználást ismered inkább, vagy abban mozogsz többet. Mind a kettőtöknek igaza van, ezt kell látni.

Szerintem ezen ne vitázzatok tovább. De persze vitázhattok, szabad, csak szerintem ne tegyétek.

Nem "az a megközelítés", hanem a konténerek maguk koncepcionálisan tényleg chroot-ok szteroidokon.

Az, amit te mondasz hozzá, az már a modern hozzáköltés az eldobhatósággal meg a többivel, de a konténereket eredetileg az izoláció igénye, és nem az újrahasznosíthatóság hívta életre. Régóta létező koncepciót kapott fel az ipar és költött hozzá dolgokat. A BSD-kben évtizedek óta létezik a jail intézménye, ami gyakorlatilag szintén konténerizáció a lehető legalapvetőbb formájában, de mögötte a tároló perzisztens, a mentett adatok szintén.

Az OpenVZ és az LXC szintén ebben a szemléletben íródott, ezek ténylegesen izolált hálózati/egyéb stackkel felpimpelt chrootok. Nem is használnak pl közös image-t úgy, ahogy a Docker/ContainerD használ. Használhatsz templateket hozzá, amiből jön az oprendszer, de a template és a tényleges konténer között nincs szükségszerűen több kapcsolat, mint amikor egy HDD-t klónozol egy másik HDD-re.

A Docker vezette be először azt a szemléletet (vagy legalábbis ezzel a szemlélettel ő terjedt el széleskörűen), hogy az image és az abból származó konténer között kapcsolat van. Aztán valaki meglátta ebben a koncepcióban a kettővel nagyobb absztrakció lehetőségét, és épített rá egy komplett ipart.

Különben, a Docker konténerek "ephemeral" storage-e is perzisztens mindaddig, amíg el nem törlöd a konténert (docker rm). Nem véletlenül létezik minden konténerizációs engine-ben a stop/start intézménye, ez nem törli sem a konténert sem az "ephemeral" storage-t, így kvázi lehet chroot-ként is használni ezeket a konténereket.

Érdemes elolvasni a konténerizáció történelmét, nagyon-nagyon régi dologról beszélsz. https://www.aquasec.com/blog/a-brief-history-of-containers-from-1970s-c…

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

kosz. en ezt vegigkovettem chrootostul, openvzstul mindenestul a gyakorlatban is. :)
nem veletlen tekintek ugy egy kontenerre, ahogy.
ettol, ha 2025-ben valaki kontenerekrol beszel, az 99%-ban by default egy orchestrationt is jelent es igen, eldobhato kontenereket, nem pedig egy koszos chroot-ot :)
a perzisztens storage pedig nem veletlen talalmany, nem viccbol kezeljuk kulon a szoftvert es az adatot. a chrootozgatas is azert jott letre, mert a privilegio-szeparaciora es a dependency hellre kellett valami.

ugyanaz a sztori, hogy mikor azt mondod elmesz kocsikazni egyet, azt2025-ben senki nem ugy fogja erteni, hogy lovak huzzak es a boglyat rakod magad moge :)

Jogos.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Szóval mi úgy használjuk, hogy van minden ügyfélnek egy dataset létrehozva kvótával, és abban vannak további al-datasetek az ügyfél tényleges mentéseinek minden CT-hez külön. A legtöbb ügyfélnél persze ez egyetlen al-dataset egyetlen CT-hez. De van olyan is, akinél van PBS, kopia a laptopokhoz és rsync is egy régi NAS mentésére. Így ügyfél szinten tudjuk az ügyfél fő dataseten beállítani a tárhely korlátot, és az ügyfél pedig annyi tölt be az egyes al-dataseteken lévő tárolókba, amennyit akar/fér.

Ha a CT-k tárolója lenne a mentés helye közvetlenül, nem ilyen bind mount, akkor csak CT-nként tudnánk tárhelyet állítani, kézzel kellene vezetni mennyit is adtunk ki összesen adott ügyfélnek, és ha változtatni kell az elosztáson egy ügyfél tárolói között, azt megint csak kézzel kell adminisztrálni. Persze megtehetnénk, hogy ügyfelenként felvesszük a dataset-eket a PVE-re storage-nak kvóta beállítás után, de az megint plusz adminisztráció, és akkor még az egyes CT-ken csak be kell állítani egy tárhely méretet a PVE felületen, nincs olyan opció, hogy "írhatja amíg a rendszer engedi a szülő dataset kvótája szerint". Nyilván lehetne játszani overprovision-nal minden CT-re, hogy az az ügyfél limitig nyújtózkodhat minden CT, de az megint nem eléggé áttekinthető számunkra.

Tehát adminisztrációs kényelem okán van ez így, végülis.

Köszi, világos.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

VM előnyök:

- akármilyen kernel (régi v új v más) használható
- nfs mount tisztán megoldható
- host upgrade után nem "szopódsz be" egy új restrikció miatt (ld. még cgroups)
- docker futtatás 

CT előnyök:

- ha valamit gyorsba' ki akarsz próbálni
- ha valamit nagyon biztosan tudsz hogy ezek csak "sima csomagok" és sose semmi több 
  - pl nekem ansible tower így van, pedig lehetne konténer is.

A CT nem ad többet mint egy docker konténer, de macerásabb adminisztrálni.

zászló, zászló, szív

Persze egyetértek azzal amit írsz, és nem mondanám, hogy jellemzően CT-ben futtatunk dolgokat. Ennek ellenére nekem valahogy még mindig túlzásnak tűnik a hosztra virtualizáció, arra VM, abba Docker és ott konténereket futtatni. Pláne, hogy a Docker VM-nek nem eléggé flexibilis a tárterülete, ha a host-ról adom, nem egy külső tárolóról. Persze van Proxmox-on VM-ben Docker példányok nekünk is ennek ellenére, mert a Docker nagyon praktikus.

Ráadásul nekem valamiért a CT (általában Linux konténer) és a Docker kb. azonos funkciója és működése miatt nem is tűnik logikusnak Proxmox-on CT helyett egy VM-ben Docker-en futtani bármit. Ha a fizikai gépen Docker lenne csak, az más kérdés, de akkor hiányoznának a Proxmox extrái.

Ez a mentő rendszer ilyen téren "speciális". Azért is nem "engedünk" egzotikus dolgokat kérni az offsite backup rendszerre, hogy CT-ben biztonsággal és problémamentesen futtatni lehessen, és ne kelljen a CPU-t meg a memóriát elpocsékolni sok-sok kb. azonos kernel futtatására VM-ekben. És a CT-vel megspóroljuk az overhead jó részét, de tudunk az ügyfélnek SSH hozzáférést adni, ha igényli. Docker esetén mindenkinek kellene egy VM, amihez hozzáférhet és ott nyomogathatná a saját Docker-ét. Egy host-on vagy egyetlen VM-ben futó Docker-hez nem adnék különböző ügyfeleknek hozzáférést akkor sem, ha sokat dolgoznék a jó szeparációval. Szerintem az egyszerűen nem elég szeparáció még akkor sem ilyen célra.

A mentő rendszered sztem ez:

"- ha valamit nagyon biztosan tudsz hogy ezek csak "sima csomagok" és sose semmi több "

Nem gondolom h túl sokat spórolnál a ct-vel a vm helyett de ha megy akkor pont jól van ez így.
Én a saját PBS-emet azért raktam VM-be mert a storage-ot alá NFS-en mountolom fel.

zászló, zászló, szív

Még egy dolog: ha van egy csomó lxc-d, előbb-utóbb lesz közte legacy is. Nem vagyok biztos benne hogy egy 22-es vagy régebbi ubuntus konténer jól fog menni a 13-as Debian kernelével. Az egészen biztos hogy senki nem tesztelte :)

Fordítva is igaz, volt is ebből bajom: nagyon régi volt a proxmoxom (3.x valami) és a valamelyk (talán 22-es) ubuntu már nem akart felmenni rá. 

Szóval a host és a konténer verzióját sokkal közelebb kell tartani egymáshoz mint a vm-ét.

zászló, zászló, szív

( n.balazs v | 2025. 08. 21., cs – 13:03 )

Nem szurkálódásból kérdezem: Eddig volt valamilyen backup megoldás?

Ha van kedved kísérletezni: Rendben, hogy a PBS nem támogatja a Windowst. Viszont tehetsz WSL-t Windowsra. Oda meg fel tudod varázsolni a PBS klienst. Persze ez nem a teljes Windowst fogja tudni menteni, csak mappákat.
Esetleg kombinálhatod a PBS-t Cobian Reflectorral (alias Cobian Backup, alias Cobian Gravity). A Cobian kiteszi a fájlokat adott megosztásra, ami mondjuk Linuxon fut. A Linuxos gépet meg mented PBS-sel.

Nem írtad, hogy van-e AD. Ha igen, akkor azt is menteni kellene mihamarabb. Arra PBS teljesen alkalmatlan lesz.

A PBS mellett megnézném a helyedben a Baculát is. Elég régóta élő termék, sok szoftvert és OS-t támogat.

Eddig semmilyen backup nem volt, ezéet is kérem a segítségeteket, hogy merre induljak. A wsl megoldást nem szeretném. Natív gui-s windowsos megoldást keresek.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

( Mik v | 2025. 08. 21., cs – 19:00 )

Hogy legyen egy cloud alternatíva is ami backup jellegű:

Schools and universities with Google Workspace for Education subscriptions have a baseline of 100 TB of pooled storage shared across all users.

A Google Workspace for Education meg ingyenes. És jár vele egy csomó minden más is. 

(a Google Drive asztali verziótól én idegállapotba kerülök, de azért egy ilyen környezetben sima felhasználóknak jó lehet) 

M365-ből is van iskolai ingyenes licenc, nem is rossz tartalommal. Na nem mintha jobb lenne, csak úgy mondom, ha valakit érdekel. Az az előnye, hogy az MS garantálni tudja, hogy csak EU területen tárolja az adatokat, a Google viszont egyelőre nem kínál ilyen lehetőséget. Ez viszont magyar állami finanszírozású intézménynél elvárás/kötelező.

Nekem mindkettővel az a bajom, hogy pl. a fehérhajú bohóc gondol egyet, és a MS meg a Google szépen lekapcsolja a szolgáltatást ahol mondja nekik. Vagy nem lekapcsolja, csak holnaptól fizetős. Gondolhatja mindenki, hogy ilyen úgysem lesz, de azért én inkább nem építenék ilyenre, max. kiegészítésnek, ami nem baj ha elveszik... A fizetős csomagok valamennyire más tészta, de az ingyenes az szerintem olyan, mint a kutya vacsorája...

( B2iL4o | 2025. 08. 25., h – 10:59 )

> A rendszer egy Raid10 tömbben két diszken..

Biztos, hogy Raid10-es az a tömb?

Úgy tudtam, hogy ezt a Vatikánon kívül senki sem alkalmazza, annyira high-tech megoldás..

A raid10 pont annyira jó, mint bármelyik raid. Vannak előnyei, hátrányai (mondjuk két diskkel én semmi előnyét nem látom, meg eleve összerakni is csak taknyolással lehet).

És részemről majdnem biztos vagyok benne, hogy raid1 lesz az, esetleg (~1%) raid0 (ehhez már azért kell merészség), és szinte kizárt hogy raid10.

Hát, őszintén szólva azért lett ez mert a hp hw raid vezérlője van és az ilo felületen lehetett választani. Úgy gondoltuk, a csíkozással növelhető a redindancia is.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Hát, ez a válaszod inkább összekutyulta, mint letisztította sz eddigi képet... :-)

A csíkozás (stripe, RAID0) az egy redundancia nélküli "sorba kapcsolás", tárterületet és sebességet lehet vele növelni, adatvédelem nincs. Minimum 2 lemez kell hozzá.
A tükrözés (mirror, RAID1) az a nevéből is sejthetően egy diszk másolata egy másik diszkre, "párhuzamos kapcsolás", adatvédelmet ad 1 diszk hiba esetén, valamint az olvasási sebesség és olvasási IOPS lesz magasabb. Minimum 2 lemez kell hozzá.
A csíkozott tükrözés (striped mirror, RAID10) az előző kettő kombinációja, amikor is két tükröt (két RAID1 tömböt) kapcsolsz sorba. Így növelhető a átviteli sebesség és az IOPS egyaránt, de van hibatűrés. Minimum 4 lemez kell hozzá, 2 lemez elvesztését viseli el (nem mindegy melyik kettő).
Egy paritásos tömb (RAID5) paritással dolgozik, az adat lemezekből számol egy paritást és azt a paritás diszken tárolja. A RAID5 esetében a paritás diszk nem egy kijelölt lemez, hanem szét van osztva az összes lemez között a paritás adat. Egy lemez elvesztése esetén a maradék lemezekből, a rajtuk lévő paritás adattal kiszámolható az elveszett diszk adata. Minimum 3 lemez kell hozzá.
Két paritásos tömb (RAID6) ugyan az, mint a RAID5, csak kettő lemeznyi paritást tárol, így kettő lemez elvesztését bírja ki adatvesztés nélkül. Minimum 4 lemez kell hozzá. Ez a RAID10-zel szemben bármely kettő lemez elvesztését eltűri
A RAID50 és RAID60 pedig az előzők analógiájára RAID5-6 tömbök csíkozása (sorba kapcsolása) a nagyobb tárterület, sebesség és IOPS érdekében.

Ezek alapján mindenképp nézz rá, milyen a RAID konfiguráció, nehogy egy diszk hiba esetén meglepetés érjen.

Reméljük azért a "fele akkora"-t nem sikerül összehozni, az minden szinten iszonyú hülyeség lenne.
Nem ismerem a hp raid megoldásait de remélhetőleg most raid1-ben vannak a diszkek és a logikai diszk van arra felkészítve hogy ha jönne bele még 2 ugyanolyan fizikai diszk akkor elkezdené a stripe-ot csinálni azokra.

zászló, zászló, szív

Ok tehát a szerver egy hp dl380 g7, ennek a felületén a raid 10 az a raid 1+0 jelent. Hardware raid az minden gépben a HP Smartarray P410i -je. Ha nem voltam egyértelmű akkor bocsi. Én nem csináltam mást csak kiválasztottam a listából ezt, a többit intézte a hp.

“The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use them.”

― Philip K. Dick

Értem.

Nem kötözködésből írtam, csak a nagy könyv szerint RAID-10-hez minimum négy lemez kell és ezzel tudja hozni a legjobb teljesítményt.

Kevesebb disk elméletileg csökkenti a teljesítményt, de ilyen bizarr megoldásokra nem találni benchmark adatokat, vagy jó mélyen el vannak

ásva.

Mivel HP, minden is lehetséges a lehetetlent is beleértve.

Négy diskkel hozza a minimum teljesítményt, ennél kevesebből csak erőszakkal lehet összerakni egy rettenetet.

Aztán egy ideig kb. lineárisan nő a teljesítmény, aztán biztos van egy pont, amikor már kár plusz diszket betolni, de hogy ez hol jön el, az erősen elméleti kérdésnek tűnik.

Amit én közelről láttam, az kb. 64 disk lehetett, már ha jó emlékeim vannak, hogy kábé ekkora vas, kábé ennyi polccal, az kábé ennyi disk lehetett. 

Valahogy sejtettem, hogy a "legjobb"-ba bele fogsz kötni és nem kontextusban értelmezed, 

azaz ha 4-nél kevesebb van és valami "RAID 10"-es megoldás, akkor az nagy valószínűséggel a teljesítmény rovására

megy.. de akár az is lehet, hogy nincs igazam.

Nem feltétlen rettenetről van szó, a neten találni pár érdekességet, de mind elég régi..

https://wiki.archlinux.org/title/RAID

https://web.archive.org/web/20160314063744/http://blog.a2o.si/2014/09/07/linux-software-raid-why-you-should-always-use-raid-10-instead-of-raid-1/

A "nagy" gyártók meg különösen szeretnek kavarni és minden is lehet.

A fentebb linkelt oldal azt taglalja, hogy mdraid-del lehet 2 lemezes RAID10 tömböd "far2" layout-tal létrehozva, ami gondolom azt mondja az mdraid-nek, hogy a stripe-ok 1-1 másik lemeze nem érhető épp el. A cikk szerint ez a trükk azért kell, mert az mdraid sima RAID1 tükör esetén, egy művelethez nem használja olvasásra mindkét diszket (csak ha több párhuzamos művelet van), a RAID10 far2 módban viszont mindkettőről olvas akár egy művelethez is.
Annak utána lehetne nézni, hogy ez 2014 óta változott-e az mdraid megvalósításában (logikus lenne, ha implementálták volna bele a "normál" RAID1 működést olvasás terén).

Nem gondolom, hogy ez működne HW RAID kártyával, hogy engedne RAID10 tömböt létrehozni 2 meghajtóval, merthogy mi értelme (bár meg sem lepne, ha mégis engedné valamelyik).

Ezen felül szerintem ez csak teoretikus vita alapja lehetne, mert RAID1-et mindenki a redundancia okán csinál, az csak nem várt plusz, ha növekszik az olvasási átvitel és IOPS egyúttal. De mivel nem utóbbi a cél, így szerintem senki nem esik pánikba, ha egy RAID1 tömb csak egy diszk sebességét hozza minden téren.

Hát, írásnál máris bukik a dolog, mert hiába a két vinyó, mindkettőre ki kell tolni ugyanazt az adatot.

Olvasni lehet okosan felét itt, felét ott, de ez már a vezérlő belügye.

Én ettől még nem nevezném RAID10 -nek a stripeolva olvasott RAID1 -et, mert megtévesztő. Marketing szagú.

( YleGreg | 2025. 08. 26., k – 10:29 )

Szerkesztve: 2025. 08. 26., k – 10:32

Réges rég, egy messzi-messzi iskolában nulla pénzből kellett backupot összeraknom.

Sok morfondírozás után a következő megoldás született:

- mindenkinek meg lett mondva, hogy a kliens gépeket nem mentjük, mert nincs rá erőforrás, ezért aki úgy érzi, hogy az anyaga fontos, az rakja fel a központi fileserverre, a saját vagy a csoportjának a könyvtárába.

- a file serveren windows ütemezőből indult minden éjjel egy winrar.exe indítás, ami rekurzívan végigment a kiajánlott tárhelyen, és a legerősebb tömörítéssel készített egy mentést minden olyan állományról, amin be volt kapcsolva az archive bit, majd a forrás állományokon törölte a bitet. A kész mentés egy nagy állományt jelentett, a neve az adott napnak megfelelő volt.

- asszem havonta futott egy full mentés, amit kiírtunk CD-re. A sok word/excel/ppt meglepően jól tömöríthető volt, mondjuk most már a docx, xlsx már eleve tömörített, de legalább elég kicsik, és már nem kell beleférni a 700 MB -ba.

- a kliens gépek egyformák voltak, ha megmakkant a vinyó, akkor nem volt nehéz újra húzni. A szerverek (mail, AD, file, intranet-web, stb) eleve RAID5 alatt voltak, azzal nem volt gond. (Exchange -re volt még valami varázslat, asszem valami beépített Windowsos tool, de már nem emlékszem, hogy mi volt ami mentette.)

Így elég jól elműködtünk, mert a legtöbb visszaállítási kérés vétlen törlésből, vétlen felülírásból keletkezett.

Nem egy vérprofi módszer, de ingyen volt és jól működött.

A mai világ ezt annyiban nehezíti, hogy komolyan készülni kell belső támadásra is (titkosító vírusok), és a mentést úgy kell készíteni, tárolni, hogy lehetőleg azt ne tudja elérni egy ilyen károkozó.

A leggyakoribb továbbra is a véletlen törlés, módosítás (felhasználói hiba), de most már sajna nem lehet egy Windows-ról egy NAS-ra SMB-n másolgatni a mentett adatot, mert a titkosító vírus az SMB-s megosztást is betalálja ügyesen (vagy azt elsőre, az éles adatot csak utána...).

A leggyakoribb továbbra is a véletlen törlés, módosítás (felhasználói hiba)

A kedvencem (true story) ami már többször előfordult:

- Juj, eltűnt egy fontos excel-em, sürgősen vissza kéne állítani!
- Ok, mi a fájlnév és hol volt?
- Azt nem tudom.
- A fájlnevet, vagy, hogy hol volt?
- Egyiket se, csak negyed évente kell használnom.
- Mikor volt meg utoljára.
- Negyed éve biztos.
- Hát így könnyű lesz...
Pár perc múlva kap egy listát, negyed évvel ezelőttről, az összes xlxs fájlról ami bárhol is volt a mappáiban x1000 név.
Hosszabb idő múlva...
- Basszus, nem kell visszaállítani, megvan, csak rossz helyen kerestem.

Ezekre nagyon szeretem a restic-et. Egy ilyen lista, pár pillanat. Van ahol csak ezért van restic-is beüzemelve.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

:-D

Nekem a legjobb eddig, hogy

- vissza kellene állítani egy Excel állományt
- hol van ez az állomány, visszateszem neked a tegnap esti mentésből
- ma reggel hoztam létre, egész nap írtam bele, majd kilépéskor arra nyomtam, hogy ne legyen mentve
- automata mentés be van kapcsolva? mert akkor megkeressük azt hová tette és átnevezzük
- kikapcsoltam, mert szerintem azért lassult be a gépem, a mentegetéstől
- akkor nincs benne a tegnapi mentésben, ha ma csináltad. meg úgy általában nem is létezik ez az állomány, ha sose mentetted el
- ezzel azt akarod mondani, hogy nem tudod mentésből helyreállítani az egész napi melómat? akkor minek fizetünk a mentésért?

Ő a hülye és még be is szól. Legjobb :D

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Jogos. Amikor ezzel mentettem, akkor még nem létezett a ransomware.

A vicc kedvéért egyébként megoldható a WORM működés, mert a napi mentés CD/DVD/BD -re írható, úgy, hogy nem zárom a lemezt, hogy mindig hozzá lehessen még írni. Ez egy külön gép, nem fogad hálózatról semmit, csak ránéz egy SMB vagy FTP helyre, és ha van ott új file, akkor azt hozzábiggyeszti a lemezhez.

Időnként ki kell cserélni benne a lemezt és kész.

Pluszban random kibont néhány docx, xlsx állományt, és belenéz, hogy valid állomány-e, vagy egy enkódolt valami, és küld egy levelet, ha szerinte a file szerveren már végigpusztított a ransomware.

De ez tényleg csak vicc, elég szűk az a követelmény-tartomány, ahol egy ilyen kókány mentő rendszernek létjogosultsága van.