Át kell alakítanom a mentési eljárásomat, adjatok ötleteket. [megoldva]

Segédprogramok

Sziasztok, jelenleg így működik a mentés:

Van egy dedikált Linuxos (RH7) szerver, ahol rsnapshot-ot használok a mentéshez. A mentendő adatok egy része NFS, egy része SAMBA megosztás felcsatolásával érhető el. A maradékot pedig ssh-n keresztül direkt csatlakozással menti le, tipikusan root userrel csatlakozva, kulccsal. Az rsnapshot rsyncet használ, így tipikusan csak a különbség utazik a hálózaton, ami azért fontos, mert a mentő szerver BP-en van, a mentett adatok fele pedig a Lengyelországi adatközpontunkban található. A helyi diszkre jelenleg az utolsó 12 mentés fér el. De ez ettől még csak egy diszkes mentés, nem archiválás. Erre van egy másik, windowsos szerverünk, azon pedig a CA Arcserve végzi az utolsó mentés (daily.0) szalagra írását.

Ez a megoldás évek óta tökéletesen teszi a dolgát, az egyetlen problémát az okozza, hogy a PL DC-t nem mi üzemeltetjük, hanem az IBM, akik havonta egyszer letiltják az sshd-ben a root belépését, akkor is, ha csak kulccsal léphet be. Én ezt persze visszaállítom, mert a mentés fontos.

Viszont ezt a csiki-csukit már nagyon unom, így a legkisebb változtatást azzal érném el, ha az ssh-n keresztüli mentést megszüntetném (mezei userként nem tudja menteni azokat a fájlokat, amihez nincs joga). Tehát meg kellene fordítani az irányt, a mentendő szerverek mennének a mentő szerver felé. Így viszont megvan a lehetősége annak, hogy illetéktelenek is beléphetnek a mentő szerverre. Másik lehetőség, hogy minden szerveren csinálok a mentendő adatokról egy NFS share-t.

Vagy keresek egy másik szoftvert. Tanulmányozom a bacula-t, eddig tetszik, ssh független, jelszóval védett, a mentő szerver csatlakozik a klienseihez. Ám úgy tapasztaltam, hogy mindent egy fájlba ment, ami nekem nem jó, mert jobb szeretem, ha látom a fájlokat. Könnyebb kikeresni őket visszatöltéskor.

Nem lehet beállítani, hogy a mentett fájlokat natívan tárolja a diszken?

 

update: kaptam egy remek tippet https://unix.stackexchange.com/questions/325100/proper-way-to-set-up-rs…

a mentendő szervereken létre kell hozni egy fájlt az /etc/sudoers.d alatt ezzel a tartalommal:

msandor ALL = (root) NOPASSWD: /usr/bin/rsync
 

fel kell másolni minden gépre a mentő szerver publikus kulcsát, majd az rsnapshot konfba be kell szúrni ezt:

+rsync_long_args=--rsync-path="sudo rsync"
 

Persze ezt majd ansible-playbook-al fogom teríteni, eddig erre még nem volt playbookom, ideje elkészíteni ;-)

Mielőtt azt mondanátok, hogy erre dedikált usert csináljak, azt kell mondanom, hogy az nem biztos, hogy megállna az auditon, engem már jóváhagytak, így egyszerűbb.

  • 1021 megtekintés

( andrej_ v | 2021. 01. 02., szo – 16:38 )

Nem teljesen értem, hogy bárki miért tiltja le az sshd root belépést havi 1x fixen. Ha már root belépés, akkor a kulcsosat is tudod IP-re korlátozni, illetve az letiltós arcoknak jelezni, hogy azért gondolják át ezt, mert nem poénból van így.

Ha SSH független, akkor valamilyen szimpatikus VPN-en keresztül már egészen kitárulnak a lehetőségek. A VPN lehet adhoc felépítve, nem kell állandónak lennie.

A mentő szerveren (is) el tudod tenni az SSH-t speciális portra, tudod tűzfalazni és az ssh konfigban szintén lehet IP-re korlátozni.

