Backup btrfs-el?

Sziasztok!

 

Adott egy (free)PBX szerver, amire rá van akasztva körülbelül 5 készülék, szóval ilyen szempontból nem kritikus a működése, viszont az egyik nem árt, ha lehetőleg 0-24-ben üzemel de főleg napkeltétől napnyugtáig.

Még folyamatban van a megvalósítás, de minden valószínűség szerint nem lesz lehetőségem fizikai backup szerver beállítására mostanában.

Egyelőre úgy néz ki a dolog, hogy van egy szoftveres RAID1 tömb és onnan fut a rendszer. Ha valamelyik lemez megkotlik, akkor megy tovább a másikról, ilyenkor csere mehet majdnem futásidőben mert nem hotswapos a rendszer, de egy gyors újraindítást kibír mindenki. Ha alatta a vas romlik meg, akkor elméletileg vannak a raktárban ideiglenesen felhasználható hardverek szóval így előreláthatólag max fél-1nap kiesés lehet ami egyébként elég géz de még nem volt időm elmagyarázni a főnöknek hogy mégiscsak meg kellene oldani majd azt a másik szervert mellé. Mert itt minden fillérrel garasoskodnak ami bizonyos szinten érthető is, de nem biztos, hogy itt kellee... Szóval ameddig ez van, addig arra gondoltam, hogy:

Mivel a raid nem véd az esetleges hibás frissítésektől vagy konfigoktól, így kellene egy olyan megoldás, ami lehetőleg snapsot rendszerű.
Maga a rendszer nemsokára új vasra költözik, mert a mostani csak kölcsönben van, így még van időm picit gondolkodni. Igazából csak az a kérdés, hogy csináljak mindenhova btrfs-t és egy külön partícióra vagy lvm kötetre toljam a backupokat, ahonnan baj esetén visszaállítható (gondolom legrosszabb esetben egy live rendszerről) vagy tegyem a mentéseket külön fizikai lemezre? Ez utóbbival abszolút 0 tapasztalatom van és rajtam kívül sajnos a backup meg sem fordul a fejében senkinek itt, szóval ha jót akarok magamnak, kénytelen leszek megoldani valahogy mert hiba fennállása során néha erősen megy a vér verejték sztori :D ebből nem akarok engedni, mert eyébként mindig tudják az embert sokkolni különböző feladatokkal de mivel ezért egyedül én leszek a felelős, így ki akarom hozni a lehető legjobbat az lehetőségekből. Lehet, hogy így 2x annyi ideig tart majd az install de legalább nyugodtabban alszok utána. (fél nap helyett 1?)

Ha valakinek lenne erre a micro projektre javaslata, azt szívesen fogadom.

Hozzászólások

Szerkesztve: 2021. 04. 11., v – 22:53

Én régóta komplett FreePBX distrot használok virtualizálva (Asterisknow)Van backup modulja ami bőven elegendő, simán kitolom a konifogkat cdr-t stb egy ftp-re vagy ahol éppen ami van. 

Ha gond van, felhúzok templateből egy másik freepbx, config visszatölt és megy tovább minden.

A migrálásokat is igy csináltam, az újabb freepbx simán megette a régebbi konfigot is. 

Fedora 33, Thinkpad x280

A BTRFS miatt kattintottam a temara, PBX-ben egyaltalan nem vagyok kepben, de nekem a ventrura megoldasa tunik a legjobbnak. Ahogy latom mindenki mas a teljes filerendszer backup-ban gondolkodik, de ha van mod az alkamazast backup-olni en azt preferalom. Sokkal kisebb, gyorsabb (mert nem mindent kell menteni, csak ami fontos). Ha eleve virtualis gepet csinalsz akkor ki is probalhatod a backup/restore-t egy masik virtualis gepen.... A nem kiprobalt backup-rol a kritikus pillanatban derulhet ki, hogy megse jo. ;)

btrfs snapshot az jó, laptopon 5 percenként/óránként/naponta/havonta snapshot van, évek óta, az sok minden ellen véd... pl. rolling distro nyalánkságok ellen...

meg használok btrfs/zfs snapshotot backupra, külső szerveren: snapshot+ssh+rsync... sok éve... lehet, hogy ez jobb volna neked, bár írtad, hogy nincs pénz...

bár ezt akár egy 5 eurós VPS-re is lazán be lehet lőni...

 

a btrfs-vel van még egy olyan, hogy, bár mostanában elég stabil, de ha meghal, akkor meghal... persze, van esély valamiket visszaszedni, de az is megeshet, hogy csók, adat :)

>btrfs snapshot az jó, laptopon 5 percenként/óránként/naponta/havonta snapshot van, évek óta, az sok minden ellen véd... pl. rolling distro nyalánkságok ellen...

+1, én is így csinálom. Pontosabban rootot csak frissítések előtt snapshotolom, oda elég az is. Évente 1-2 alkalommal simán megborul Arch valami jól sikerült frissítéskor, aranyat ér ilyenkor, hogy nem kell csomót molyolni, hanem nagyon max pár perc alatt (ha be se butul a rendszer és meg kell keresni a linuxos pendriveot) snapshotból utolsó állapot visszaránt, aztán szevasz, pár nap múlva lehet újra próbálkozni.

Máshogy Archot én nem is mernék használni. :)

>a btrfs-vel van még egy olyan, hogy, bár mostanában elég stabil, de ha meghal, akkor meghal... persze, van esély valamiket visszaszedni, de az is megeshet, hogy csók, adat :)

