Backup rendszer kiépítése

UNIX haladó

Szaisztok!

Egy szerver folyamatos mentését szeretném megoldani. Az albbi szempontok alapján kellene kialakítani.

- sok kicsi és apró fájlt kell menteni naponta egyszer
- mentési tárhely van bőven, ami pl. NFS-en keresztül érhető el, de annyi nincsen, hogy naponta mindent újra teljesen lementsünk
- fontos, hogy 30 napra visszamenőleg tudjunk visszaállítani állapotokat, többnyire egy-egy fájlt, amit törölt a felhasználó
- fontos, hogy ha teljesen meghal a szerver, akkor a teljes visszaállítás is minél gyorsabb legyen

Kérdésem, hogy kienek milyen ötlete, elképzelése vagy tapasztalata van e téren? Köszönöm ha foglalkozol vele.

  • 6481 megtekintés

Nincs mit.

Első mentés adatmennyiségtől függően "sokáig" tart.
Definiálhatod hány napos inkrementet akarsz menteni pl. -d 30, a visszatöltésnél is megadható mikori mentést akarod visszaállítani.
Jól scriptelhető mind a két folyamat.
Első mentés után elenyésző időt vesz igénybe a mentés, persze ez is adatmennyiség függő.

Ajánlom a két helyre mentést biztonsági okokból, a másikra pl. heti egyszer egy teljes mentés s soha nem lesz gondod :-) S a törölt levelét visszaállítod te leszel a király :-)

dirvish, rdiff-backup es hasonszoru baratainal felesleges teljes mentest futtatni periodikusan, mivel az aktualis allapot mindig a legujabb teljes mentes allapotat mutatja.

Sajnos persze ez sem igaz teljesen, volt mar ra pelda, h vmi kernel bug miatt a munin-nak az .rrd file-jain nem modosult az mtime (CentOS 5) es igy azok nem kerultek bele a mentesbe.

Csak FYI.

tompos

( maszili | 2011. 08. 30., k – 09:52 )

Szerintem jó megoldás lehet az...

rsync -rlptgoDH --delete -h $RsyncOpt "$User@$Host::$Module/" "$des/"

majd...

