backup megoldások 2022

Közösségi kerekasztal

Sziasztok!

rsnapshottal mentek 3 (KKV-jellegű) fizikai szervert, vagyis bizonyos könyvtárakat egy 4. vasra raid1 kötetre, illetve onnan időnként áttolom egy NAS-ra NFS megosztáson keresztül.

Agyaltam rajta kicsit, hogy ez az egész jó-e így, nem lehetne-e jobban, szebben, optimálisabban, más toollal (borg pl. ígéretesnek tűnik)... Nyilván egzakt jó megoldás nincs, de kíváncsi vagyok a véleményetekre, ti hogy oldjátok meg az ilyen jellegű feladatot?

üdv,

donatus

( andrej_ v | 2022. 11. 27., v – 22:46 )

Ha Windows Hyper-V vagy VMWare alapúak, akkor Veeam. Veeam-ből van agent Linuxra is, és ingyenes, de hogy mennyire áll kézre az más dolog, mert ők eléggé a Windows világból érkeznek.

Ha linuxod van, akkor sokkal jobbat nem fogsz elérni a fentinél, mást valszin igen. Ami fontos, hogy a malware kódolás ellen legyél védve, a felülírás ellen valahogy védekezz, azaz elsőre legyen erősen szeparált a backupra használt hálózat, és IP-re korlátozva az elérése. Egy-egy időszakos külső diszkre mentés roppant hasznos (nem felülírva, hanem dátumozva odapakolni), és semmi extra nem kell.

( Carter | 2022. 11. 27., v – 23:38 )

a duplicati annyira hasznos szerintem, hogy kár lenne kihagyni.

https://www.duplicati.com/

Az online ne tévesszen meg a reklámban, tud egy rakás helyre menteni, local drive-ba, vagy ftp-vel helyi hálón, vagy .. hát kb. bármi:)

( gabrielakos v | 2022. 11. 28., h – 01:42 )

urbackup illetve restic. urbackup a windowsoknak, helyben.

restic a linuxoknak, előnye hogy egyből képes titkosítottan s3-ba menteni (backblaze b2)

illetve a synology-nak is van egy activebackup nevű cucca, az is ment s3-ba.

Gábriel Ákos

Itt meg szeretném jegyezni, hogy a Synology ABB-vel nekem már voltak/vannak gondjaim, miszerint nem minden Windows-os gépen sikerül a VSS alapú mentés, ráaádsul nem feltétlen ugyan úgy nem sikerül. Az összes létező Syno és más által javasolt dolog leellenőrzése után sem lett megoldás (minden jól működik a mentendő gépeken, minden teszt a várt eredmény adja).

Sajna semmilyen Syno supporttal nem jutottam előrébb, és aránylag sok ilyen tartalmú netes fórumtéma és Syno nyitott hibajegy van. Én ki is vezetem az ABB-t onnan, ahová bevezettük (volna).

Ugyan ez a probléma simán fennállhat bármi más, Windows VSS-re építő mentési rendszernél sajna (ha logikusan átgondolja az ember).

Mi már a második vss mentésen alapuló rendszerünket koptatjuk, a vss a hibás. A megoldás a backupok időbeni eltolása illetve a fileszervereken a filehistory kikapcsolása valamint a linux szerverekről standard checkpoint kell nem production, mert néha jó néha nem (és semmi értelmes nem látszik a logokban).

( vudumancs | 2022. 11. 28., h – 09:59 )

+1 az urbackup-nak.

Ha van elég budget akkor +1 a veeam-nek.

Szijártó Zoltán
Aki tud az alkot, aki nem tud az csak szövegel.

Van benne néhány komolyabb feature, ami nincs, vagy csak részleges, de rendkívül jól használható. Emitt a lista: https://www.veeam.com/products-edition-comparison.html (ami nincs, azért ott nézd meg, hogy mi az, egyáltalán nem a napi szinten szükséges történet)

Szerk: Annyit javítok, hogy nem pont backup job a 10db limit, hanem az automatizált. Ha van egy replikációd, akkor az is levon belőle.