Per definitem remote root _nincs_ jobb helyeken. Kulcsos auth-tal sem. mentéshez meg nem root usert használunk, hanem a mentéshez szükséges joggal (és nem többel!) rendelkező technikai usert. Persze, root-tal könnyebb, mert az lát mindent _is_, de a minimálisan szükséges jogosultságnál ez sokkal-sokkal több.

Nincs szükség VPN-re, mert ezek a szerverek belső hálózaton vannak, a gond nem az elérésükkel van, az ssh alternatív portja nem old meg semmit.

Talán bővebben le kellett volna írnom az IBM szerepét: a szervereinket mi üzemeltetjük, de a PL DC-t az IBM viszi. És az ott futtatott Linux, Windows, AS400-as szervereket is ők üzemeltetik OS szinten. Emiatt lehet, hogy az ssh-t is időnként saját kedvük szerint konfigurálják. Sajnos nincs egyértelműen definiálva a szerepkör, ez egy kényszer házasság, én addig feszegetem a határokat, amíg le nem basznak érte. 

Backup user, megfelelő acl-lel lássa azt, amit látnia kell. Amit meg root-only/postgres-only lehet csak tartani (pg nem indul el, ha a data könyvtáron a pg useren kívül akár acl-lel is van bármilyen jog), azt lokális backup folyamat mentse, és azt a fájlt vigye el a backup user.

Persze, lehet acl is, meg lokálisan futó akármi is, ezt a konkrét backup megoldás mentén kell rendesen beállítani.

De továbbra is az az üdvözítő, hogy igen is fel kell tolni a problémát, hogy kedves kollégák, hogyan lesz backup, és aki szolgáltat, az szolgáltasson, és legyen kooperatív abban, hogy milyen feltételek mellett mit lehet csinálni. Mert ez az én kerhelek valamit, amit most épp nem basznak el, az fusi lófasz. Ja, lehet, hogy lesz a másik oldalt valami büdös gyökér, azért van a manager mind a két oldalon, hogy elmondja, hogy baszki bélám, márpedig az én üzletmenetemhez a backup kell, úgyhogy lesztek kedvesek, és dolgoztok.

Jahogy. Bár ahogy elnézem, az csak olyan elméleti. Mármint a van valami backup, csak fogalmam sincs, milyen és hogyan lehet visszatenni, az nincs.

De ez ilyen tipikus ugyan egyáltalán nem beszélünk, de a másik oldal biztos segghülye szituáció, márpedig abban, hogy az ilyen, a fogadó oldal is vastagon benne van, akkor is, a a másik oldal valóban segghülye*. Így nem lehet dolgozni, meg üzemeltetni. Ezt a szituációt úgy kell kezelni, hogy a lentebb emlegetett szar szerződést el kell eszkalálni a picsába, ne vicceljünk már, pénzügyi szektorban ez megengedhetetlen üzleti kockázat. És ha képtelen rá a management megoldást találni, akár úgy, hogy felülvizsgálják a szerződést, akár úgy, hogy kooperációra késztetik a másik felet, akár akárhogy, akkor meg fel kell állni a fenébe, de minimum közölni, hogy én a PL DChez nem nyúlok, mert ez így nem üzemeltetés, hanem vicc**

* Ráadásul amire panaszkodik, az bizony egy teljesen reális automata compliance checking folyamat részének tűnik, szóval ez egyáltalán nem biztos.

 ** Bár az igazság az, hogy ahol a megváltó megoldás az lett, hogy a kolléga néhány nap alatt rácsodálkozott a sudoersre, ott lehet hogy jobb volna meghallgatni azt a segghülye másik oldalt

a lentebb emlegetett szar szerződést el kell eszkalálni a picsába, ne vicceljünk már, pénzügyi szektorban ez megengedhetetlen üzleti kockázat

Helyi szinten (Hungary) ezt már többször elkezdték feszegetni, hivatkoztak mindenre, ügyfelekre, pénzre, ami csak eszükbe jutott, de a szerződést a New York-i központban kötötték, mindenki pont leszarja a magyar leányvállalatot, mi csak kerekítési hiba vagyunk a cégnél.

