Fórumok
Sziasztok,
Remélem nem inditok ezzel vitát, de szeretném kikérni a véleményeteket.
Mentési megoldásra mit használtok vagy használnátok az alábbi adatok ismeretében?
- 70-nél több Szerver
- Mind Ubuntu Linux VPS
- Minden szerveren található minimum 1 de valahol több Weboldal, és persze Mysql
- Egyes szervereken PGSQL vagy MongoDB is van
- Full és Incrementál mentés is kell
- Jó lenne valamilyen felületen látni, hogy sikeres-e és lefutott-e a mentés vagy elakadt
- Küldjön EMail-t ha gond van
- Nem baj ha fizetős, csak ne legyen Horror ára :D
- Ha lehet SSH vagy FTP-t használjon, nem szívesen teszek fel Agent-et csak ha nagyon nincs más
Jelenleg saját scriptekkel mentek de már nagyon-nagyon terhes a kezelése és átlátása... :(
Hozzászólások
en egy ideje ezt: https://borgbackup.readthedocs.io/en/stable/
egyszerre full es incrementalis, mivel deduplikalas elven mukodik (mindig fullt csinal de csak azt kuldi/tarolja el ami meg nincs meg)
remlik lattam mar hozza valahol guit de en sajat scriptbol hivom, es az email reportot is az kuldi.
Ajajj, ebből megint végeláthatatlan lista lesz :)
Én hasonló környezetben a backuppc-t használom. Mindenhol van egy /backup ami alá a konténerek a mentést teszik és egy /márnemtudodmmi ahol az "állandó" adatok vannak.
Persze menteni könnyű, helyreállítani nehéz, szóval szerintem semmiképp nem úszod meg legalább 2-3 megoldás kipróbálását, így jobban jársz ha egy LLM-et kérdezel, az 20 másodperc alatt válaszol, és több időd marad a kipróbálásra.
Az agent miért gond? 70 gépről már gondolom van valami leltár, egy Ansible vagy akármi simán kirakja neked, amit kell.
Igazából ha kell, hát kell. Ezért írtam ezt:
"nem szívesen teszek fel Agent-et csak ha nagyon nincs más"
Tehát ha valaki javasol egy jó megoldást, és Agent kell hozzá, hát legyen :)
Nekem ez fájl szintű mentési igénynek tűnik, és a kiírt feltételek miatt én a Bacula-ra szavazok.
Kliens ugyan kell a mentendő gépekre, de minden disztróban (így az Ubuntuban is) van valamilyen verziójú elérhető (annyi a lényeg, hogy a szerver és a storage daemonnál lehetőleg ne legyen újabb a kliens), nem kell egyedi tárolóból feltenni. Szerver oldalon kell mindent konfigurálni, klienseken semmit a kezdeti kapcsolatfelvétel után. Bármire tud menteni, mindenről értesít, és van hozzá való, jól átlátható webes felület is mostanra. Tömöríteni tud, inkrementális mentést is nyilván (akár nagy állományok esetén rész-mentéssel), deduplikálás ugyan van, de én azt sehol nem használom benne. Nagyon gyors, kis erőforrás igényű a kliens is, szerver is. Open source, használhatod ingyen üzleti célra, vagy vehetsz támogatott verziót is akár, amiben plusz extra fícsörök is vannak (amik szerintem itt egyáltalán nem kellenek).
Az adatbázisok konzisztens mentését meg tudod oldani szerver oldalról konfigurált, a kliensen mentéskor lefutó parancsokkal (így nem lesz olyan, hogy a DB mentés még nem futott le, mikor a file mentés menne), és ezek eredményétől függően akár a mentést lehet sikertelennek is minősíteni (nehogy minden meglegyen csak konzinsztens DB nem). Ezekről is értesít.
Én kb. 20 éve használom különböző helyeken, sohasem hibázott. Van, ahol sok gépet kevés adattal, van ahol kevés gépet, de több millió állománnyal, több TB adatmennyiséggel ment.
Bacula vs BAreos
Nem követtem pontosan az eseményeket,de annó pár(sok) éve ment a vihar a biliben és leforkolták a Bacula-t.
ez a Bareos álláspontja :
https://docs.bareos.org/IntroductionAndTutorial/WhatIsBareos.html#histo…
Melyikkel érdemes indulni?
Az az igazság, hogy én már aktívan használtam a Bacula-t, amikor ez a fork történt, és nem követtem a Bareos fejlődését, mert a Bacula mindent tudott a community verzióban, amire szükségünk volt (ez azóta sem változott, mert nem változtak az igények, ahol ezt használjuk...). Az tény, hogy a Bacula eredeti írója durván a kezében tartja az egészet, és végig érezni lehetett erősen az üzletközpontúságot annak ellenére, hogy a legtöbb tömegigény elérhető volt a community verzióban. Pl. sokáig csak díj ellenében lehetett Windows-ra bináris klienst használni, mert zárt forrású volt, lefordítani sem lehetett magunknak. Ez azóta változott, de nyilván nem jó ómen az ilyen szintű kontroll lehetősége.
Akkoriban a Bacula fejlesztőjének írásaiból az jött le, hogy a gonoszok ellopták a melóját, mert nem értettek egyet azzal, hogy szerinte merre kell menni a projektnek. Aztán eltelt röpke 20 év, és én egészen máshogy látom a forkolást azóta, és látom, hogy több projektnél előfordul az, hogy open source, de mégsem nyílt, mert egy személy vagy szervezet dönt mindenről, és megértem, akinek ez nem felel meg (pláne, ha ilyen sokaknak nem). És a forkolás sem bűn, ahogy azt egyesek beállítják, hisz bárkinek szíve-joga, és aki nyílt forrásúvá teszi a projektjét, annak ezt el kell fogadnia szó nélkül, hisz a nyíltság és a szabadság az egész lényege.
Most elolvasva egy független de nem elfogulatlan írást a témáról, én azt mondanám, érdemesebb a Bareos-t kezdeni annak, aki még új a Bacula/Bareos vonalon, mert nyíltabb a fejlesztése, mint a Bacula-nak. A Bareos szintén mindenhol elérhető official repo-ból egyébként. A szituáció hasonló, mint a pfSense->OPNsense és az írásban említett ownCloud->Nextcloud esetében volt. Ez utóbbi kettőt átéltem, és váltottam is mindkét esetben, nyilván új telepítésnél a Bareos-t venném elő inkább ezután, mégha bele is kell rázódni a Bacula után.
Normalis management UI nehezen lesz agent nelkul. Raadasul a kulonbozo adatbazisokat mashogy kell menteni, amihez altalaban megint agentjei vannak a legtobb termeknek.
Kulonben ugyanott leszel, mint most, hogy neked kell scriptelgetned, hogy ujra elinduljon a mentes ha valami otrtenik, mikor induljon el, hogyan.
A server-agent topologia ebben az esetben nem urdungtu-valo am. A serveren manageled az egenteket, ok meg majd csinaljak a dolgukat es szepen mindenrol ertesitik a servert. Raadasul ezek legtobb esetben TLS-en kommunikalnak, szoval a titkositas is megvan. Vagy miert kell az SSH egy menteshez? Mire hasznalnad a mentyes soran az SSH protokollt?
Proxmox backup szervernek adnék egy esélyt. Igaz még DB-t pl. nem tud, de minden mást igen. Igaz ugyan h. kell hozzá agent, de azt egyik olyan megoldásnál sem úszod ami kicsit is fejlettebb az rsnapshotnál. Cserébe nem sshzol a mentő szerverről rootként pl, ami azért nem biztos h. baj.
nem kell ssh... lehet readonly rsync daemon is over wireguard
Ez mondjuk teny, de ehhez minden node-odon dolgozni kell. Plusz nincs a mentesed titkositva egy szakaszon. Meg titkositva tarolva, stbstb
már említették, hogy ansible
melyik szakaszon? ha zavar, minden node-ra teszel wg-t
zfs encryption?
Ez mind tök jogos, csak kényelmi szempontból egy agent ami mindent tud azért jobb szerintem. Teszem hozzá h. használok én is olyat, amit írsz h. zfs-re mentek rsnapshottal (igaz nem wg, az még egy plusz sz.pókör lenne)
Mindent lehet, kérdés mennyi időd van és az időd mennyibe kerül. Ha többe mint megvenni egy jó megoldást, akkor nem biztos h. megéri megcsinálni azért mert cool.
igen. ssh-nak hívják és linuxokon fent szokott lenni alapból :P... és, ahogy már fennebb elhangzott, ansible könnyen tudja matatni a 70 hostot.
a rsnapshot hard linkekkel készít "snapshotot"... akkor meg minek neked a zfs? cow filerendszeren rsnapshotot használni szerintem hülyeség
szerk: amúgy meg nem kell wg, ha jó az ssh... és azt a backup juzert le lehet limitálni egy folderre (ahova pl. fel van mountolva a root fs readonly módban)
azt mondod tehat hogy az SSH egy backup megoldas amivel pontosan lathatom egy dashboardon, hogy mikor eppen milyen mentes tortenik es azok eppen milyen allapotban vannak, sot akar megallithatom kozben vagy ujraindithatom, vagy utasithatom, hogy ha a mentes nem sikerult, akkor 3 alkalommal kiserelje meg ujra a mentest mindegyik idointervallumot duplazva. Ezen kivul kivalaszthatom egy korabbi mentesemet, hogy azt visszallithassam akar egy masik gepre is? Ezen kivul shceduling van benne meg manualis inditasi lehetoseg, de ha eppen manualisan rainditok de fut egy scheduled, akkor azt megvarja vagy eldobja a manualisat a beallitastol fuggoen?
(igen, tudom hogy az nem az, csak erdeklodtem :D )
off/flame/stb.: nem, amit te írsz az az ansible :)
Viccet félretéve, ezekre gondoltam én is agent alatt, csak máshonnan közelítjük meg az egész kérdést, így igazából almát hasonlítunk körtével. A backup egy dolog, de pl. az ilyen lemásolom, megvan helyzeteknél hogy néz ki egy visszaállítási teszt? Ugye amit írsz az pont fontos, mert _másik_ gépre vissza tudod állítani egy értelmesebb megoldással. (igen, tudom másik gépre is lehet sshzni, meg ansibleözni, meg minden és mindent meg lehet erőszakoskodni h. úgy nézzen ki mint egy ló, még a kutyát is)
Egy olyan infrastrukturaban ahol a szolgaltatasok helye valtozik (jo nem az RDBMS-eke), ott eleg nehez ansible-el menteni amiben le van irva hol kell a mit csinalni. Igen meg lehet csinalni ansiblel-el is, kurva sok programozast igenyelne. Lekered hol milyen szervizek vannak, aztan a dict alapjan atmozgatod a cornjobokat es remenykedsz, hogy ne fusson eppen mar egy backup, ami ujbol elindul meg a masik alatt. Stb stb.
Kicsiben persze es statikusan minden menni fog ansible + ssh + cron+ bascript-ekkel, ha a dashboardot is leszarod.
Amugy meg (amikor meg uzemeltetessel foglalkoztam) egy full entes utan visszaallitasi tesztet vegeztunk automatikusan egy short-lived kornyezeten amin aztan megfutnak az autotesztelok altal irt folyamatok. Sot ezt releasek kozott is megcsinaltuk regebben, amikor meg DevOPS-kent is mukdotem :D
Nem csak az visszatoltes a lenyeg, hanem hogy az adat tenylegesen jol lett e visszatoltve. Rhhez meg tesztek kellenek.
én az agentre írtam az SSH-t.
amúgy meg, amiket leírtál, azokat a sima bash szkriptjeim mind tudják. Schedulingre meg ott van a cron és a szkriptben van flock. Inkrementális, mert COW fs snapshotokat használ, enkriptálva van. Ha baj van, szól pushoveren. Pont nem érdekel a dashboard.
Ok, akkor most kepzeld el, hogy van 100+ masinad. Amin mind managelned kell a cron-t, a backup scriptjeidet stb. Oke, ha van eleg idod megcsinalod. Ok nem erdekel a dashboard, mert a scripjeid eppen aktualis allapotat lekerdezed valahogy (ansible). Na de mi van ha a mentes mar 38 oraja fut es maskor csak 7 percig futott. A scripted ezt is kiirja? Osszahasinlitja? Ehhez kell egy monitoring is, meg mondjuk egy ML, meg minden istennyila is.
Te azt mondod, hogy tengernyi idovel rendelkezel, hogy Te mindezt kifejleszd. Sot, ha a szervereken nem fixen futnak az adott alkalmazasok, hanem ugy, hogy eppen ott induklnak ahol van eleg eroforras, akkor a Te mentesi scriptjeid pontosan tudni fogjak, hova migralodjanak reggel, majd mozogjanak at este, mikor az adott szolgaltatas mar mashol talalhato. Vagy lehet megoldod ezt is ansible-el (igen siman meglehet). De mondjuk egy dashboard-on egy klikk, vagy dynamikus agent-tel, ami bezony felismeri mifasz fut hol) egy igazi backup megoldas rohogve megoldja. Nem azt latom hogy melyik gepen mi fut (mentes szempontjabol irrelevans), hanem hogy a mentesek allapota milyen.
Az SSH egy atviteli csatorna, nem pedig backup megoldas. A backup megoldas a scriptjeid, a cron, a montiroing stb. Ezt egy mentesi megoldas egyben szallitja neked, plusz nehany featurrel ami kenyelmesebbe teszi az eletedet. Nem azt mondtam hogy ez mindnekinek kell. De ne talaljuk mar ki, hogy a ketto ugyanaz sot a kezzel vagy ansibellel managelt scripthalmaz ugyanazt nyujtja. A jelenlegi megoldas neked tokeletes es jo ez igy. Nincs szukseged masra, azokra amiket irtam. Azert probald most meg elkepzelni, hogy nem 100 hanem mondjuk 4000+ objektumot kezelsz. Nem csak szerverekrol beszelek, hanem pluszban szervizekrol, alkalmazasokrol, stb stb ahol nem fix sem az infrastruktura sem pedig a szolgaltatasok helye.
es ugye neha vedeni kell a hatsodat is, mert ha baj van es kiderul hogy a backup hibas valamiert, akkor te leszel az oka, nem tudod atharitani a felelosseget a backup szoftvert gyartojara (nem mintha ok vallalnanak felelosseget, de az mar legyen az ugyfel gondja)
"csak kényelmi szempontból egy agent ami mindent tud azért jobb szerintem"
És van olyan? Mert amit ajánlottál, az pont nem tudja amit kell.
megjegyezném, hogy a mysql-t vagy pl. innobackupex-szel mented vagy kell egy helyi filesystem snapshot, esetleg megállítod a backup idejére. másképp simán korruptálódhat az innodb.
nincs semmi baj a saját szkripttel, ha jól működik... rsync over ssh rulez...
én zfs/btrfs-re szoktam backupolni, ezt, mint inkrementális backup, nehéz überelni...
Innobackupex v mariabackup +1
Myisam ha akad akkor meg lvm es mylvmbackup.
mysqldump nem jo? mondjuk ha nagy (sok gigas) a db es lassu alatta a disk akkor azert eltarthat egy par percig, mondjuk hajnalban kibirjak :)
de van ahol van master-slave mysql replikacio, ott a slave-en csinalom a mentest (plusz monitorozva van a replikacio is)
A mariabackup/innobackupex innodb esetében nagyon hasznos cucc, sokkal jobb mint egy dump. Eleve non-blocking. Azon túl tudsz inkrementális mentést csinálni.
Ott ahol mondjuk 2-3-400G a DB ott azért ez tud számítani.
A lehlenyegesebbet nem írtad le, mekkora adat?
Olyan 800GB.
Az nem olyan sok. Mekkora a legnagyobb db? Mennyi idő alatt alarsz visszaállítani? Mi baj konkrétan a jelenlegivel?
Valószínűleg legjobban a custom scriptekkel jarsz IMO. Ha nem, akkor ott van a Burp, Borg v cezekhez vmi wrapper. pl. https://torsion.org/borgmatic/docs/how-to/backup-your-databases/ .
Miért vps és nem saját infra?
A Borg, Burp, Restic, Kopia mind nagyon szuper, de mindnek a baja az, hogy a kliensen állítasz be mindent. 70 kliensnél 70-en... Ha módosítani akarsz, 70-en. Ha visszatöltési teszt van, 70-en...
Tudom, hogy nagyon népszerűek, mert pillanatok alatt feltehető és használatba vehető, meg persze Ansible-lel is lehet konfigurálni távolról. De amikor van több, bevált, jól működő, teljesen szerver oldalon (egy helyen, template-ezve) kényelmesen konfigurálható és felügyelhető mentési rendszer, akkor miért kellene újra kézzel több komponensből összelegózni?
Tényleg jó az rsync, rclone, rsnapshot. ZFS-re vagy btrfs-re küldve van kényelmes tömösítés meg kvázi-readonly előző verziók. Meg ezek kombinációja sima script-ekkel. De szerintem nem puhap@cs, aki nem áll neki megírni, tesztelni, debug-olni, hanem használ egy kész megoldást.
Ezt a commentet vajon minek küldted be? Amennyire szét van esve, talán még csak nem is józanul. Ha igen. akkor viszont szuper lenne, ha leírnád.
???
Nem józanul? Ezt a pár félre ütött betűből gondolod, vagy egyesen nem értelmes, nem magyar mondatokat írtam?
Melyik része van szétesve? Írtam, hogy a kliens oldali mentések sajna kliens oldaliak, egyesével kell menedzselni, és szkriptekkel összefogni, pont ez nem kell OP-nak. A tisztán szkriptes rsync és társai FS szintű tömörítéssel, meg "deduplikálással" szintén szkriptelősek, pont ez nem kell OP-nak.
Arra válaszoltam bővebben kifejtve, hogy az OP nem szeretne a 70 gépén a továbbiakban szkriptekkel bajlódni, valami könnyen menedzselhető, könnyen felügyelhető mentést szeretne. Erre sokan bekommentelik - köztük Te is -, hogy a tisztán szkriptekkel működő, vagy a gépenként telepítendő, beállítandó, majd szkriptekkel összefogott mentés neki a legjobb választás a 70 gép esetén...
De akkor átrendezem és kiegészítem, hátha másodszorra sikerül nem szétesettet írnom:
vs.
Amire ez a válaszom:
Tényleg jó az rsync, rclone, rsnapshot. ZFS-re vagy btrfs-re küldve van kényelmes tömörítés meg kvázi-readonly előző verziók. Meg ezek kombinációja sima script-ekkel. De szerintem nem puhap@cs, aki nem áll neki megírni, tesztelni, debug-olni szkripteket, hanem használ egy kész megoldást.
A Borg, Burp, Restic, Kopia mind nagyon szuper, de mindnek a baja az, hogy a kliensen állítasz be mindent. 70 kliensnél 70-en... Ha módosítani akarsz, 70-en... Ha visszatöltési teszt van, 70-en...
OP-nak egy szerver-agent típusú mentés kell az igényei alapján (azokból csak az agentless nem valósul így meg), központi felügyelettel, értesítésekkel, áttekinthető státuszlappal. Ilyenek a Bacula, Bareos, Veeam, Amanda, Zmanda, UrBackup, BackupPC
Az Ansible ott jöhet képbe, hogy azzal könnyen fel tudja tenni és konfigurálhatja a mentéshez tartozó agent-et. Egyszer, utána elfelejti. Onnantól a szerveren állít be és ellenőriz, monitoroz mindent.
A szkriptek meg ott maradnak meg, hogy DB specifikus parancsot ír (a mentő szerver konfigba) a különböző DB-k konzisztens mentésére, ami a mentéssel együtt, az előtt, felügyelten lefut.
Kiemeléném a BackupPC-t, ami agentless, és mentőszerver oldalról pull működésű, Linux kliens esetén SSH-n keresztül, SMB-n keresztül vagy rsync-el tud menteni, központi dashboard van, értesíteni is tud. Én nem használtam még, de pont annak tűnik, amit OP keres. Nem kell szkriptelni...
Haladok visszafelé.
Én hasznaltam a backuppc-t ugy 2010 környékén. Működött, épp webszervereket meg ilyesmit mentett. Aztan egy ido utan annyi apró szar volt benne, h aggasztóan lassú volt és végül már egymásra futottak a mentések, meg a cleanup és ott már szánalmas volt. Nem mondom, h nem ajánlom, de legyen vilagos, h vannak/voltak nem túl magas korlátai. Azóta lehet fejlődött. Rémlik, h snapshotot (régebbi mentést) az FS-en nem tudtal megnézni, csak a backuppc tudta összeállítani.
> OP-nak egy szerver-agent típusú mentés kell az igényei alapján
Ahogy a mondat második felében magad is leírod, nem.
> A Borg, Burp, Restic, Kopia mind nagyon szuper, de mindnek a baja az, hogy a kliensen állítasz be mindent. 70 kliensnél 70-en...
So what? Később meg azt írod, h Ansible-vel tolja ki az agenteket. Az épp ugyanez pepitában. Megírja a configot a szerveren és kitolja a központi helyről. Tessék, központi vezérlés. Ahogy te is írod korábban.
A custom script ellenes commented nem értem, ajánlottam customot es nem olyat is.
Amúgy ennyi erővel hasznalhat dirvish-t v. zrb-t is. A lényeg nem azon van, h script v. nem, se azon, h custom v. nem (mert vki akkor is írta). Hanem azon, megfelelő-e számára, azaz kielégítő az eredménye, bízik-e benne, SPOF lesz-e ő a használatával, megfelelően tud-e visszaállítani és még lehet párezer másik feltétel, amiket neki muszáj számba venni. Szinte tuti, h vhol kompromisszumos megoldást fog alkalmazni, így nem értem, miért kiabálsz ezek ellen, pláne úgy, h te is olyat ajánlottál.
Az, hogy Ansible egyszeri futással felteszek egy agent-et, default konfiggal, amiben egy név meg egy password a változó mindössze, meg aközött, hogy Ansible-lel felteszek egy agent-et, majd minden változtatási igényemnél az összesen ugyan ugyan így Ansible-lel átparaméterezem, az nem ugyan az.
Ahogy a szerver oldalon írt egyetlen job template igény szerinti módosítása, majd alkalmazása sem ugyan az a meló és hibalehetőség szint, mint Ansible-vel konfigot teríteni.
Pont ezek miatt én a Bacula-t ajánlottam. Enterprise szintű megvalósítás, rettentő kevés hibával, mindent tud, amit kért OP. Kivéve agentless. De az eddigiek alapján agentless nincs olyan megoldás, ami minden más kritáriumnak megfelel, megbízható, és nem kézzel kell összerakni.
De újra leírom, hogy nem vitázni szerettem volna senkivel, csak rávilágítani, hogy OP kifejezett és elsődleges szándéka volt, hogy a szkripteléstől szabadulna, erre mindenki a szkriptelést variálta szét, mint javasolt megoldást.
Nagyszerű, levezetted, h maguktól nem működnek a dolgok:)
Az OP azon igényét fejezte ki, h nem akar custom scriptelni, mások (ismétlem, köztük te) pedig kifejezték, h kisebb v. nagyobb mértékben ez lényegében megkerülhetetlen, része a munkának.
Backuppc ma :)
~200G, ami tömörítés és dedup után ~30G. A max. az 400/165 volt, az éves stat alapján.
Szóval én elégedett vagyok vele, szögegyszerű (mint én). Aztán... bármikor elhiszem, hogy nem elég, én ehhez igazítottam a környezetet (persistent data, binlog, mifene), mert megtehettem. Ahol ez nem lehetséges, ott nem lesz jó.
Aztán, a teljesség igénye nélkül:
Recent Email Summary (Reverse time order)
A kutyma az a steamdeck, arról is mentek, egy ideje nem volt bekapcsolva.
Szóval... vállalva hogy csőlátásom van: még mindig ez a legjobb(*) :D
*) Igazság szerint anno, amikor elkezdtem használni (szintén olyan 10+ éve), akkor azért bukkantam rá, mert olyan megoldást kerestem, ami a roadwarriorjaink laptopját "azonnal" lementi, ahogy azok csatlakoznak a céges hálózathoz. Mivelháthogy általában nem, de amikor igen, akkor fontos volt, hogy azonnal legyen mentve. Aztán később persze vpn meg minden, már nem lett annyira fontos elvárás, de megmaradtam ennél.
70 szerver, 800G adat - ezek még nem túl nagy számok, simán működhetnek az egyszerű módszerek.
Ha van központi hozzáférésed, egy lehetséges megoldás csinálni egy pull backup szervert, rajta egy compressed btrfs kötettel, pl. /mnt/backup. Egy ezen belüli subvolume-ba (pl. ./mirror) rendszeresen átrsynceled a szerverekről a filerendszereket, ssh tunnelen át SQL dump bele szintén a mirrorba.
A btrfs köteten minden mentés után menjen egy snapshot a /mirror subvolume-ról, így megvan akkor visszamenőleg minden mentés pillanatfelvétele, simán a filerendszerben hozzáférsz a snapshotokhoz. Nem igazi deduplikációs / inkrementális mentés, de a CoW miatt az érzés (és a helyfoglalás) hasonló. Pl.
Ezekből lehet archiválni (szalagra, cloudba), a szokásos 3-2-1. Bizonyos idő után a régi snapshotokat eldobálhatod.
Ha jól értem, akkor ~ ez az, amit csinál, és ez az, amit nem akar.
Még egy ötlet: email értesítés helyett lehet használni a ntfy.sh szolgáltatást push üzenet küldésére. Némi korlátozással az ingyenes is elég, még regisztrálni sem kell. Választasz egy egyedi topic nevet, adminok feliratkoznak rá a mobilos appból, az értesítést pedig küldheted a scriptből, ha valamelyik mentés nem sikerül:
itt a free csomagban mi van? a weboldalukon nem talalom...
en ezer eve a pushover-t hasznalom, ott 10k uzit irnak havonta, az mindenre is eleg :)
A'rpi
A pushover is nagyon jó. Kb. ez a nagyságrend itt is, 250 üzenet / nap / topic.
https://docs.ntfy.sh/publish/?h=limit#limitations
Free:
Publishing messages can be done via PUT or POST. Topics are created on the fly by subscribing or publishing to them. If you use ntfy without sign-up, the topic is essentially a password, so pick something that's not easily guessable. If you purchase ntfy Pro, you can reserve topic names instead.
https://ntfy.sh/#features
Klasszikus monitorozás esetén kb. egyértelmű, h mit nyer vele, de a backup esetén minek?
Tipikusan olyan téma, ami várhat másnap reggelig.
Van, ahol éles backup -> uat/hibakeresési/jelentéskészítő/stb. környezet restore a folyamat, ott nem biztos, hogy jó, ha csak NBD reggel derül ki, hogy szahara van a palacsintában.
Ezt leírnád pls, mert nem eértem, lehet.
Az viszont tuti, h itt irreleváns amúgy.