( kruska v | 2022. 11. 28., h – 10:47 )

Ami nálam bevált fileszervereknél:

1. Pull típusú mentés: a mentendő hostok nem érik el a backup szervert (sem megosztáson, sem SSH kapcsolaton keresztül), csak fordítva; így ha kompromittálódik a szerver, a backup biztonságban van. Akár azon az áron is, hogy a backup szerveren kell foglalni egy mirror területet, ahová folyamatosan szinkronizálódik a mentendő adat, és onnan kerül le mentésbe.

2. Deduplikáció: a mirror területet mentve bekerül egy borg repo-ba. Ha az adatmennyiség túl nagy, és szűk a backup window, akkor előfordul hogy a borg-os megoldás helyett btrfs-re teszem a mirrort, és rendszeres automatikus snapshotok készülnek.

3. Online backup: a borg repo szinkronizálódik valami cloud-os helyre (borg-nál egyszerű elkülöníteni a repo új filejait), a btrfs snapshotok pedig egy másik adatközpontba.

4. Offline backup: heti/napi 1x a borg repo vagy a btrfs snapshotok kikerülnek szalagra.

 

Adatbázismentésnél kicsit más a felállás.

( Fisher v | 2022. 11. 28., h – 12:07 )

Nha, hogy okoskodjak: a mentéssel az a "baj", hogy az adott környezethez kell(ene) szabni. Szóval ami az egyiknek tökéletes, az a másiknak lehet hogy öngyilkosság.

"Nálam", azaz egy régebbi munkahelyemen a backuppc nagyon bevált pl. arra, hogy amikor vagy vpn-en, vagy úgy, hogy behozzák az irodába és előkerül a laptop, akkor azonnal lementi, HA x napja nem volt mentve.

A mai napig is ezt használom a saját cuccaim mentésére. A backuppc repót (is) meg a borg menti egy külső diskre. Annyi okosság van benne, hogy ha fut a BackupPC_dump, akkor a borg vár, míg az le nem áll, így van esély, hogy konzisztens mentést csinál. (Ezen mondjuk még bőven lehetne csiszolni.)

( ggallo | 2022. 11. 28., h – 12:09 )

Nekem file szintű mentésre a Bacula vált be, elképesztő futásidők után is hibátlanul működik, bármennyi file és adatmennyéség esetén. Kb. 15 éve használom különböző cégeknél, különböző adatmennyiségekre. Van hozzá webes tool a felügyelethez és a kényelmes visszaállításhoz. Tény, hogy a deduplikáció messze nem olyan jó benne, mint a chunk alapú mentési megoldásoknál, de ahol én használom, 1-2 TB adatig teljesen kordában tartható a backup tárterület költsége egy számunkra elfogadható 3 hónapos megőrzési idő mellett.
A Bacula mentései saját magával is replikálhatóak több módon más (offsite) tárolóra, és "hibrid" megoldással gyakorlatilag bárhová tud dolgozni.

Virtualizálásra pedig kizárólag Proxmox VE-t használunk egy ideje, és ezt a Proxmox Backp Server-rel mentjük. Ennek parádésaj jó az inkrementélis mentése és a deduplikációja. A PBS tárolói pedig máshol futó PBS-re nagyon hatékonyan replikálhatóak, valamint szalagos mentést is támogat (ami szerintem egy jogtalanul feledésbe merülő dolog manapság).

( bujdi | 2022. 11. 28., h – 13:07 )

Igaz, hogy én csak gombfocizok (~3,5T az össz forrás méret), de borg + borgmatic megy nálam kb 7 éve hibamentesen (havi integritás ellenőrzéssel stb.). A visszaállítással sem volt eddig gond. 

( szabek | 2022. 11. 29., k – 11:53 )

Én rdiff-backup-ot használom, ha csak file-okat kell mentenem. És veeam, ha vm-et.

Burp egy nagyon jó backup megoldást!
Kb. mindent tud amire szükség van, burp-ui-val kiegészítve "kattingatósan" is működik.

Kliens oldalon egy pár Mb-os app települ csak, az sem fut folyamatosan, hanem megadott időközönként nézi meg hogy kell-e mentenie.
Akár nyílt közegben (internet) is használható, teljesen (SSL kulcs alapú) titkosított a forgalom.

Minimális erőforrás igény, megbízható.
És bármire felrakható!

Köszi ezt a tippet! Sose hallottam róla, de elolvasva az oldalt és a doksiját, eléggé ígéretesnek tűnik.

Nagyon meg vagyok elégedve a Bacula-val működés-megbízhatóság terén, de egyetértek, hogy rémálom a telepítés és az üzemeltetés mai szemmel. Mindenképp kap egy próba lehetőséget a Burp tőlem, akár a Bacula (nem tervezett) leváltója is lehet belőle nálunk.

Valószínűleg pont azért nem terjedt el, mert kő 1xű ....

Nincsen csilivili GUI, nem lehet összekattingatni.
Az SSL kulcsokat openssl-el kell kézzel legenerálni, a konfigokat kézzel kell összerakni, kliensre eljuttatni.

Mentés egy sima "burp -a b" paranccsal lehet indítani, de hasonló módon lehet visszaállítani is bármit, ha nem használod UI-t.
UI-ban kapsz egy kis "kényelmet", látod a meglévő mentések/kliens, tudsz benne tallózni, fájlokat visszaállítani, ez a része már user frendly.

Backula tudásának a töredékét tudja, de nem is kell hozzá pilótavizsga.
Ami az esetek 99%-ban kell A-ból B-be megadott helyekről (inkrementális) mentés, és onnan visszaállítás (adott időpontra), azt tökéletesen elvégzi.
Kliensenként minden testreszabható, A kliens 12 óránként ment, x,y,z könyvtárakat, 30 példány maradjon meg - B kliens 4 óránként menti z könyvtárat, 90 példány maradjon meg.

És tényleg bármin is elfut, amin openssl életképes, ott Burp is menni fog. Jellemzően azért linux alapokon, pl synology-ra nem volt egy nagy matek csomagot készíteni.

A Bacula-hoz mérten nagyon egyszerű konfigurálni, beüzemelni. 15 év Bacula-zással a hátam mögött, kialakult, bevált konfig készlettel még mindig azt gondolom, leváltanám egyszerűbb üzeműre. Én (igyekszem) csak Linux alapú rendszerekkel foglalkozni, azoknál kb. egyiknél sincs GUI konfigurálás, így ez nem szempont nekem. A text alapú konfigurálásokat hasonlítom össze magamban. Abban sokkal könnyebb és átláthatóbb a burp.

Maga a burp nagyon könnyen üzembe helyezhető úgy szerveren mint kliensen. A v2.4 - ami most a stable - teljesen önállóan készíti és teríti a tanúsítványokat, repo-ból telepítve meg a kofig is félig kész mindenhol. A kliensen valóban kell egy kicsit konfigurálni, de ez annyi, hogy meg kell mutatni neki a szervert, és nevet, jelszót kell állítani. Eddig nem láttam olyan szerver-kliens menő rendszert, ahol ne kellett volna valamit beállítani a kliensen. Az nagyon tetszik, hogy a Windows telepítő minden paramétere mehet parancssorban, így könnyen automatizálható a telepítés.

A burp-ui telepítése azért feladta a leckét, mert nem jellemző, hogy Python-ban írt webappot kellene támogatnom, így nincsenek ilyen irányú ismereteim. A telepítéshez szükséges infók meg szétszórva a doksiban minden felé vannak. Csak az install rész elolvasása után nem valószínű, hogy működik a rendszer... De aztán életre kelthető ez is persze, és egészen jól működik. Lehet konfigot szerkeszteni a legújabb verzióban, azonnali mentést indítani (annyira azonnal, amennyire hamar jelentkezik a kliens a szerver felé - de ez a burp működéséből adódik), visszaállítást pedig lehet kérni nagyjából bárhová, akár saját admin desktop-ra is letölthetem a böngészőn keresztül (ilyent pl. a Bacula semmi módon nem tud).

A mentés és az elő-, utófeldolgozás sebessége durván elmarad a Bacula-tól. A teszt rendszeren nagyjából 1 GB/perc-et figyeltem meg, különbözeti mentésnél ez jelentősen rosszabb (a hosszas elő- utófeldolgozás miatt szerintem), a Bacula meg kb. Ethernet sebességen ment (1 GbE esetén ~7 GB/perc). De ez egy elfogadható kompromisszum a könnyebb telepítés, üzemelétetésért cserébe, azokban a környezetekben, ahol én használnám.

A Bacula vs burp tudás különbség akkor érdekes, ha az ember kihasználja a Bacula tudását. Sima napi file mentésre, X ideig történő megőrzéssel nem látok komoly különbséget. Ráadásul a Bacula Enterprise eléggé eltávolodott ilyen téren a Bacula Community-től, mert a magasabb szintű integrálások, modulok az ingyenesben nem elérhetőek, nem jelennek meg később sem (mint régen). Minden esetre a burp-nál is van lehetőség mentés előtt-után script-et futtatni, ezzel a feladatok nagy része megoldható (MySQL memory flush vagy dump, ilyesmi).

Egyenlőre tetszik. Pár hét próbaüzemet kap teszt környezetbe, utána kipróbálom a meglévő mentés meghagyása mellett kisebb ügyfélnél is. Azt nem látom még, miként tudom majd monitorozni (elsősorban Zabbix-al), hogy ne kelljen a napi e-mail jelentéseket olvasgatni.

Jól összeszedtél mindent! :)

Burp-UI telepítése tényleg érdekes, néha bele lehet szaladni nem kezelt függőségekbe is.

Mi nagios-al felügyeljük mindenhol, kiindulásnak:
https://github.com/pierre-guillot/check_burp_backup

Nem nagy kunct írni rá egy scriptet, szerver oldalon listázható az összes kliens, utána kliensenként listázható az összes backup.
bash-ben egy óra alatt összekalapálható.

Köszi a linket! Tovább is vitt ezen a vonalon.

Annak, aki idáig eljutott olvasásban és érdekli a téma: burp felügyelet Zabbix-szal: https://github.com/ronivay/burp-zabbix

Azért szükséges/fontos az aktív felügyelet, mert a burp ugyan értesít a sikeres és sikertelen mentésekről e-mail-ben, de nem értesít arról, ha egy kliensnek X ideje nem készült (sikeres) mentése (a működésaből adódóan: a mentést a kliens kezdeményezi, a szerver csak engedi vagy tiltja a konfig alapján). Ez azért nem annyira elhanyagolható kérdés.

Qt alapra mint desktop app? Bocs, nem vagyok annyira jártas, melyik framework pontosan mire jó. Ilyen téren szerény ismereteim alapján a Qt desktop célú.
Szerintem jó webapp-nak, így nem kell helyben telepíteni, lehet a mentő szerveren.

Mondjuk én úgy látom a burp-ui projekt Gitlab oldalán, hogy 3 hete volt az utolsó commit. Na persze, hogy ez érdemi, vagy kozmetikai, abba nem merültem bele.

( g3rg0 | 2022. 11. 29., k – 13:49 )

Szerkesztve: 2022. 11. 29., k – 14:59

Ha egyet hátra lépek, akkor az a kérdés merül fel, hogy otthoni környezetben MIRE mentsünk 2022-ben?

 

A dvd tipusú (n*100Ft-ért elmenthettünk egy akkori átlagos merevlemezt) eszköz talán nem is létezik.

Ami adja magát az valamilyen külső méretes hdd, NAS vagy felhő. Egyik sem az igazi, különböző okokból.

 

Ti mire mentetek otthoni környezetben a ransomware árnyékában?

Ti mire mentetek otthoni környezetben a ransomware árnyékában?

Ahogy fent kruska kolléga is írta:
 

1. Pull típusú mentés: a mentendő hostok nem érik el a backup szervert (sem megosztáson, sem SSH kapcsolaton keresztül), csak fordítva; így ha kompromittálódik a szerver, a backup biztonságban van. Akár azon az áron is, hogy a backup szerveren kell foglalni egy mirror területet, ahová folyamatosan szinkronizálódik a mentendő adat, és onnan kerül le mentésbe.

Nálam a mentés (pontosabban archiválás) az LTO szalag. Korábban LTO-4, később 5, most 7.

Offline, 20-30 év a várható élettartam, addigra már 2-3x újraírom egy újabb generációra ha kell.

Disclaimer: ebből (is) élek, Backup-as-a-Service). Egész szép kis rendszert kalapáltam össze az évek alatt, amolyan unixos módra: mtx/mt/tar/dd/borg és sqlite a katalógus adatbázisnak.

( cadmagician | 2022. 11. 29., k – 18:51 )

reoback

ne nyirjatok ki.

Aki másnak vermet ás, az stack pointer.

( Proci85 v | 2022. 11. 29., k – 21:48 )

Backup szerver benyúl a mentendő szerverre és rsync-kel áthúzza. A backup szerveren zfs van, amikor végez a backup script, nyom egy snapshotot.

Több dataset van beállítva, pl. mail, sql, archiv, ezek különböző lejárati idővel rendelkező snapshotokat tartalmaznak.

Sima MC-vel konzisztens snapshot-okban lehet tallózni a .zfs mappában.

SQL esetén úgy van, lvm-en fut és arról készól előbb egy snapshot, azt mountolja és rsync-keli. Ez kimaradt a leírásból tényleg. A rendszer és www esetén nincs ilyen, ez igaz. A felvetés jogos, bár éjjel a kutya se _írja_ a webes tartalmakat fájl szinten. Azért, ha sok időm lesz, lehet megreszelem ehhez is :)

Hát ő. Ebből már volt itt vita. SQL-t azt tuti konzisztensen csak a saját dumpjával fogsz menteni. A Veeam pl. az MSSQL -be beépül admin joggal, és úgy intézkedik, illetve ott a VSS, és egyéb Windows toolok.

Ha sima snapshotból megy SQL, az elég erősen kétesélyes lesz, és hiába működött eddig mindíg, az könnyen kevés lehet nagyobb problémánál.

...saját dumpjával fogsz menteni...

Nem az SQL -t használó alkalmazás saját toolja kell ehhez? Ha az alkalmazás több táblába ír adatokat egymás után, és a backup a folyamat közepén indul, nem lehetséges inkonzisztencia az adatok között? Vagy manapság a szerverek tudnak atomilkusan írni megfelelően technikát használva? Kb. tranzakcio start, iras, iras, iras, ..., tranzakció end. Vagy a start előtti, vagy az end utáni adatot kapom.

(Nagyon régen tanultam ilyesmit, és sosem írtam SQL fölé semmit.)

Ezt meg kell ugrania a dump toolnak, legyen az pg_dump vagy mysqldump, vagy bármi. Gyakorlatilag select-eket futtat a táblákra, és persze tudja, hogy tranzakciók vannak.

Egy PHP-s webáruháznak relatív ritkán lesz saját mentő toolja, mármint ami tényleg saját... :) Mert az exec('mysqldump') az nem saját.

Ugye az sql az egy lekérdezőnyelv. Az oracle db pl. meg tudja azt, hogy mentheted futás közben (alter database begin/end backup), majd a redo logból helyrehozza magát. Persze ja, lehet azon kattogni, hogy ez így konzisztensnek számít-e, de a lényeg, hogy van megoldás, és felteszem a többiek is tudnak hasonlót.

Tipikusan az van, hogy több megoldás van a mentés-helyreállításra, és az épp aktuális feltételek alapján lehet választani a legkevésbé rosszat.

Node ez egy az rdbms-ből jövő eleve konzisztensnek tekinthető adat, és nem valamilyen diszk állapotból készült valamilyen snapshot, amit majd valahogy visszapakolsz file szinten. A méltán népszerű (...) mysql/mariadb-nél ott van a bináris napló, amivel egészen visszahozható lehet a történet. A mysqldump vagy pgdump szintén futás közben masszírozza, meg kell ugrania. Ezzel szemben a snapshot ugyan papíron konzisztens filerendszer állapotot talál, de az egyáltalán nem biztos, hogy az adatbázis konzinsztens állapotával egybevág. Azt értem, hogy majd a recovery log, meg a minden failsafe összerámolja valahogy, de nem biztos, hogy erre jó építeni.

"Azt értem, hogy majd a recovery log, meg a minden failsafe összerámolja valahogy, de nem biztos, hogy erre jó építeni"
Az Oracle support szerint ez így a jó :) Nekem (is) égnek állt tőle a hajam, de működött, amikor kellett. Meg persze van nekik is tippre legalább tíz másik módszerük is.

> SQL-t azt tuti konzisztensen csak a saját dumpjával fogsz menteni.

nyilvan az az igazi (en is futtatok mysqldumpot fileba mentes elott), de elmeletileg ha a mysql data konyvtarat lemented snapshotbol, es arra alsz vissza, az pont olyan lesz, mint egy aramszunet utan (ups nelkul). journaling / binlog alapjan megjavitja a db-t es megy tovabb.  ms dolgokrol nem tudok nyilatkozni, olyat en bottal se ;)

Normális adatbáziskezelő érti a VSS-t. Onnantól pedig nem kell saját dump, ha a backup szoftver is kezel VSS-t, akkor a backup kezdetekor erről értesül az adatbázis, a commitolt tranzakciók belekerülnek a backup-ba, a futó tranzakciók és a backup pillanata után induló tranzakciók pedig a VSS temp területére iródnak, ahonnan a backup végével visszakerülnek a normális helyükre.

Igy készül konzisztens image backup egy futó adatbázisszerverről.

A snapshot nem feltétlenül instantpoweroff utáni állapot (például képes lehet egy az OS és filerendszer által konzisztens _filerendszer_ állapotképet prezentálni, és ha ilyen akkor valóban egész jó esély van arra, hogy ebből magához térjen egy db), és egyáltalán nem biztos, hogy bármelyik rdbms össze tudja magát szedni rendesen, ha olyan sérülés van a filerendszeren.

jah tellegmas: a snapshot elott a kernel nyomhat egy forceflusht, es csak utana csinal egy pillanatnyi allapotot miutan kiment minden write cache. tapkimaradasnal nincs ilyen, akkor akarmi is lehet az fs-el. szoval ami db nem tudja egy flusholt fs-bol osszekaparni magat, az nem db :)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Annyival kiegészítem, hogy egy helyen, ahol kritikus adat és 100GByte adatbázis van, de kibírja a pár másodperces leállást ott így történik:

Mentő script benyúl a célszerverre. service mysql stop, lvm snapshot, service mysql start (mehet a kiszolgálás, állt pár másodpercet), majd lvm mount és jöhet az rsync alapú több ideig tartó kimásolás...ráér, senkit nem zavar és tuti konzisztens.

A sima dumppal az volt a baj, hogy baromi sok idő és keveset változik az adat, felesleges a sok GB-s táblát kinyomni állandóan. Az rsync mindig csak a változó táblákat hozza át, gyorsan végez. Aztán lvm umount, snapshot törlés. Parasztos megoldás, de gyors, konzisztens és nálad a tuti működő nyers fájl, semmi hókusz-pókusz kontérbe csomagolt mentő program kimenete, ami kell a visszaállításhoz.

( buccaneers v | 2022. 12. 01., cs – 00:45 )

Én 100 éve file szintű tömörített(titkosított) mentésre helyben vagy FTP-re stb. ezt használom: Cobian backup

az új verzió: Cobian Reflector

 

valaki ismeri ?

For Whites Only meeting room!

Évekig használtam, majd. 2-3 éve újratelepítéskor elveszett a license -em. Ezért váltottam diplicati -ra. Semmi bajom nem volt a Cobian -nal, annak ellenére, hogy 2013 volt az utolsó release. Egyszerű cucc volt, azt tudta ami kell, de azt jól.

Az új verziót nem ismerem.

Ipari környezetben Win alatt néhány helyen használom. Tudja a Shadow Copy-t, szervizként fut, Schedule beállítás szerinti időzítéssal teszi a dolgát a háttérben. A Cobian backup 11 megbízható módon működik.

Kísérleti jelleggel az új verziót (Reflector) idén kezdtem el használni saját környezetben. Még nem bízom benne, ezért csak Win alól nyomom át a CAD-es munkákat Debianra, mert hiába dolgozom Linuxon, az ipar ezt nem hajlandó megérteni.

( kovacsbela | 2022. 12. 01., cs – 14:05 )

én borg-olok már az attic (a borg annak a továbbfejlesztése) óta.

soha nem volt vele problémám, számos visszatöltésen vagyunk túl. Mivel jórészt LAMP szerverek, így nagyrészt az adatbázisok változnak sűrűbben, így kb 10 perc alatt lefut 1 TB -on, mentve a különbségeket.

van olyan szerver, amiről 5 éve mentek 100 GB-ot folyamatosan, előzmény törlés nélkül. és most 600GB-os a dedupos, tömörített borg könyvtára, benne 5 TB adattal.
és a minap mountoltam egy 2021. 12. 01-es állapotot.

( kruska v | 2022. 12. 01., cs – 22:16 )

VM-ekhez is jó a borg egyébként, snapshot után a VM image deduplikálva menthető.

Sőt, Windowson is megoldható. HyperV szerveren ha van WSL, akkor azon elfut a borg, így frankón menthető:

https://hup.hu/node/178573

( YleGreg | 2022. 12. 02., p – 19:42 )

Hinnye, de bonyolultak vagytok.

Szoval fogsz egy WinRar.exe -t (termeszetesen egy krekkelt valtozatot) es a Windows beepitett utemezojebe beleirod, hogy induljon meg jo erosen mondjuk 4 orankent, es a file szerveren amin rajta van az arhiv bit, azt rakja bele a datum_ido.rar arhivumba, aztan torolje a bitet.

Ha menozni akarsz, vagy ingyen van a tarhely, akkor mondhatsz olyat is, hogy mondjuk hetente nyomjon egy full mentest.

Evekig ment ez a parasztmentes (PUN detected) egy foiskola irodai halozataban*, es meglepoen jol mukodott. Sot, meg fileokat is sikerult belole visszaallitani. :-)

* Ha jol emlekszem, egy delelott mondtak, hogy nagy emberek jonnek auditalni (azt se tudtam az mit jelent) es megneznek mindent is, kozte a backup meg arvhivalo rendszert. En visszakerdeztem, hogy az mennyire gond, ha nincs olyanunk? A hivatasos egyenruhas fazonoknak tanitanak egyfajta szuros nezest, na, a fonokom ezt kurva jol csinalta, egy szot sem szolt, de en leizzadtam. Mondtam is neki gyorsan, hogy semmi para, meg ebed elott lesz backup es arhivalo rendszerunk. Az elobbi a fentebb targyalt, a selejtbol kukazott "szerveren", Win XP alatt futo winrar.exe volt, utobbi pedig egy szinten tort Nero, amivel jol ki lehetett irni CD-re a mentest.

A vegen meg lettem dicserve. Tulajdonkeppen megerdemeltem. :-)

Szoval fogsz egy WinRar.exe -t (termeszetesen egy krekkelt valtozatot) es a Windows beepitett utemezojebe beleirod, hogy induljon meg jo erosen mondjuk 4 orankent, es a file szerveren amin rajta van az arhiv bit, azt rakja bele a datum_ido.rar arhivumba, aztan torolje a bitet.

Az első ransomware elpusztítja az így készült "mentést".