És az IBM ezt pontosan tudja, ezért is élnek vissza a hatalmukkal. Az infra csapat Európai vezetői se hülyék, látják, hogy szart kapunk aranyáron, de nekik sincs hatalmuk ezen változtatni. Az egyetlen esélyünk, hogy az éven jár le a szerződésünk, de a pletykák szerint úgy is marad az IBM, "túl drága lenne megint költözni". Remélem, hogy legalább az eddig felmerült problémákból tanultak, és módosítják a szerződést.

ez így nem üzemeltetés, hanem vicc

Én lelkiismeretes ember vagyok, nálam az első mindig a folyamatos üzletmenet, elvégre a fizetésem is abból van, az csak másodlagos, hogy minden esetben "hivatalosan" járjak el.

Hát, ha nem megy, akkor fel kell állni a picsába :) Vagy legalábbis megmondani a főnöködnek, hogy nyugodtan előveheti azt a kártyát is, hogy vagy lesz akármi, vagy pl feláll mindenki a leszart kis leánynál. Meg nem reménykedni kell, hanem szépen folyamatosan mantrázni, hogy ez szar. Minden alkalommal, amikor a legkisebb probléma is van, akkor azonnal eszkalálni, hogy ez megint nem jó. Ha a főnököd se tud mást tenni, csinálja ő is. Kérni kell, hogy lesznek kedvesek, és lepróbálják veletek együtt a visszaállítást. Kérni kell, hogy lesznek kedvesek, és részletekbe menően ismertetik, hogy hogyan üzemeltetik ők az OSt. Mit, mikor, hogyan csinálnak, mihez nyúlnak hozzá, te mihez nyúlhatsz hozzá, mik a szabályok. És persze lehet, hogy már a magyar főnököd elhideolja ezt felfele, vagy tényleg nem jut semmire. Neked mindkettő hasznos infó.

> Én lelkiismeretes ember vagyok, nálam az első mindig a folyamatos üzletmenet, elvégre a fizetésem is abból van, az csak másodlagos, hogy minden esetben "hivatalosan" járjak el.

Értem, csak a folyamatos üzletmenetet így nem tudod biztosítani, csak szerencsével.

"...én addig feszegetem a határokat, amíg le nem basznak érte."

Ahogy más is írta, nem feltétlen agyhalottak ülnek a másik oldalon :) Ilyenkor egy e-mail, hogy "Hé, fiúk, ez a problémám, mit tudtok javasolni?" esetleg célravezetőbb lehet, mint ha határok feszegetéssel történő kitapasztalása.

Még 1 nagy cégen belül is vannak direkt nem-kooperativ "kollégák" (röviden büdös gyökér seggfej, direkt gecizik az emberrel mert nem tudod megkerülni, és a rafkós nyelve a főnökség seggében van tövig, csak te szophatod meg ha nyiltan csatázni kezdesz vele), nemhogy ha 2 különböző cég melósának kellene összedolgozni, főleg ha az egyik fél "feljebb" van bármilyen ok miatt.

Ha pedig olyan helyre kerülsz, ahol nem? Felmondasz és új helyen reménykedsz h. nem megint egy ugyanilyen fasszal sodor össze a balsors? Nem egy magyar kkv v. nagy multi magyar leányánál dolgoznak műszaki kulcspozicióban olyan seggfejek, akik szakmaféltésből v. szimplán emberi fogyatékosságuk okán lettek ilyen együtt-nem-működő gecik. Ugyanakkor vannak már annyira rafinált dörzsöltek h. nem találni rajtuk fogást, és nagyon jó rutinnal ásnak alád, rúgatnak ki ha útjukba kerülsz.

"Ha pedig olyan helyre kerülsz, ahol nem? Felmondasz és új helyen reménykedsz..."

Alapvetően igen. Eddig is ezt csináltam, amikor nem voltam elégedett a menedzsment munkájával. De nagyon nem akarok úgy járni mint a nyuszika, aki kölcsönkérte a róka fűnyíróját.

És a részemről elmondtam, amit az adott témában gondoltam.

( uid_6201 v | 2021. 01. 02., szo – 16:49 )

Esetleg stunnel kölcsönös SSL tanúsítvány ellenőrzéssel + benne root-ként futtatott rsync?
rsync-et szeretem, mert képes --backup-dir -be a törölt/megváltozott állományokat eltenni + ZFS/btrfs snapshotot alá rakva félre van rakva a teljes állapot is.

( Fisher v | 2021. 01. 02., szo – 16:55 )

Nyilván az üzemeltető - IBM - nem bízik benned, hogy megfelelően vigyázol a privát kulcsra. Mivel a felelősség közben az övék, ez érthető is.

"A helyi diszkre jelenleg az utolsó 12 mentés fér el."

Ugyan hiányzik pár részlet, de az nem megoldás, hogy a hely diskre mented azt (is), amit amúgy rsnapshottal (lusta vagyok megkeresni, hogy az rsnapshotnak problémás-e helyben mentenie), és azt elcuccolni kb. bármikor máskor? Nyilván ez se tökéletes megoldás, hiszen a mentés vége + elcuccolás közben van egy ablak, ami akár jelentős is lehet.

Vagy ügyeskedni sudo-val, (ennek talán még értelme is van), kb. 10 másodpercet szántam rá, ezeket dobta a google:

https://gist.github.com/mufus/51cd2330ad86b4dc18f2

https://unix.stackexchange.com/questions/325100/proper-way-to-set-up-rs…

Ahogy nézem, ugyanaz a kettő, egy sudo rsyncet pattint fel.

A sudo úgy változik, hogy az általuk beállított sudoers fájlokhoz nem nyúlok, egy újat hozok létre, ami szemmel láthatóan egy dologra jó, az rsyncet rootként futtatja. Ezt egy olvasni tudó admin érteni fogja, bár nem vagyok benne biztos, hogy az IBM ottani kollégái közül mindenki megüti a mércét.

Nagyon bánom, hogy a kb 5 éve indult migrációról nem blogoltam itt, annyi szerencsétlenkedést elképzelni se lehet, mint amit ez a kutyaütő banda elkövetett.

A főnökömmel egyeztetni fogom hétfőn, a mentés nekünk fontos (meg az üzletnek), az IBM részemről le van szarva. Ez egy kényszerházasság, egy amcsi balfasz kötött egy a cégünkre előnytelen szerződést, és az a rossz benne, hogy bebetonozták az IBM-et ebbe a pozícióba.

Mondok egy példát, az IBM nem vállalt SLA-t, és ezt nálunk aláírták vazze. Többször előfordult, hogy beszart egy prod. szerver, konzolunk nincs, engem pont kitiltottak (máig nem derült ki, hogy miért, a feletteseim nem kértek ilyet), kb 2 hétig ment a levelezés, hogy engem újra engedélyezzenek, pedig már az atya úristent is ccztük a levelezésbe. Már az MNB is ránk telefonált, hogy miért nincs kint a neten az ügyfeleinket tájékoztató weboldal. Szerencsére az utolsó mentésből el tudtam indítani egy másik szerveren. Ha várok az IBM-re, már rég megbüntették volna a cégünket.

"ngem pont kitiltottak [...] kb 2 hétig ment a levelezés, hogy engem újra engedélyezzenek" - A probléma mélyebben gyökerezik, mert ez úgy néz ki, mint egy one-man-show, amiből leginkább kimaradni buli, nem benne lenni.
Ha annyira kritikus a prod. szerver működése, akkor illendő lenne egy saját élő kiszolgálót összerakni, amire minden release/konfig módosítás a kintivel azonos folyamatban kimegy, és a fájlszintű adatokat naponta/naponta többször (amennyi kiesés/adatvezstés elfogadható) szinkronizálni a hazai oldalra, ami meg DB-ben van, azt archivelog (vagy hasonló, minden értelmes RDBMS tud ilyet csinálni) áthúzásával és az itthoni DB-re való folyamatos visszatöltésével közel szinkronban tartani.
Minthogy a gépen lévő adatoknak ti vagytok a tulajdonosai, így én azt is megfuttatnám a cégen belül, hogy a kinti üzemeltetők által a vm-ről készített mentést kapjátok meg ti is.

Ide is felteszem a kérdést általánosságban, nem konkrétan neked, hanem bárkinek aki ilyen cipőben jár a munkahelyén: van egy 5 éve tartó belső súrlódás, ami napi szintű frusztrációt okoz az egyik félben. Hatalma nincs változtatni rajta, de napi szinten frusztrálja, gyilkolja tudatalatt, még ha ennek nincs is tudatában. A szálka attól még ott van a sebben, és a seb folyamatosan gennyesedik, nem tud begyógyulni. Mit teszel ilyen esetben? Meneküljön el az adott munkahelyről? Azért 5 évig nyelni a mérget már komoly gyomorfekély-kiváltó tényező, ha az ember nem leszarom-módban üzemel. A motivációja morálja is évekre lemegy 0,0-ba, amit a következő munkahelyen se fog tudni visszanyerni egyik napról a másikra. Vagy ha egyetlen/leginkább kenyérkeresőként a család fő eltartójaként kiszolgáltatott helyzetben végig tűrni a végtelenségig az ilyen szarságokat?

Szeretem a munkámat, de igazad van, általában én állok a fasznak a rosszabbik végén, emiatt időnként beveszem a leszarom tablettát, aztán keresek magamnak valami olyan elfoglaltságot, amit élvezek. De gyorsan vissza tud jönni az életkedvem, mindig találok magamnak új kihívást az üzemeltetésben, annyi tanulnivaló van.

2020 nálam abszolút az ansible és a docker körül forgott, amit a nehézségek ellenére is hihetetlenül élveztem.

Hát, 5 év után már rohadt nehéz, de alapvetően azért a felmondás előtt még meg lehet próbálni, normálisan, asszertíven kommunikálni a másik féllel is, hogy nézd Bélám, én évek óta nyelem ezt a békát, és most kérlek beszéljük meg, mert ez nekem nem jó, vagy a főnökkel is, hogy nézd, a Bélától nyelem ezt évek óta, de ...

Aztán ha nem, akkor imho következő munkahely. Egyrészt azért a tiszta lap igen is viszonylag gyorsan tud(hat) motivációt lendíteni, meg persze mindenhol van szar, de nem mindegy, hogy már el van-e mérgesedve, vagy már 77x megpróbáltad átvariálni, de nem sikerült. A kenyérkereset persze fontos, és biztos van olyan, amikor egyébként az ideg mértéke nem olyan, hogy ne legyen nagyobb szívás a váltás, és inkább beveszed a leszarom tabit, de valljuk be, ma az ITban azért elég rendesen vannak ma lehetőségek -- persze nyilván tudás/hely/akármi függő -- és kapkodni nem kell, nem az van, hogy felmondtál, van egy hónapod találni valamit. És jó eséllyel, már önagában az elhatározás, hogy akkor én ezt elengedem, keresek mást, segít leszarni a napi frusztrációt a végén.

( Zs | 2021. 01. 02., szo – 17:02 )

A bacula kapcsán azt gondold át, hogy bár tud különbözeti mentést, de azért egy idő után mindenképp kelleni fog full backup is. rsnapshot esetén egyetlen alkalommal, induláskor kell egy full backup, onnan kezdve akár 10 éven át is elegendő a különbözeti mentés, mert backup oldalon mindig előállítja a teljes állapotot.

Ha az a legnagyobb baj, hogy csiki-csukival a root kulcsos belépés is tiltódik, akkor azért arra vannak megoldások, hogyan védekezzünk ellene...

  • az sshd_config állományon a megfelelő flag-ek beállítása. Első körben levehető a "w" jog még a tulajtól is, ha ez a jelzés kevés,akkor egy immutable beállítása is jelezheti nem tetszésünket...
  • a BSD rendszerkből lopott megoldásként legyen egy toor user, 0-ás UID-del...
  • ha ez a vonal nem járható, akkor lehet egy backup user, detto csak kulcsos belépéssel, majd tegyünk arról, hogy az rsync ezen a gépen akkor is root-ként fusson, ha a backup user lépett be:
    • csúf megoldás, de legyen SUID-es az rsync és legyen a root a tulaj
    • egy fokkal szebb: legyen egy SUID-es shell script ami indítja az rsync-et, tulaj root, más a scriptet nem módosíthatja
    • használj sudo-t, a backup user az rsync-et sudo-val jelszó nélkül is futtathassa root userrel

Elsőre hirtelen ezek az ötleteim vannak, lehet csemegézni. :-)

"az sshd_config állományon a megfelelő flag-ek beállítása. Első körben levehető a "w" jog még a tulajtól is, ha ez a jelzés kevés,akkor egy immutable beállítása is jelezheti nem tetszésünket..." - Mert a túloldalon hülyék ülnek, mi? Ilyen után kifejezetten nehéz beszélgetésre kellene készülnie...

"a BSD rendszerkből lopott megoldásként legyen egy toor user, 0-ás UID-del..." - avagy a gányolás magasiskolája. Értelmes sshd a root login-t UID=0 értelemben használja, nem?

"csúf megoldás, de legyen SUID-es az rsync és legyen a root a tulaj" - bzmg... gányolda lvl. 1000...0000

"SUID-es shell script" - amin a suid bitet lesz@rja a rendszer...

"használj sudo-t, a backup user az rsync-et sudo-val jelszó nélkül is futtathassa root userrel" - na ez már valamennyire értelmes javaslat. Az előzőeket egy audit során 32pt piros bold betűkkel írnám bele a vezetői összefoglaló második bekezdésébe. (az elsőbe azért nem, mert ott a mit és miért vizsgáltunk összefoglalása van).
 

Az észrevételek jogosak. Nem mentség, csak magyarázat, de le lettem zsibbasztva a hozzászólás előtt, illetve

  • azért valljuk be, az sem teljesen perfekt megoldás, hogy az ssh konfig havonta képen van csapva, ha kell, ha nem, ha változott, ha nem.
  • a mentés lokális diszken szintén nem teljesen tiszta - a lokális nekem helyire utal. Ha ez így van, akkor viszont ha betalál az istennyila, akkor az éles adat a mentéssel karöltve távozik (legalábbis ez, mert van másik is). Ez szintén nem feltétlenül a best practice.

A másik, hogy ebben a felállásban a bacula nem tűnt jó megoldásnak, az pedig, hogy a kliens lépjen fel a mentő szerverre, szintén nem jó megoldás, mert ekkor nehéz összeszervezni azt, hogy a sokadikként induló kliens ne várjon, ha az előző mentés már lefutott, de még ne induljon el, ha az nem végzett. Ezt a legegyszerűbben úgy lehet megoldani, hogy a mentő szerver ütemezi a mentéseket, ezért első sorba olyan irányba próbáltam mozdulni, amely az eredeti mentési rendszer megtartását tenné lehetővé.

"az sem teljesen perfekt megoldás, hogy az ssh konfig havonta képen van csapva, ha kell, ha nem, ha változott, ha nem" - szerintem meg a compliance oldalon elvárt beállításokat teszik vissza, amit a poszt-toló önkényesen felülír.

"a mentés lokális diszken szintén nem teljesen tiszta - a lokális nekem helyire utal." - A menteni kívánt adatokat, fájlokat egy root joggal futó helyi folyamat, cron job összemásolja egy mondjuk /srv/backup/yyyymmdd.tgz fájlba, amire a backuphu user kap rw jogot, és amit ha készen van a fájl, akkor szépen le lehet onnan húzni. Tehát a mentendő adatok összeszedése helyben megtörténik, majd a pakkot már egy alacsonyabb jogosultsággal bíró user "húzza le" a gépről oda, ahova a mentést rakni szeretné.