cp -al $des/* $arch/

--
maszili

( Skuzzy | 2011. 08. 30., k – 11:20 )

Nekem most ez alapjan az rsync tetszik:

http://danielmcgraw.com/2010/02/25/Incremental-Rotating-Backups-With-Rs…

Hard linkekkel jatszva, ami nem valtozik, az csak egyszer van letarolva fizikailag, a rotalasnal meg csak linket tesz ra, az ujakt menti fizikailag, ami meg torolt, arra nem rak linket.
Az elso nap teljes masolasa utan, mar gyors is.

Nalam levelezest mentve igy az eredeti meret 110-120%-ra rafer ket het. Mivel tomoritetlen, gyorsan visszaranthato barmi, ha kell.

Ez egy regi, de magyarazosabb leiras ugyanerrol:
http://www.mikerubel.org/computers/rsync_snapshots/

( p.zoltan | 2011. 08. 30., k – 11:24 )

ezt használom kb 3 éve nagy sikerrel: r1soft.com

( mhmxs v | 2011. 08. 30., k – 11:34 )

Amit ajánlani tudok : duplicity egyszerű, kényelmes, hatékony
Amit nem ajánlok: dirvish, jó amíg minden jó, de ha egyszer elsz@ródik nehéz konzisztens állapotot visszaállítani

Nálunk rendszeres a "dirvish error: branch /bar/foo:default image 20110829-2204 failed", és a "cannot expire bar-foo/:default:20110829-2205 No unexpired good images" üzenet. Tudom mit jelent a hibaüzenet, és tettem jó sok kisérletet a javításra is (átírogattam kézzel a dirvish státuszokat, meg minden) érdemleges változás nem történt. Amit sikerült is megcsinálnom, néhány nap mulva ismét elszaródott, vagy ha nem az akkor a másik. Meguntam, most duplicityt használunk, és bevált, nem kezdem minden reggelemet úgy, hogy az elsz@rt (és mostmár érted :)) backupokat javítgatom kézzel.

Már odáig fajultunk, hogy hackolt rsync_no24-el szinkronizálunk, ami a 24-es hibát, azaz a forrás közben változott elnyeli. Nem segít mindig. Kb 6 gépről mentünk összesen majd 30 könyvtárat, és ritka az olyan reggel, amikor minden flottúl megy, ezért váltottunk. Igaz így a duplicityt midnen gépen be kellett állítani, de azóta nincs hiba.

Nekem nem vilagos, hasznaljatok meg, vagy nem?

Ha igen, ezzel probald:

--- dirvish-expire 2011-03-17 15:31:58.000000000 +0000
+++ dirvish-expire-new 2011-07-19 11:00:08.000000000 +0100
@@ -109,6 +109,7 @@
$$Options{time} and $expire_time = parsedate($$Options{time});
$expire_time ||= time;

+my %recent;

if ($$Options{vault})
{
@@ -150,7 +151,20 @@
my ($created, $expired);
($created = $$expire{created}) =~ s/:\d\d$//;
($expired = $$expire{expire}) =~ s/:\d\d$//;
-
+
+ my $vault = $$expire{vault};
+ my $branch = $$expire{branch};
+
+ if ($recent{$vault}{$branch} eq $created)
+ {
+ printf "cannot expire %s:%s:%s It's the latest good image\n",
+ $vault,
+ $branch,
+ $$expire{image};
+ ++$unexpired{$vault}{$branch};
+ next;
+ }
+
if (!$unexpired{$$expire{vault}}{$$expire{branch}})
{
printf "cannot expire %s:%s:%s No unexpired good images\n",
@@ -224,6 +238,19 @@
$$summary{vault} && $$summary{branch} && $$summary{Image}
or return;

+ my ($vault, $branch, $success, $created, $recent);
+
+ $vault = $$summary{vault};
+ $branch = $$summary{branch};
+ $success = $$summary{Status} =~ /^success/ && -d ($path . '/tree');
+ ($created = $$summary{'Backup-complete'}) =~ s/:\d\d$//;
+ $recent = $recent{$vault}{$branch};
+
+ if ($success and (!defined($recent) or $recent lt $created))
+ {
+ $recent{$vault}{$branch} = $created;
+ }
+
if ($status == 0)
{
$$summary{Status} =~ /^success/ && -d ($path . '/tree')

( wyx v | 2011. 08. 30., k – 11:38 )

A Te barátod az egyszerű rsync, erre van kitalálva.

Ez a feljebb említett hardlinkes megoldást használja.

Használtam egy ideig, aztán rdiff-backup lett belőle.

rsnapshot-hoz még annyit, hogy akár a felhasználóknak is hozzáférést adhatsz a mentésekhez (mondjuk ro mounttal). A visszaállítás sima másolás. Ami nem tetszett akkor rajra, hogy a backup gépen rootként futkorászik.

( Fisher v | 2011. 08. 30., k – 12:53 )

Ha a teljes rendszervisszaállítás tényleg gyors kell hogy legyen _és_ belefér néha egy-egy kiesés, akkor pl. clonezillával érdemes lementeni a rendszerterületeket. Ez újraindítással jár, cserébe viszonylag biztos mentést csinál. Ezt érdemes havonta egyszer, vagy érdemi változtatások után megtenni.

E mellett lehet menteni a gépet bármelyik szimpatikus mentőmegoldással, én pl. a backuppc-t is tudom ajánlani, bár ez leginkább akkor kényelmes, ha sok gépet kell menteni, és olyanokat, amik nem mindig elérhetőek, pl. laptopok.

Ezt csak az tudja eldönteni aki az adott rendszert üzemelteti. Ha sok apró file van, akkor pl. ez lehet akár egy dovecot szerver is, tehát nem feltétlenül vastüdőt hajt a gép. Ha a cég elfogadja hogy havonta egyszer van fél órás kiesés mondjuk vasárnap reggel, akkor miért ne?

Éves szinten ez 1,5%(*) (tervezett, jó esetben üzemidőn kívüli) kiesés, cserébe a megbízhatóságért.

*) Jól számoltam?

"akkor pl. clonezillával érdemes lementeni a rendszerterületeket."

"E mellett lehet menteni a gépet bármelyik szimpatikus mentőmegoldással."

Lehet hogy homályosan fogalmaztam, de arra céloztam hogy az OS-t elég viszonylag ritkán menteni, viszont cserébe érdemes úgy, hogy hamar visszatölthető legyen (azaz ne kelljen pl. csak azért feltenni egy alap OS-t, hogy a mentést vissza lehessen tölteni, hanem azonnal rá lehessen borítani az image-t). Kétlem hogy 100G-s az OS amit használtok, de bármi lehet. És egy OS mentése ami mondjuk 4-5G szerintem belefér fél órába a reboot-save-reboot lépésekkel.

E mentés mellett szükség van az adatok (plusz etc., plusz logok, de talán ennyire már nem kell magyarázni) mentésére is, amire már "bármi" jó, mindenkinek megvan a maga kedvence, nyilván azt javasolja.

( fimikz | 2011. 08. 30., k – 13:00 )

fogsz egy ZFS-t, minden backup targetnek csinalsz egy fs-t rajta, rsync ramegy, majd snapshot utana, datestamppel ellatva. X idonel regebbi snapshotok torolhetoek. ha dedupot bekapcsolod, akkor a gepek kozotti azonos blokkok sem foglalnak extra helyet. takarekos, egyszeru.

( mr shadow v | 2011. 08. 30., k – 14:06 )

szábszkrájb
--
Imperare sibi maximum imperium est.

( uid_2716 | 2011. 08. 30., k – 16:40 )

Alapvetően az rdiff-backup-ot javasoltam volna, azonban látva az NFS-t és a sok apró file-t, valószínűleg a duplicity jobb lesz.

Előbbi ui. file-onként hasonlítja össze a két véget (metaadat szinten), míg az utóbbi, ha jól tudom, lokálisan állítja elő a növekményt egyetlen (opcionálisan titkosított) tar-ban, helyi szignatúra-állományok alapján, és a növekményt egyben tölti fel. Mindenesetre ne higgy nekem, próbáld ki mindkettőt.

Nem azonosak. Ugyanaz a csóka írta mindkettőt, így valószínűtlen, hogy átsiklott volna afelett, hogy másodjára írja meg ugyanazt :)

http://www.nongnu.org/rdiff-backup/features.html
http://duplicity.nongnu.org/features.html

Az alábbi az én értelmezésem. A duplicity-t még sosem használtam, az rdiff-backup-ot igen.

Az rdiff-backup a forrás- és a célkönyvtárat párhuzamosan, rekurzívan végignyalja, metaadat-eltérésre vadászva (mtime, file mérete stb). Ahol eltérést talál, ott a célt frissíti a forrásból (tartalmilag és metaadatban). A célban a korábbi változatot nem szimplán lecseréli az új változatra, hanem az rdiff algoritmussal egy különbséget képez a cél eggyel megelőző és a legfrissebb változata között, majd a különbséget tömörítve eltárolja. A cél így a backup végén a forrásnak egy tükre, azonban a korábbi cél-állapotokra (amelyek korábbi forrás-állapotok tükrei voltak) reverse rdiff-ekkel mutat vissza. Az rdiff-ek file-onként képződnek és tárolódnak.

A fentihez elég annyit tudni az rdiff-ről, hogy valamiféle bináris diff. A duplicity (általam vélt) működéséhez azonban egy kicsit jobban bele kell nézni az rdiff-be. Az rdiff használata az alábbi lépésekből áll:

  1. Kiinduló file-ból szignatúra (lenyomat) készítése. A szignatúra lényegében annyi, hogy a file-t darabokra szedjük, minden darabra kiszámolunk külön-külön egy strong hash-t, illetve egy gyenge gördülő hash-t is (ld később), és ezeket a hash-eket egy tömbben elmentjük.
  2. A szignatúrát odatesszük az új (target) file mellé. A szignatúra és a target file kettőséből előállítható a delta. Ez úgy működik, hogy beolvassuk a felmásolt szignatúrát, majd végignyaljuk a target file-t. A végignyalás közben byte-onként számolunk egy csúszóablakra egy rolling checksum-ot. Ez a checksum gyenge (sok az ütközés), azonban rolling, és így gyors számolni, és amikor egy byte-nyit odébblökjük a csúszóablakot a target-en, akkor a rolling checksum-ot könnyű frissíteni. A rolling checksum minden értékére (minden byte-pozíción) megnézzük, van-e ilyen rolling checksum a szignatúrában. Ha van ilyen találat, akkor kiszámoljuk a csúszóablakra az erős hash-t is. Ha még ez is stimmel, akkor a target-ben találtunk egy olyan blokkot, ami a forrásban megvan. Így a deltába egy copy utasítást írunk bele: "másold a forrásból ezt a blokkot a célba". A strong hash találatok közötti (= a forrásban meg nem lévő) adatokat pedig "literal" command-ok formájában tesszük a deltába (vagyis az ilyen target-byte-sorozat "szó szerint" belekerül a deltába).
  3. A deltát visszamásoljuk az eredeti file mellé. Itt a deltát utasítás-folyamként végrehajtjuk: amikor copy utasítást találunk, akkor a forrásból másolunk a kimeneti file-ba, amikor pedig literal utasítást, akkor a deltából másolunk a kimeneti file-ba.

A duplicity az alábbi elven működik (sejtésem szerint...):

  1. Legelső alkalommal (full backup) egy teljes tar-t készítünk, plusz minden állományról elkészül a szignatúra is. A teljes tar-t titkosítva és integritás-védve felmásoljuk a nem megbízható távoli szerverre. A szignatúra-halmazt helyben megőrizzük, de a redundancia kedvéért szintén titkosítva és védve szintén felmásoljuk külön állományként a távoli szerverre. Természetesen a szignatúrahalmaz-file mérete csak egy töredéke a teljes tar méretének.
  2. Amikor növekményesen frissítünk, akkor a bemenő adataink a (frissült) forrásunk és a helyben őrzött (vagy távolról visszaállított) szignatúra-halmaz, amely a forrásunk korábbi állapotának felel meg. Ebben a lépésben előállítjuk a deltákat, amelyek így a (csak a távolban meglévő) korábbi forráslenyomatból képesek majd visszaállítani a jelenlegi forrásállapotot. A módosult file-ok szignatúráit szintén újraszámoljuk. Feltöltésre a szignatúra-növekmény és az adatnövekmény kerül.
  3. Fontos, hogy a szignatúrahalmaz csak növekmény képzéséhez kell, helyreállításhoz nem.

Ha jól sejtem, a duplicity-nél a delták nem fordított irányúak, vagyis a target sosem friss mirror, hanem egy régi full backup, plusz néhány növekmény. Így a helyreállítás tovább tart.

De mondom, sosem használtam a duplicity-t :)

Az rdiff-backup és a duplicity különbségei tehát nagyjából:

  • Az előbbi párhuzamosan olvassa végig a forrást és a célt, és metaadat-eltérésre vadászik. Az utóbbi a növekményt kizárólag helyi adatok és tartalomváltozás alapján állítja elő. Emiatt az utóbbinak sokkal kisebb a latenciája.
  • Az rdiff-backup ment metaadatokat, a duplicity (úgy tűnik...) nem. Vagy legalábbis nem tudom.
  • Az rdiff-backup nem támogatja a cél titkosított tárolását (egyéb segítség nélkül), a duplicity igen. Persze sshfs-en keresztül felcsatolhatunk egy távoli file-t loop device-nak, amire tehetünk LUKS-ot, amire formázhatunk egy ext2-t, amire helyben tehetünk rdiff-backup-ot...

Ha az NFS szerver a szomszéd gépteremben van, akkor az rdiff-backup akár ideális is lehet, mivel kifejezetten készül arra, hogy a cél alatti fs nem támogat ugyanannyi metaadat-típust, mint a forrás.

Pontatlanságokért bocsánat stb. stb., ez csak egy fésületlen braindump volt.

( handler | 2011. 08. 30., k – 22:52 )

Mennyire sok es kicsi filek? ? 1 millio 10 millio 100 millio file? Esetleg megtobb ? Mennyi az osszmeret?