Követelmények:
- Adatbázis és fileok mentése (de <10MB adat)
- RTO < 1h
- RPO < 1 nap
- A mentés folyamatos ellenőrzése
Az adatbázis némi figyelmet igényel, naiv filerendszer snapshot nem jó.
Az utolsó pont a trükkös. A legtöbb megoldás (pl. VM disk snapshot) nem bizonyítja önmagában,
hogy amit elmentettünk, az visszatölthető-e, és pl.: nem zsarolóvírus által megemésztett adatot tartalmaz csak.
Megoldás:
- Minden VPN mögött, jogosultság ellenőrzéssel
- A szolgáltatás két példányban fut, éles és tartalék
- HTTP GET /backup: konzisztens mentést csinál, zip fájlt ad vissza (amit egy ideig helyben is tárol)
- HTTP PUT /backup: beolvas egy zip file-t, betölti az adatbázisba és újraindítja magát
- HTTP GET /metrics: minden tábla mérete és utolsó módosítása, egyebek, OpenTelemetry formátumban
- Minden éjszaka egy job leszedi az éles rendszerről az adatot, és betölti a backup rendszerbe,
ezután összehasonlítja a két rendszer metrikáit. Tárolja a mentéseket (biznyos ideig),
valamint a backup eredményeit (zip, metrikák) harmadik helyre küldi (email).
(4*curl+diff+mail)
A rendszer végére persze mindig kell egy ember, aki nézi a metrikákat es figyeli a leveleket.
- erenon blogja
- A hozzászóláshoz be kell jelentkezni
- 647 megtekintés
Hozzászólások
"naiv"-ra gondoltam. Ha csak simán lemásoljuk az adatbázis alatt a filerendszert (az adatbázis megállítása nélkül), könnyen inkonzisztens eredményt kapunk. Még egy snapshotoló fs esetében is előfordulhat ez (de ha van snapshot, akkor gondolom CoW, az pedig DB alatt nem szerencsés gondolom).
- A hozzászóláshoz be kell jelentkezni
> Ha csak simán lemásoljuk az adatbázis alatt a filerendszert (az adatbázis megállítása nélkül), könnyen inkonzisztens eredményt kapunk.
Így van, sőt számíthatóan inkonzisztens lesz az eredmény.
> Még egy snapshotoló fs esetében is előfordulhat ez (de ha van snapshot, akkor gondolom CoW, az pedig DB alatt nem szerencsés gondolom).
Snapshot-olható lesz az :) Ugye a snapshot az nem backup. Nem is értem ezt a terjedő trendet. Hogy VM-ekről, FS-ekről, bármiről snapshotot csinálunk, és azt backup-nak tekintjük. Nope, az nem backup, a közelében sincs.
echo crash > /dev/kmem
- A hozzászóláshoz be kell jelentkezni
lehet full state is snapshotolni, memoriatartalommal. annal konzisztensebb backupot nem nagyon tudsz csinalni egy adott vm allapotrol. :)
- A hozzászóláshoz be kell jelentkezni
Dehogynem. Leállítod (offline state), mented. Egy szeparált környezetben (buborékban) ha restore-olható, akkor az backup.
echo crash > /dev/kmem
- A hozzászóláshoz be kell jelentkezni
az mar nem ugyanaz az allapot, mert le kellett allitsd a szolgaltatast. mi van ha fel sem bootol mar legkozelebb? :)
- A hozzászóláshoz be kell jelentkezni
Akkor valaki mocsok nagy hibákat vétett az üzemeltetés során, és igazából az, ami ilyen állapotban van, azt már élőhalottnak lehet tekinteni. Fájdalmas könnyek között el kell búcsúzni a cucctól.
- A hozzászóláshoz be kell jelentkezni
viszont a kerdes nem errol szolt.
inkabb abban gondolkozz, mi van, ha beindult a vind'zapdejt, teged megker, hogy akkor most rebootold el a szervert, de mar soha nem indul el a vm.
na, ezekre pont tokeletes egy memoriatartalommal egyutt keszult snapshot. :) (been there, done that)
felkeszul: linuxos distupgrade utan mar semmi nem mukodik esete, mert megvaltozott a menetirany (libek, konfigok, mifenek). :) (been there, done that)
volt olyan vm snapshotom jatszos vason, amibol azota reg linux jatszos rendszer lett, aztan talaltam egy snapshotot 1 evvel korabbrol. na mondom, ez mi a csoda. es siman elindult belole egy egy evvel azelotti, futo windows X nap uptime-mal. :) na, ilyenekre jo ez :)
amugy nem hiszem, hogy lenne manapsag olyan rdb, aminek ne tudnal beszolni, hogy figyi, snapshot/backup van, most vegyel nagy levegot. :) es viszed file szinten az adatot/diszk snapshotot. :) de nem is relevans ez itt annyira, inkabb csak lazan kapcsolodik :)
nem mindenhol opcio az, hogy te ujjaepited a rendszert 0-rol meg visszatoltogeted az adatokat bele.
- A hozzászóláshoz be kell jelentkezni
Ezek a snapshotok restore-olhatók izolált környezetben, a backup kell hozzá egyedül. Legalábbis, amiket a Proxmox csinál vzdump-os backup, az ugyanabból a backupból tölthető vissza 1:1, akár teljesen másik clusteren is.
- A hozzászóláshoz be kell jelentkezni
> A legtöbb megoldás (pl. VM disk snapshot) nem bizonyítja önmagában, hogy amit elmentettünk, az visszatölthető-e, és pl.: nem zsarolóvírus által megemésztett adatot tartalmaz csak.
Nagy barátja vagyok a backup-nak, és most triggerelődtem, bocsi :) Egy "VM disk snapshot" semmit nem bizonyít, főleg azt nem hogy a mentett snapshotolt bármi visszatölthető-e, függetlenül attól hogy ransomware vagy bármi egyéb fertőzött-e. Láttam én már nem induló RHEL Linuxot multicéges környezetben (fájt), backupnak kikiáltott snapshotból, és még csak ransomware se volt.
> Mi a helyzet a "nagyon olcsó" lehetőséget igénylő kisvállalkozás igényével?
Számtalan lehetőség van erre. Amazon Glacier pl.
Backup:
stop all
backup (byte-ra pontosan)
start all
echo crash > /dev/kmem
- A hozzászóláshoz be kell jelentkezni
naiv kerdes: meirt nem db replika + querylog? :)
- A hozzászóláshoz be kell jelentkezni
Kezdjük ott, hogy az elejét duplán írtad be - nem tudom miért, de nagyon furán hat.
A vége felé vannak bakugrások azért ebben a posztban.
> - HTTP GET /backup: konzisztens mentést csinál, zip fájlt ad vissza (amit egy ideig helyben is tárol)
És mitől is lesz ez konzisztens? Mert te azt mondtad? Ha nem állítod le az SQL szervert vagy nem SQL dumpot mentesz, akkor az se lesz konzisztensebb mint a snapshot.
Plusz, ez a zsarolóvírus ellen nem véd. Ha nincs havi-éves backup megtartva, hanem mondjuk X napig láttok vissza, és a legrégebbit törlitek, akkor az adott rendszer használati gyakoriságától függ, hogy észreveszitek-e ha valami végigmászott dolgokon és felülvágta. Amire te gondolsz, az a rendszeres DR visszatöltés és ellenőrzés - erre viszont a "nagyon olcsó lehetőséget igénylő" kisvállalkozások általában nem gondolnak.
Ugyanez pl az offsite backuppal. Ha a backupot a hálózaton belül tárolod, az megintcsak nem fog a zsarolóvírus ellen védeni, cserébe a "nagyon olcsó lehetőséget igénylő" kisvállalkozás húzni fogja a száját, hogy miért is kellene neki Amazon Glacierre fizetni mondjuk 5 dollárt, hát ott van 30 tera a fájlszerverben.
"A mentendő szolgáltatás egy HTTP service, kevés felhasználóval, kis adatbázissal."
Itt pedig koncepcionális problémák vannak. Eleve ez nem EGY darab service, hanem alsó hangon KETTŐ:
- Van valami alkalmazás ami HTTP felett szolgál ki, és vannak adatai a fájlrendszeren
- És ez használ egy adatbázis szolgáltatást, amiben tárolunk ezt-azt.
És persze, ezt lehet alkalmazás oldalról megközelítve menteni (összezipelem a fájlrendszert + csinálok egy SQL dumpot), a WordPress meg a Drupal is csinál ilyeneket, de ez egyrészt az alkalmazás backupja, és nem az adott adatbázis szerveré / webszerveré, másrészt közel sem biztos, hogy ez bármilyen szinten konzisztens lesz.
Mondok egy példát: van egy kis webshopom, éjjel-nappal nyitva (ugye), 23:59-kor elindul egy fizetési folyamat, 0:00-kor a backup, kicsi a db, 0:02-re végez a backup, 0:03-kor jön az aszinkron visszanyalás a payment gatewaytől, hogy a pénz tényleg elment. Na, ez utóbbi nem lesz benne a backupban, és soha sehogy nem fogod tudni helyreállítani, ha 0:15-kor szétszáll az egész a rákba.
Backupolni dolgokat mindig úgy backupolunk, hogy első körben felmérjük az igényeket, és elkezdünk gondolkodni, hogy mitől nem fog ez az egész működni helyreállítás után. Aztán szépen hosszabiggyesztünk egy számot, hogy az adott issue mennyire fáj nekünk üzletileg/szakmailag. Pl elveszett egy rendelés fizetési állapota, az jellemzően fáj, az, hogy BloodySteve35 "a qvanyátókat hoty sak 1gyet kűdtetetek" visszajelzése elvész, az kicsit talán kevésbé. Ha timeoutba megy a HTTP kérés, és a ZIP vége nem érkezik meg, az meg mondjuk mocskosul fáj.
És akkor jönnek azok a megodások, hogy pl backup előtt 5 perccel maintenance-ba tesszük a site-t. backup végén ellenőrizzuk az SQL fájl konzisztenciáját mondjuk egy teszt DB-be való visszatöltéssel, stb. Attól függ, milyen aspektus fáj nekünk és mennyire.
Aztán felmérjük azt, hogy mennyi időbe kerül _most_ a backup, és mi lesz 10 év múlva, amikor ötször ekkora lesz az adatbázis és/vagy a fájlrendszer, és nem megy 1 perc alatt körbe a backup. Mert ami 1 percen belül konzisztens, az nem biztos, hogy 15 percen belül is az lesz. A "nagyon olcsó lehetőséget igénylő" kisvállalkozások pedig általában ezeket a rendszereket elfelejtik, egy idő után nem fizetnek karbantartást se, mert minek: "hát működik, ott látom a fájlszerveren, hogy keletkezik minden nap a backup-2035-08-11.zip, ezt én is tudom figyelgeni, majd szólunk ha vissza kell állítani", aztán mikor odajutsz hozzá, akkor jönnek a meglepetések, mikor kibontod a csomagot. Például hogy fél éve üres az SQL mentés fájlja.
Ezeket a "nagyon olcsó megoldásokat igénylő kisvállalkozásokat" meg kell győzni arról, hogy miért fontos a megfelelő mentés használata, és arról is, hogy a backup az nem egy buy & forget dolog. A backup az olyan, mintha az ember magához venne egy bernáthegyi kiskutyát, rendszeresen foglalkozni kell vele, mert ugyan lehet, hogy egyszer az életedet fogja megmenteni a hegyen, de addig is szüksége van gondozásra.
- A hozzászóláshoz be kell jelentkezni