Ez konkrétan többször is megesett velem, utoljára pár hónapja talán. A backup kötelező, kritikus üzleti rendszerek alá meg nem való még mindig a BTRFS, lehet nem is lesz alkalmas már rá soha. Ez mondjuk szomorú nagyon.

Nálunk van egy távoli tartalék gép, amire BTRFS snapshot után, megy send/receive-vel a backup, mindez SSH-n keresztül.

Nekem a céges gépem úgy működik, hogy van egy SSD-m, azt használom, 15 percenként btrfs snapshot, ami send/receive egy szintén a gépbe épített HDD-re. Emellett van send/receive egy távoli szerverre is ssh-n, de az csak óránként. Így a backup mellett van egy 15-perces időgépem is. Évek óta így használom, és már többször hasznát is vattam, mind a timemachine, mind a backup részének, sajnos többször makkant már meg az SSD, így egy sima csere után, egy mozdulattal állítottam vissza.

Azt kell megvizsgálni, hogy milyen hibák ellen hogyan akarsz védekezni?
Ahogy azt te is megállapítottad, a HW raid nem véd a hibás frissítéstől, konfigtól - de egy fizikailag ugyanazon a diszken lévő mentés használhatósága is erősen vitatható: ha bekapsz egy FS sérülést, akkor ebben az esetben a backup ugyanazon a sérült FS-en van, mint amin az eredeti adat. Ez azért nem hangzik annyira jól.
A másik fele, hogy mit akarsz menteni? Ha a teljes rendszert (esetleg: VM-et), annak előnye, hogy relatíve gyorsan, egy menetbe helyre állítható a rendszer, a telepített program és a konfigok. Cserébe van erőforrás igénye. Ha csak egy konkrét program konfigurációját, akkor ebben az eseteb olyan szentségtörőnek tűnő megoldás is szóba jöhet, mint svn... Ha ritkán módosul a konfig, akkor elegendő csak a modosítás után egy svn commit és ennyi - ráadásul az előző konfigok is jól meglesznek.

A btrfs jó és stabil, de eszedbe ne jusson ECC ram nélkül használni. Plusz ha btrfs van lvm nem kell.

Ha valamennyire is érdekelnek az adataid amúgy is ECC használsz.

igen

 

A különbség az, hogy a btrfs-t pillanatok alatt tönkreteszi a ram hiba és nem jön helyre. Az ext4-et általában rendbe teszi az fsck.

ez pedig bullshit, urban legend, nevezd, aminek akarod... az ext4-et is pont úgy odavághatja a ram hiba... btrfs legalább leellenőrzi a checksumot...

nem érzékenyebb se a btrfs, se a zfs a ramhibára, mint az ext4...

Ha valamennyire is érdekelnek az adataid amúgy is ECC használsz.

Én meg olyan eszközöket használok, amikbe be van forrasztva valamiféle RAM. Ha tippelnem kellene, nem ECC.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Szerkesztve: 2021. 04. 15., cs – 09:58

Sok itt a hasznos infó, köszönöm!
Jövő héten úgy néz ki ráfordulok az ügyre. Valószínűleg az aktuális konfig lesz az elsődleges amit menteni kell, mert ebből a rendszer azért szükség esetén visszaállítható. Illetve híváselőzmények (amiről egyelőre nem tudom, hogy hogyan fog menni) + rögzített hívások, de azoknak megvan a helye.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Látszik, hogy nincs még tapasztalatom btrfs-el.

Csináltam egy snapshot-ot a gyökérről a /.snapshots/subvol1 helyre. Eddig oké, látok is ott mindent is.
A gond az, hogy onnan állományokat tudok csak visszaállítani a cp-vel mondjuk, de magát az egész snapshotot nem tudom visszaállítani mert azt mondja, hogy File exists.

Valószínűleg az sem segít rajtam, hogy ugyanazon a partíción vannak a snapshotok (illetve a subvolume-ok) ahol a rendszer gyökere.

Itt három opció jutott eszembe:

1. Vagy megpróbálom rsync-el visszaállítani
2. Külön particióra teszem a rendszert és a snapshotokat - szerintem ezt nem úszom meg reinstall nélkül
3. állítólag fstabból kileshető egy paraméter, amit grubban megadva elindítható a korábbi snapshotról a rendszer. 

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Ez jól hangzik, csak az a kérdés, hogy debian telepítés közben ez mennyire konfigurálható. Ha a rendszert tudnám telepíteni subvolume-ra az lenne a legjobb. Vagy ez telepítés után elvégezhető?

 

Már kezdem elengedni a témát, egyre közelebb kerülök az rsync-hez csak az lassabb :|

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Úgy néz ki, hogy sikerült a dolog. Végülis feltettem a Timeshiftet, mert azzal sokat segít főleg a visszaállítás terén. Konzolból is megy :) Kicsit hákolni kellett a raid miatt, mert a gui-n nem ajánlotta fel az md0 kötetet, de konzolból megette.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Persze, azok ugyanúgy a részét képezik a RAID-nek.

Utólag így tudod a /dev/sda1 btrfs fájlrendszered raid1-esíteni, amin eleve lehet sok subvolume és snapshot:

Ehhez a btrfs balance -ra lesz szükséged. Pl., ha /dev/sdb1 -et akarod hozzáadni második device-ként:

sudo mount /dev/sda1 /mnt
sudo btrfs device add -f /dev/sdb1 /mnt
sudo btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt