Fájlrendszer backup futó OS-ról

Naplózó filerendszerek (journaling)

Adott egy max 8000M méretű rendszerpartíció rajta linux serverrel,
amiről x időnként crontabból futtatva egy használható teljes backup kéne készüljön.
A fájlrendszer ext3.

A dd nem nagyon játszik. Futó rendszerről készült dd-s fájlt még nem sikerült visszaállítanom...

A legkényelmesebb az lenne tar-ral be lehet csomagolni az egészet,
de nem tudom, hogy a jogosultságok, ilyesmik, hogy maradnának meg,
illetve egyeltalán képes-e hozzáférni minden fájlhoz a rendszeren?

Tehát a nagy kérdés az, hogy futó rendszerről, hogy lehet normális (teljes) mentést készíteni?

PS: RAID1 nem játszik, ígyis 5 winyó van a gépben és otthoni szerverről van szó.
Ráadásul szoftveres RAID-del nagy károkat tudok okozni, ha rendszer kerülne rá.

  • 5502 megtekintés

( eax | 2009. 10. 25., v – 20:16 )

lvm snapshot

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Macerás. Egy hosszabb leállás nélkül biztosan nem fog menni.

Egyszerű megoldás: másik vinyó, amin létrehozod az Physical Volume-ot, majd ebből építesz Volume Groupot és ebbe a rendszernek való Logical Volume-ot, majd éles rendszer leállít, valami live image felbootol, és dd-vel áttolod a Logical Volume-ra az eredeti partíció tartalmát. Végül mount és fstab, grub/menu.lst és hasonlók átírása, esetleg initrd újragenerálás, hogy LVM-ről induljon.
Bonyolult rizikós megoldás: éles rendszer leállít, resize2fs-sel fájlrendszer zsugorítás, partíció zsugorítás, LVM PV-nek partíció létrehozás, innentől mint az előző, végül eredeti partíció ledob, helyére szintén LVM PV létrehoz és hozzáad a Volume Grouphoz.

Először mindeképpen célszerű egy virtuális gépen elpróbálni a lépéseket a megfelelő disztróval, hogy a leállítás előtt már előre ismerd a buktatóit. Elsőre ritkán sikerül mindent beállítani úgy, hogy hiba nélkül bootoljon, 1-2 dolog mindig kimarad, ezt jobb úgy csinálni, hogy nincs az emberen a nyomás, hogy "gyorsan legyen már kész mert indítani kéne".
---
Internet Memetikai Tanszék

( gd | 2009. 10. 25., v – 20:23 )

tar-nak opciókkal meg lehet adni, hogy tartsa meg a jogosultságokat, időt stb. root-ként minden fájlhoz hozzá fér.

Viszont nem hiszem, hogy a rendszerről is érdemes mindig mentést csinálni, nem csak a kiszolgált fájlokról. Az adatokhoz gondolom, tudod, melyik felhasználók férhetnek hozzá.

Fontos a rendszerről is, mert folyamatosan hegesztgetem, fejlesztem és a rendszer partíció egy 10 éves ATA winyón van, ami bármikor elpatkolhat.
A kiszolgált adatok RAID tömbökben vannak. Felcsillant a szemem, hogy majd az egyik RAID1 tömb végére odarakom a rendszert, de itt még nem tartok.

Kipróbálok egy tar-os metést és virtuális gépen megpróbálom beindítani.

Itt egy friss próbálkozásom:
http://hup.hu/node/78659 ?

Két másik hup-os kolléga ihletett erre.

(még a partíciós táblát kell elmenteni és azt, hogy az egyes slice-okon milyen fájlrendszer van, pl. mentésnél dd és sfdisk -d, visszaállításnál sfdisk és mkfs.* kellhetnek)

ami át van húzva, azt teljesen fölösleges elolvasni. az olyan, mintha ott sem lenne

( XMI | 2009. 10. 25., v – 20:29 )

A dd nem nagyon játszik. Futó rendszerről készült dd-s fájlt még nem sikerült visszaállítanom...
Alapvetően LVM a barátod, abban lehet snapshotot csinálni egy teljes partícióról (LVM-nél logikai kötetnek hívják), majd a snapshotot dd-zni, végül ledobni. A snapshot teljesen atomi művelet, pillanatszerű állapotát fogja megőrizni az eszköznek, az időközben történt változásokat copy-on-write jelleggel külön tárolja. Tehát a rendszer zavartalanul tud működni miközben egy kicsit korábbi állapotát éppen backupolod, nyilván teljesítményben van kis ára, ezért is (és a snapshot COW volume növekedése) célszerű a backup végeztével mindig eldobni a snapshotot.

A snapshot nélküli dd-zés azért lesz használhatatlan, mert a másolás nem atomi művelet, ahogy másolódik, közben össze-vissza lesznek változások és amit már lemásolt az eszköz elejéről az nem lesz konzisztens azzal, amit még csak most fog másolni az eszköz végéről. A napló csak arra jó, hogy a teljes eszközről készült konzisztens pillanatképen vissza tudja játszani a félig befejezett műveleteket.

A fájlrendszer szintű backup esetén is megjárhatod, ha pl adatbázis fut, mert a DB backend fájlját nem fogod tudni úgy lemásolni, hogy közben a DB ne akarjon valamit valahol módosítani benne. Legalábbis szerencsére lesz bízva, az pedig backupnál nem jó dolog. Ilynekor a DB-ről külön fájlba dumpot kell csinálnod a backuphoz, a DB engine meg fogja oldani, hogy konzisztens legyen. Vagy rábízod magad a blokkos eszköz szintű snapshotra, ami egyben a DB-ről is atomi pillanatképet csinál.
---
Internet Memetikai Tanszék

Adatbázisról van a hét minden napjára mentés (mysqldump), az nem probléma, ha esetleg a fájlrendszeri mentésben nem lenne.

A tar-os backupnál fennállnak ugyanazok a problémák, mint a dd-nél?
El se kezdem akkor...

Az LVM-től azért idegenkedem, mert ugyanúgy nem foglalkoztam még vele, mint a szoftveres RAID-re telepítéssel.
Ha meg már egyiket gyorsan meg kell tanulni és átmentenia rendszert, akkor az utóbbi még jobb is lenne.

( mazursky | 2009. 10. 25., v – 20:45 )

esetleg dirvish, mint a lehetséges megoldások egyike.
nem túl bonyolult összelőni.

/mazursky 

Love your job but never love your company!
Because you never know when your company stops loving you!

( hrgy84 | 2009. 10. 25., v – 22:13 )

En baculat hasznalok, gondosan kizarva azokat a mappakat, ahol db mukodik (arrol van kulon dumpbackup). Bar a futo rendszert ad-hoc mentem, de lehetoseg lenne rendszeres inc+full mentesre is.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( LGee | 2009. 10. 25., v – 22:29 )

mondo/mindi elvileg erre van, bar nem ismerem...

( barii | 2009. 10. 25., v – 23:54 )

mindig mindenki dd-zik... az mennyivel jobb egy cp -ax-nál? nekem úgy tűnt annyi a különbség, hogy a dd lassabb

( apal v | 2009. 10. 26., h – 00:25 )

Az xfs filerendszert lehet dumpolni (normalis es teljes, lasd: 

xfsdump

). Ha arra at tudsz allni valahogy, akkor?

Tétel:
Készítsen snapshot-ot egy futó OS-ről. Nem gondoltak rá a telepítésnél. Lehetőleg mellőzzön minden technológiát, ami erre való.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( fimikz | 2009. 10. 27., k – 10:30 )

igen, az ember pontosan ezert hasznal olyan FS-t, amiben van snapshot support. ez nem osszekeverendo az FS alatt levo blockdevice snapshotolhatosagaval, mert a ketto kozel sem ugyanaz. ext3+snapshot temakorben keresgess, ha tud ilyet, ott az idealis megoldasod, ha nincs, akkor haxolhatsz jo gnuhuszar modjara mindenfele szerencsetlen szolucioval.

( pgabor v | 2009. 10. 27., k – 11:35 )

Nem nyitok új témát, talán ide befér.

Backup-manager debian-on minden reggel létrehozza a kívánt backup fájlokat. Teljesen random módon az md5 fájl és mellette általában még egy (log vagy mysql) nem megfelelő jogosultságokkal jön létre. Logok alapján: használatban van a fájl és ezért gond akad a csomagolásnál. Találkozott már valaki ezzel a problémával?

( xray | 2009. 11. 12., cs – 20:49 )

Relax & recover?

Sokat olvastam róla állítólag nagyon jó bár még nem próbáltam. FS layout LVM layout mindent lement elvileg.