Webszerver mentése, mit és hogyan?

Ubuntu Linux

Sziasztok!

Van egy webszerver amiről jó lenne valamiféle backupot csinálni. A szerveren MySQL, Apache2, PHP5, postfix + courier, ftp, svn szolgáltatás fut.

A célterület jelenleg egy FTP. Adódik a kézenfekvő lehetőség, hogy rsync, viszont mit érdemes menteni és hogyan, hogy a legegyszerűbb legyen a disaster recovery?

Van rá esetleg bejáratott scriptetek?

Előre is köszönöm

  • 6600 megtekintés

( gergelykiss | 2013. 01. 30., sze – 09:41 )

Talán a legegyszerűbb megoldás távoli mentést készíteni SSH-n keresztül egy shell scripttel, ami tömörített tar fájlba pakolja a mentendő adatokat. Nálunk például egy távoli backup szerveren fut egy ütemezett szkript, ami ssh-n keresztül remote futtatja a mentést végző parancsokat, a kimenetet pedig egy mentési célokra dedikált, redundáns háttértárolóra menti el.

DB-mentéshez használhatók a különféle DB-szerverek beépített eszközei (pl. mysqldump, pg_dumpall), majd az így készült dumpok szintén becsomagolhatók egy tar fájlba.

Amiről mindenképp érdemes mentést készíteni:

- csomaglista ("dpkg -l" kimenete), ennek segítségével egy összeomlás esetén tudni fogod, hogy pontosan milyen csomagok, és azoknak milyen verziói voltak telepítve
- /etc teljes tartalma
- adatbázisok
- webszerver docroot-ok, ezt lehet egyben is menteni, vagy külön, site-onként is, ahogy kényelmesebb
- ha vannak saját szkriptjeid, vagy egyedi alkalmazások a szerveren, akkor azokat a könyvtárakat is érdemes menteni, ahol ezek vannak (pl. /usr/local/bin, /opt)
- ha vannak mailboxok is a szerveren, akkor a maildir-eket vagy mailbox fájlokat is ajánlott menteni (pl. /var/spool/courier)

A mentéshez használt szkriptjeinket sajnos nem oszthatom meg, tippeket viszont szívesen adok, ha van kérdésed.

Én is valami ilyesmire gondoltam, hogy a dbket, svn repokat a beépitett toolokkal dumpolom (svndump, mysqldump), persze inkrementálisan és mondjuk heti 1 full, utána átjuttatom a másik gépre.

Köszönöm a tanácsokat.
-------------------------
127.0.0.1 SWEET 127.0.0.1
AMD Athlon X2 245E@3,1 GHz OC, MSI Radeon 6770 1 Gb GDDR5, Seagate Barracuda, Windows 7 Enterprise

Virtuális gép, van a VHD-ról egy teljes mentés azutánról amikor minden be lett lőve. Végülis csak a felhasználói adatokról, adatbázisokról kell mentés.
-------------------------
127.0.0.1 SWEET 127.0.0.1
AMD Athlon X2 245E@3,1 GHz OC, MSI Radeon 6770 1 Gb GDDR5, Seagate Barracuda, Windows 7 Enterprise

( pityulaman1983 v | 2013. 01. 30., sze – 09:58 )

Kicsit off, de az elkészült backupokat szoktátok ellenőrizni, hogy visszaállíthatóak-e?

-----------
"640GB sokmindenre elég"

( freeoli v | 2013. 01. 30., sze – 10:20 )

Ez egész jó kis szkript generátor (tessék küldeni egy tripla facepalmot) :D :

http://bash.cyberciti.biz/backup/wizard-ftp-script.php

Ezt egy pár dologgal kiegészítettem és reszelni kellett mert az ncftp se minig úgy eszi a paramétereket meg a speciális karaktereket (- _ :D) meg lemezterület állapot meg ami még eszembe jutott. Igazából alapnak használható ha már ennyire kérdezed.

Ennél csak komplikáltabb megoldások vannak de a duplicity nagyon bevált még.

( Fisher v | 2013. 01. 30., sze – 11:08 )

Ha a disaster recovery a szempont és virtuális gép, akkor a virtuális gépet kell menteni.
A kérdéses pontok, hogy mennyi idő van a visszaállásra és mennyi idő és hely, sávszélesség van a mentésre.

Mondjuk havonta egyszer leállásos mentés a virtuális gépről, közben pedig a napi mentések, amire én backuppc-t használok.

Sajnos nem megoldás a virtuális gép mentése, kb 1 óra a mentése leállítással, mentéssel, inditással együtt.

Napi/heti/havi mentésre gondoltam az adatokról. napi incr, heti full, havi ful.
-------------------------
127.0.0.1 SWEET 127.0.0.1
AMD Athlon X2 245E@3,1 GHz OC, MSI Radeon 6770 1 Gb GDDR5, Seagate Barracuda, Windows 7 Enterprise

Akkor viszont nem szempont, hisz rossz esetben vissza kell tölteni egy full(*) és öt (hat?) napi incr mentést. Ezen valamennyit segít, ha differential mentést csinálsz, de akkor is min. 2x kell visszatölteni.

Ha meg nem fér bele a vasárnap hajnali 3-4 közötti havi egy leállás, akkor ott már más kérdések is felmerülnek majd :D

*) És persze reménykedni hogy a full mentés fel is fog bootolni, nem kell először a VMDK-t visszatuszkolni.

( zeller | 2013. 01. 30., sze – 11:18 )

DR-hez full backup a DB-ről LVM snapshot használatával (flust tables with read lock, majd snapshot megcsinál, unlock tables, mount, rsync, snapshot eldob, örül), utána meg a binlogok folyamatos mentése merül fel használható ötletként. A full backup gyakoriságát meg az alapján döntsd el, hogy mennyi idő van a visszaállításra.
A fájl-alapú tárolásnál is előszedhető az LVM snapshot "trükk", de ott igazából egy find | cpio is "megteszi" - kérdés, hogy milyen gyakran változnak a fájlok.
Ami biztos, hogy minden szolgáltatást (és a hozzájuk tartozó területet) külön mentési folyamatként illendő kezelni.

( zx81 v | 2013. 01. 30., sze – 11:25 )

Én az rdiff-backupot használom, sok lehetősége van és egyszerű mint a faék. Szintén adott A és B szerver, B szerverre megy minden mentés az adott A szerverről. Lehet rsa kulccsal és egyéb más módon átmozgatni a menteni kívánt dolgokat.
url: http://unixlinux.tmit.bme.hu/Rdiff-backup
---
debian squeeze

( neutrino v | 2013. 01. 30., sze – 13:52 )

Alakul a script gyűjtemény, viszont belefutottam egy hibába. A maileket mivel lehetne gyorsan összedobni egy fájlba? Kb 1 GB mail van, és a tar -cpzf tetű lassú
-------------------------
127.0.0.1 SWEET 127.0.0.1
AMD Athlon X2 245E@3,1 GHz OC, MSI Radeon 6770 1 Gb GDDR5, Seagate Barracuda, Windows 7 Enterprise

Én backuppc-vel. Az incr. mentés 25-120 perc, a full az öt óra. Mondjuk ebben minden szirszar benne van, az OpenVZ konténerek, mysql, logok, stb., ami összesen olyan 250G.

Ahol tisztán csak maildirt kell menteni ott (is) jól jöhet egy dedup fs, mert ha jól emlékszem akkor a maildir a fájlnévben tárolja a metadatát (olvasott-e vagy nem meg ilyenek), így tartalmilag 100%-ig egyező fájlok akár többször is szerepelhetnek a mentésben.

"Ahol tisztán csak maildirt kell menteni ott (is) jól jöhet egy dedup fs,"

Maildir-re abszolut nem jó a dedup. A levelek átlag pár Kb méretűek, 100%-ban egyezőek nincsenek.
Ellenben egy tömörítő fájlrendszer már annál hatásosabb.
Pl. egy 108GB-nyi maildirt 57Gb-n tárol egy ZFS, gzip-el (level-6) tömörítve.
Ugyanez dedup-al több mint 90Gb-t igényelt.

Egyszerű rsynccel, egy külső nasra. Naponta inkrementális mentés van, hétvégénként pedig egy teljes.

Ez a teljes mentés: (persze az előző hetire)
sent 1.45M bytes received 6.94G bytes 13.85M bytes/sec
total size is 127.54G speedup is 18.37

Ez meg az inkrementális, ez szinte semmi:
sent 1.30M bytes received 3.50G bytes 14.64M bytes/sec
total size is 110.62G speedup is 31.55

Nem kétlem: 


root@mailstore:/home# df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vz_vg-mailstore_lv
                      243G  117G  114G  51% /home

De tisztán okoskodás útján:

- az első mentés esetén a tar gyorsabb: az rsync minden fájlt megnyit - olvas, a régi helyen, megnyit - ír az új helyen, a tar csak egy fájlt ír
- a második mentés esetén a fene tudja, a tarnak is meg lehet adni hogy az időpont (fájl dátum) utániakat tegye a tarba

Én az rsyncet azért szeretem, mert könnyen lehet folytatni a félbehagyott mentést. És mert azt ismerem kevésbé rosszul :D

Ha tar-olsz, tarolj "home"-onként, ha az rsync vagy egyéb megoldás nem jó.
Legalább visszaállításkor sem kell az egész mail backupot kicsomagolni, csak azt a backupt, amelyik a problémás useré.

pl (csak fejböl, nem biztos, hogy így ez teljesen jó is lesz):
for userhome in "/home/*"
do
tar czfp $userhome-mail.tar.gz $userhome
done

( maszili | 2013. 01. 30., sze – 19:49 )

Ha fájlszintű mentésre van szükség akkor szerintem arra a legjobb eszköz az rsync.

Több mint százmillió file, 1118 GByte, napi szinkronja ~6 óra alatt szokott lemenni minden éjféltől.
Tehát minden alakalommal egy teljes szinkron készül (az összes file aznapi állapota) a komplett rendszerről hardlinkek segítségével deduplikálva több napra/hétre/hónapra visszamenőleges állapotokkal.

Egy file vagy akár a teljes rendszer visszaállítása is nagyon gyors és egyszerű egy megfelelően megparaméterezett ellenkező irányú rsync szinkronnal.

--
maszili