Sziasztok!
Régebben Cobian Backup-ot használtam, főleg azért, mert a ramsomwarek miatt ftp-n keresztül mentettem helyi hálózatba. Most kapunk elvileg egy felhős tárhelyet, amit meghajtóként lehet felcsatolni. Szeretném megkérdezni, milyen biztonsági mentést végző szoftvert javasolnátok. Windows 10 gépek vannak, főként a Dokumentumokat menteném.
Encryptálás nem szükséges.
Elég a Windows 10 backup szoftvere, vagy van annál jobb.
Néztem ezt a topicot:https://hup.hu/node/155442
Veeam Agent For Windows Free vagy Arcserve UDP 6.5 mennyiben lenne jobb? Talán kummulatív mentésnek hívhatnám, csak a legutolsó állapotra lenne szükség. A tárhely elvileg 5 verziót tárol a fájlokról. Amúgy utána találtam a filr fájlmegosztót/archiválót, valami novelles termék lehetett, de nem találtam magyar szolgáltatót hozzá, nem tudtok ilyenről?
- 1679 megtekintés
Hozzászólások
https://www.duplicati.com/ + vsftp
- A hozzászóláshoz be kell jelentkezni
+1 a Duplicati-nak, illetve az Rclone-t is nagyon szeretem.
- A hozzászóláshoz be kell jelentkezni
Rclone +1
- A hozzászóláshoz be kell jelentkezni
Csak egy kósza és költőinek szánt kérdés...
Vajon biztonságosnak tekintünk olyan backup megoldást, amely a kliensen fut és a BACKUP tárolási célja el van mentbe rajta bárhogy és akárhogy?
-------
Tipp: PUSH jellegű backup megoldások helyett használj PULL jellegűeket...
rsync, dirvish, backuppc, borgbackup, amanda, bacula
- A hozzászóláshoz be kell jelentkezni
Friss eset, hogy nem.
https://prohardver.hu/tema/melyik_a_legjobb_virusirto_progi_kerdes_elott_olva/hsz_63643-63643.html
- A hozzászóláshoz be kell jelentkezni
Most ez a pullt mennyire érinti? Leírás alapján ez egy sima ransomware ami szépen végigfuttott a hálózati megosztásokon és amit elért titkosított.
Itt Urbackup húzza be a kliensekről a mentést (de a kliensek nem férnek hozzá :)), a borgnál dettó. Ha a user elindítja a ransomwaret az szépen letitkosítja a helyit meg a hálózati megosztásokat amihez hozzáfér (de mivel hozzá se fér a backuphoz azt nem tudja). :)
- A hozzászóláshoz be kell jelentkezni
Win10 esetén túl sok esélyed nincs más. Ha Hyper-V vagy VMWare, akkor a hostról tudod jól menteni a megfelelő Veeam (backup & replication) az OS-t tokkal vonóval (szóval pull jellegű), de egy sima Win10-nél nincs sok opciód. A Veeam-ben van több lehetőség a backup biztonságos használatára:
- Tud olyat, hogy akkor ment, ha a diszk (USB) csatlakoztatva van, ez tehát fizikailag leválasztható
- Hálózati share esetén disconnectálja a célt, tehát nincs permanensen csatlakoztatva és lehet egyedi juzeres. Ettől még el van mentve a cél, csak a backup sw-ben, de gondolom valamilyen módon egyedileg tudja kódolni ezt az infót.
- Az Agent tud integrálódni a Backup & Replication konzolba, ami roppant kényelmessé és követhetővé teszi a mentéseket.
A Veeam-től függetlenül a backupról is készíhető jóval ritkább időszakos backup, bár ehhez megint hely kell, meg ugye macera. A pull jellegű egy csomó esetben nehezen használható, vagy ütemezhető vagy túl általánosan kell a kliensre befelé irányuló forgalmat tűzfalazni.
A történet másik oldala a visszaállítás minősége, illetve ideje és egyszerűsége.
- A hozzászóláshoz be kell jelentkezni
Tudom, hogy ez ügyben tudatlan vagyok. Józan ésszel nem tudom megvédeni az általad vázolt indokot, de megtámadni sem. Segítsetek, hogy az alábbi két érvelés miért fals!
A) (Ezt írod te) Ha a mentést végző (szoftver)eszköz a mentendő helyen van, akkor korrupttá válása esetén a mentett adatok is korrupttá válhatnak. Jobb a mentést végző eszköznek a mentési helyen futnia.
B) (Nekem ez is logikus) Ha a mentést végző (szoftver)eszköz a mentési helyen van, akkor a mentési hely korrupttá válása esetén az ÖSSZES mentendő rendszer is korrupttá válik. Jobb a mentést végző eszköznek a mentendő rendszeren futnia.
- A hozzászóláshoz be kell jelentkezni
Soha sem ilyen fekete fehér a történet és mindíg a konkrét feladat szabja meg, hogy hogyan és mivel érdemes nekilátni. Van ahol Hyper-V clustert mentek, ott maga a szoftver meg is határozta, hogy a backup konzol az csak úgy van és az érdemi mentés a virtualizációs hosztokon megy, ami a guestek szemszögéből pull végülis, bár igazából push, mert a hoszton fut a maga a mentés. Ahol kósza notebookos klienseket kell menteni, ott inkább teszem a notira a mentést, hogy ő indítsa majd felejtse el ha végzett. Ez egy "ha a backup cél elérhető és N nap napnál régebbi ott a mentés" c. beállítás a szoftverben.
Az sem mind1, hogy mi a mentésed célja, mit szeretnél vele. A fenti Hyper-V-s esetben az "A" mentés és very nagyon vigyázunk rá, ha van rá keret lehet másodlagos helyet megadni, lehet "kézzel" rsyncelni máshova, hogy ha a mesterpéldány kompromittálódik, akkor még vissza lehessen nyúlni korábbi backup-backup-hoz. A kósza notis esetben nem kritikus a dolog, inkább arról szól, hogy ha elhal egy diszk a juzernél vagy jön a kódolós őrület, akkor legyen esély visszaállítani a gépét relatív gyorsan egy rögtön használható állapotra.
Ha valamilyen unixlike történetet kell menteni, akkor átgondolod, hogy mit merre hogyan és scriptelsz, mint az őrült. Ha még SQL-t is kell menteni, akkor azt távolról kéne dumpolni, ehhez kell hálózati elérés és elég extra jogosultság, szóval megint ott járunk, hogy nem biztos, hogy kivitelezhető mindenhol.
- A hozzászóláshoz be kell jelentkezni
Sok állítás és még több kérdés...
1. Ha a biztonsági mentést ugyanazon a gépen végzed / tárolod ahol az éles adataid is tárolódnak akkor egy ransomware bekapása esetén
nagy valószínűséggel az éles adataidat és a mentésedet is bukni fogod. Mindezt függetlenül attól, hogy azt állandóan a gépbe rakott diszkre,
ideiglenesen rákötött diszkre vagy külső tárhelyre mented, ami állandóan fel van csatolva az éles gépen.
De akár egy merevlemez / raid hiba esetén is bukhatod az éles adatot is és a backupot is.
Ezért nem szokás/célszerű a biztonsági mentést csak és kizárólag ugyanazon a szerveren tárolni ahol az éles adataidat is tárolod.
2. Ha esetleg időszakosan rákötött (USB HDD) mentesz, amit cserélgetsz is.... akkor is bukhatod egy ransomware incidensnél
az éppen rákötött mentő egységen lévő mentésedet.
3. Ha esetleg FTP-re vagy más külső tárhelyre mentesz akkor is a mentő szoftverben benne kell legyen a mentés helyének
elérése és az ahhoz tartozó hozzáférés, hogy automatizálható legyen. Az, hogy ezt a hozzáférést titkosítás nélkül vagy esetleg
titkosítással (ami megfelelő időráfordítással de törhető) tárolja a mentő szoftver már más kérdés.
Személy szerint azt preferálom, hogy a biztonsági mentést végző eszköz kezdeményezze a mentést
és az az eszköz, amit ezáltal mentek az bizony a lehető legminimálisabb információval rendelkezzen róla.
(értsd: se IP cím, se felhasználónév se jelszót ne tároljon a backup szerverről az éles szerver)
Ezt pl el lehet érni úgy, hogy a biztonsági mentést végző eszköz kiemelt hálózati védelemmel van ellátva
és mondjuk ő kezdeményezi a mentést egy rsync+ssh-kulcs kombóval...
4. Az, hogy van egy biztonsági mentő szervered és van rajta biztonsági mentés az egy dolog.
Pont úgy tönkre mehet a biztonsági mentést tároló HDD / Szerver ahogy az éles szerver is.
Ezért szokás azt mondani, hogy egy mentés nem mentés...
Csak az adat értékétől és az elérni kívánt biztonsági szint mértékétől függ, hogy... (no meg a rendelkezésre álló anyagiaktól)
- hány példányban
- fizikailag mennyire védett és szeparált helyen (páncél, tűzvédelem, őrség)
- geolokáció szerint mekkora távolságban (1 szoba -> 1 kontinens távolság)
.... stb...stb...
5. Másik érdekes kérdés a helyreállíthatóság...
Nem elég sejteni, hogy van mentés! Meg KELL győződni róla! TESZTELNI KELL!
Az A) és B) kérdésre a fenti 5 pont öszessége használható válaszként és magyarázatként..
Ímhol pedig példa egy kevésbé szofisztikált mentési tervre:
1. Éles szerver - minimális tudással rendelkezik arról, hogy ki és mit ment róla
2. Belső Backup szerver - az Éles szerverrel akár egy helyen lévő ámde védett eszköz, amely az elsődleges mentési folyamatokat kezeli
3. Külső Backup szerver - geolokáció szerint az éles rendszertől X km távolságba lévő másodlagos mentési pont (mert a szerver terembe is belecsaphat a ménkű)
4. Külső merevlemez - a külső Backup szerver mentéseiből készült visszaállítási pont mondjuk zárható szekrénybe elrakva (mert a külső telephelyen lévő backup szerver is leéghet mondjuk)
5. Másodlagos mentési tároló hely - rendszeresen erre a helyre viszel a külső merevlemezes mentésekből 1-1 példányt (mert a külső telephely egész irodája is leéghet benne a páncélba zárt merevlemezekkel)
- A hozzászóláshoz be kell jelentkezni
Szerintem még mindig a 3-2-1 mentés az egyik legjobb módszer, nem az eredeti adat egyszeri lemásolása egyetlen példányban. Ennél 3 példány van, 2 helyben, 1 távol. A kettő helyiből az egyik az eredeti, az másik backup. Az egy távoli pedig vagy a backup másolata, vagy egy megegyező második mentés távolra (a kettő között a különbség a visszaállításnál van, a backup másolatot először le kell tölteni helybe, a megegyező másolatot távolról is lehet használni visszaállításra).
Sajnos Windows-on futó mentő/archiváló rendszereket nem ismerek. Mi Baculat-t használunk, aminek van Windows kliense is többek között. A felhős tárhelynek a 3. példány részére pedig vagy ügyfél távoli telephelyen lévő másik dedikált NAS-t, vagy Backblaze B2-t használunk. Utóbbit hol Synology NAS-ról vagy FreeNAS-ról a bennük lévő integrációval, vagy simán rclone-nal. Mindenhol egy erre dedikált NAS-ra megy a mentés, NFS-en felcsatolva a backup szerverre, ami a hálózatból semmi más gép számára nem érhető el semmilyen protokollon. A felhős tárhely pedig nincs felcsatolva sehová FS-ként, csak API-n érjük el.
Mostanában találtam rá az rclone-changer-re, ami szalag-cserélőt emulál a Bacula felé felhős (vagy bármi, rclone által támogatott) tárolóval. Ezt még nem próbáltam alaposabban, csak úgy gyorsan. Ha a tesztek után is jó lesz a vélemyénünk róla és bevezetjük, akkor a Bacula-val közvetlen a felhős tárolóból is vissza lehetne állítani bármit egyesével, nem kell először helybe visszahúzni a mentés állományt (az összes helyi példány megsemmisülése esetén).
Maga a mentés pedig nem csak a legutolsó állapotot őrzi (mert ha rámented a titkosított verziót, akkor lesz két titkosítottad és nulla jó példányod), hanem különböző időtartamokig megtartunk régebbi verziókat is. A legtöbb helyen 3 hónapig tudunk visszamenni (természetesen nem napiban, hanem az idő növelésével egyre nagyobb lépésekben). A tárhely manapság olcsó (még felőben is, nem még fizikailag helyben), így azon nem érdemes spórolni, ha az adatbiztonságról van szó. Ezen felül van teljes, különbözeti és inkrementális mód (nálunk dátumtól függően), hogy a mentési idő és a felhasznált tárhely is a legoptimálisabb legyen.
Csak felhős mentésnél muszáj számításba venni, hogy ha szükséges, mennyi lesz a visszaállítási idő. Helyi mentésnél mindenképpen sokkal rövidebb ez az idő.
- A hozzászóláshoz be kell jelentkezni
... gzip, dvdrecord... bluray
-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
- A hozzászóláshoz be kell jelentkezni
Nekem otthonra tökéletes pár PC-n futtatva (Windows 10 mind) a Synology bizonyos típusaihoz (x64 proci és btrfs támogatás kell) ingyenesen adott Active Backup for Business. Persze ehhez Syno kell.
A btrfs miatt a backupok dedupolva vannak, teljes gép visszaállításához elég egy "Recovery media" USB driveról bebootolni, NAS ip címét és jelszót megadni, kiválasztani melyik mentést akarod visszaállítani és kész.
Nagyobb SSD-re is ezzel költöztem, ez volt a legegyszerűbb :)
A backup megosztást aztán persze tudod pl. egy másik távoli Syno-ra vagy felhőb replikálni is.
"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."
- A hozzászóláshoz be kell jelentkezni
Kizárólag Veeam Agent For Windows Free vagy Arcserve UDP 7.
Az UDP-t jól ismerem, azzal van folyamatos kapcsolatom.
- Reportálható
- Riasztásokra képes
- Távolról kezelhető
- Kezeli a verziók számát.
- Tudja a mentést ellenőrizni.
- BMR végrehajtható vele vagyis bootolsz az új notebookon egy pendrive-al és nem sokkal később egy teljesen más hardveren fut az eredeti rendszer utolsó mentett állapota.
- Tud file szintű helyreállítást / exportálást.
- ... és még sokmindent.
- A hozzászóláshoz be kell jelentkezni
Ha központilag akarod felügyelni ez megér egy próbát:
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 hozzászóláshoz be kell jelentkezni
Céges felhős mentés:
# Előzmények: három év alatt a második LTO döglött meg, ezért többet nem veszünk. :-[
# Menteni kéne: egyszer 150 GB (teljes mentés), naponta 3GB változik (Windows Share: 300 MB és ERP adatbázis: 2,7 GB mentés),
elég lenne az utolsó 7 napot, plusz utolsó 3 havi és innentől minden éves teljes mentést tárolni. Évente a teljes mentés max. + 25 GB-al nő.
- 150 GB teljes mentés
- utolsó 7 nap x 3 GB inkrementális mentés (Windows Share: 300 MB és ERP adatbázis: 2,7 GB mentés)
- utolsó 3 hónap x 175 GB teljes mentés (becsülve)
- minden év x 200 GB teljes mentés (becsülve)
# Fontos lenne: vírus ne tudja piszkálni min. a felhőben lévő mentéseket, menjen automatikusan, e-mailben riportoljon a mentésről (sikerült / nem sikerült).
# Helyi infrastruktúra: Win 2016 Srv, 100/100Mbit net, lokális mentés van, egyenlőre külső merevlemeze és egy távoli NAS-ra is.
# Előny: EU-n belülre mentsen.
Mit javasoltok?
Köszi! :-]
- A hozzászóláshoz be kell jelentkezni
Virtualizált a windows?
Ha nem akkor MSP360 + NAS + B2 storage (holland központ)
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 hozzászóláshoz be kell jelentkezni
Köszi, Win Srv. on-premise, semmi sem virtualizált (majd jövőre a szerver cserével együtt).
- A hozzászóláshoz be kell jelentkezni
Arra javaslom a Proxmox VE + Proxmox Backup párost. A Proxmox Backup szerintem jelenleg minden visz, a kezdő mentés után a napi mentés pár másodperc (nem vicc, szó szerint) és a ZFS dedupkliáció miatt a mentés mérete, hónapokkal később is, gyakran kisebb mint a mentett gép mérete. A mentést titkosítva tudod offsite szerverre sync-elni beépített eszközzel. A virtualizálásból eredően a windows ebből semmit sem lát, nem tudják elérni a windows alól, ha host környezet külön ip subnet, akkor még fizikailag sem éri el sehogyan sem a windows-os gép, gyakorlatilag zéró az esélye a kompromittálódásnak.
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 hozzászóláshoz be kell jelentkezni
Bareos-t hasznalok.
Van ahol direktben S3-ba mentek, ott egy pici VM-ben fut a Bareos
Van ahol dedikalt gep van ra, par TB SW RAID-del. 3 havonta full, havonta diff, napi incremental backup van, estenkent felmasolja egy S3-ba az elkeszult menteseket.
Lifecycle policy pedig elpakolja Glacier-be.
A visszaallitasnak igy van koltsege ami meg mindig toredeke egy LTO hardwarenek illetve az adatok ertekenek.
Titkositas kliens oldalon tortenik, minden mentett kliensrol kulon kullcsot hasznalva.
Masik alternativa a restic lehet.
- A hozzászóláshoz be kell jelentkezni
Köszi az infót, most megnézem! :-]
- A hozzászóláshoz be kell jelentkezni
Bármi olyan mentés, amit a kliens kezdeményez, a kliensről elérhető (törlésre, módosításra), azt felejtsd el.
Kliens-Szerver alapú mentés, ahol a kliensnek annyi joga van, hogy tud backupolni, esetleg visszaállítani, semmi egyéb.
Burp-ot használok újabban mindenre is, nagyon nagy megelégedéssel.
"Sose a gép a hülye."
- A hozzászóláshoz be kell jelentkezni
Köszi szépen, most megnézem amit ajánlottál! :-]
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
Microsoft Azure Recovery Services (MARS)
Windows Server share mentéssel kapcsolatban van valakinek vele tapasztalata?
Köszi!
- A hozzászóláshoz be kell jelentkezni