Gyakorlatilag a mentendő gépen futó folyamatnak le kell tennie egy "yyyymmdd.keszen.vagyok" fájlt, amikor összelapátolta azokat a dolgokat, amit a mentésbe bele kell rakni, a mentőszerverről meg ennek a fájlnak a létét (meg néhány apróságot...) vizsgálva az elmásoló script gyakorlatilag futhat x percenként cron-ból. (Vane "dolgozunk jelzőfájl? Ha van, kilépünk. itt van-e már a yyyymmdd.keszen.vagyunk fájl? - ha igen, akkor már korábban készen lettünk a másolással, kilépünk. Ha itt nincs, akkor ott van-e már? Ha nincs, akkor kilépünk, mert a túloldal nem végzett. Itt nincs, ott van, kirakunk egy "épp most dolgozunk" jelzőfájlt helyben, aztán elkezdjük áthúzni a mentendő tartalmat, és ha minden átjött, akkor a jelzőfájlt is, majd ha az is sikeresen átjött, akkor takarítunk: előbb a túloldalon, utána pedig a "dolgozunk" jelzőfájlt töröljük helyben.)

Az valóban nem helyes, hogy a posztoló önkényesen felülírja az sshd konfigját - de az mennyivel helyesebb, hogy a másik fél meg havonta visszaállítgatja? Értem én, hogy a "compilance oldalon elvárt beállításokat teszik vissza", de nem lenne jobb egy olyan irány, hogy "Te Bélám, ezzel akkor most mi is van?"? Csak a poszt többi kommentjéből ami lejön, hogy a másik oldal annyira nem partner a probléma megoldásában.

Bár nem vitatom annak a megoldásnak a helyességét, hogy kliens oldalon gyártsuk le a mentést és azt a backup gép csak szipkázza el, (van az az eset, ahol tényleg ez a jó megoldás,) de ebben az esetben gondoljuk át a a következőket is:

  • innen kezdve minimum kell a dupla winyó kapacitás, mert nem elég a hely az érdemi adatoknak, hanem kell még egyszer a hely a backup-ba tett adatoknak. Ez hely pazarlás a mentendő gépen - nem vagyok híve annak, hogy csak emiatt duplázzuk a winyó kapacitást.
    • természetesen ráugrathatunk különböző tömörítő algoritmusokat is, így valóban kevesebb hely is elegendő lesz - cserébe a gép CPU-ját is harapjuk, had izzon a vas. De mondjuk ez legyen munkaidőn kívülre időzítve, akkor legalább az egyéb terhelésekkel nem fog összeveszni.
  • jelen esetben ez a javaslat a gép teljes mentését jelentené, ami az eredeti kéréssel erősen szembe megy, az rsnapshot ugyanis csak a változást hozza át. Nyilván ha van egyetlen tömörítvényünk, akkor azt naponta át kell szipkázni. Az egészet. Ez nem fog menni.
    • azon lehet hezitálni, hogy a helyi teljes mentés helyett helyben is csak a változást állítjuk elő, de ezt a felállást rsnapshot jelleggel összehozni szép kihívást jelentene. Mind kliens, mind szerver oldalon.

"az mennyivel helyesebb, hogy a másik fél meg havonta visszaállítgatja" - a "RootLogin no" beállítás értelmes esetben alap, ergo abból kell kiindulni. Ha a baseline-tól eltérő beállításra van valakinek igénye, azt egyeztesse, indokolja, és kérje, hogy legyen úgy. Ha jóváhagyják, akkor oké, ha nem, akkor meg tessék igazodni az alapvető elvárásokhoz. Egy általánosan elfogadott baseline-nal totálisan szembemenő igény esetén persze nem csoda, ha a túloldal nem "partner", pláne úgy, ha a módosítás nincs egyeztetve velük.

Az otthoni péhápépistikegépe linuxon azt csinál, amit akar, egy céges környezetben meg tessék elfogadni azt, hogy vannak játékszabályok. Igen. root userrel menni könnyebb, ahogy a webes alkalmazásnak is egyszerűbb db owner/full control avagy sys avagy postgres avagy DB-atyaisten joggal az adatbázishoz fordulni - mégsem ezt csináljuk, hanem a hozzáféréseknél a minimálisan szükséges jogokat adjuk meg. Igen, a /etc mentéséhez elég egy backuphu user, ami kiadhat egy tar cf - /etc parancsot root-ként, aminek a kimenetét már sima userként kapja meg.

Egyébként meg nem kell mindenből is helyben másolatot csinálni, csak azokról a fájlokról/könyvtárakról, amikre nincs általában olvasási jog, és nem célszerű/nem lehet még ACL-lel sem ezt megvalósítani. A /etc könyvtár tartalma például ilyen, ott nem szórakoznék acl-ezéssel, de pl. a postgres esetén a data könyvtár is olyan, hogy annak a pg-t futttaó user tulajdonában kell lennie, és másnak nem lehet rajta semmilyen joga (0700), mert egyébként nem fog elindulni...

egy idő után mindenképp kelleni fog full backup is

akkor ez kilőve, az első full rsync mentés tartott kb 6-7 napig, a napi különbözeti mentés is kb 4-5 órán keresztül fut.

Az ötleteid működhetnek, de az IT SEC. csoportnál lebuknánk, és az nem hiányzik senkinek.

Full backup? Az meg mi a töcsnek? Csomaglista, /etc meg az alkalmazások adatai, illetve igény szerint a /home mentése, oszt' jónapot. Ha egy reinstall nem fér bele időben, akkor remélhetőleg virtuális gép, amit veeam-mel mentsenek le rendszeresen, és azt a mentést rakják el.

A full backup az én szóhasználatomban az adatok első szinkronizálását jelentette. A szerverek virtuálisak, azokat az IBM menti valamivel, de én nem bízok bennük, ezért csináltam egy független mentést. tehát nem mentek az OS-ből semmit, max a /etc-t. Az a hosszútávú cél, hogy minden beállítást, telepítést ansible-playbookal oldjak meg, ez már folyamatban van kb 1,5 éve, de bőven van még hátra teendő.

"én nem bízok bennük" - ők meg benned, illetve abban nem bíznak, hogy a közös ló root userrel bemászva mit alkot egy ismeretlen személy(!) arrafelé. A "root" technikai user ugyanis nem köthető személyhez, így ha azzalé valami katyvaszt csinál bárki is, explicit felelőst nem biztos, hogy lehet találni. Sőt. Saját nevesített userrel login, sudo-val amit kell, megcsinál, aztán jónapot, mentésre meg egy korlátozott user, ami acl-lel megkapja a mentendő tartalmakra az olvasási jogot. Egy ilyen megoldásba sem a túloldal, sem semelyik auditor nem igazán fog tudni belekötni.

( zeller | 2021. 01. 02., szo – 17:18 )

A root-tal történő remote login még kulcsos auth esetén is a "bzmg" kategória. Nem, az UID=0, de más a neve nem megoldás, hanem egy iszonyat ronda gányolás.

Amit lehetne csinálni, az annyi, hogy a mentendő tartalomhoz acl-lel read jogot adni egy backup usernek, és ezzel a backup user (akár rssh default shell-lel) végezné a mentést.

( zeller | 2021. 01. 02., szo – 17:33 )

"Ám úgy tapasztaltam, hogy mindent egy fájlba ment, ami nekem nem jó, mert jobb szeretem, ha látom a fájlokat. Könnyebb kikeresni őket visszatöltéskor." - Igen, a bareos/bacula saját fájlt használ, meg DB-t, amibe belerakja, hogy mit, mikor, hova pakolt el :-) Viszont ezeket a fájlokat bextract-tal kicsomagolhatod, és utána úgy és oda mented a tartalmát, ahova akarod - havi archiválásnál én is ezzel mókolok: utoló bacula mentés (napi/heti/stb rotálás x darab fájllal) megfog, bextract -v /itt/van/a/fajl /ide/csomagold/ki/ és már az utóbbi könyvtárból lehet is archiv szalagra küldeni a mentés tartalmát.
 

( msandor v | 2021. 01. 02., szo – 19:08 )

Bevallom, kellemesen csalódtam, nem vártam ennyi hozzászólást egy covid és politika mentes topicban :-)