Pokud provozujete například nějakou webovou službu, je vhodné zálohovat databázi, na které celý software stojí. Existuje několik způsobů zálohy, server Linux.com představil nástroj phpMyBackupPro, který vše zvládne rychle a především bez námahy. Psali jsme už také o programu phpMinAdmin od českého autora Jakuba Vrány, který umí také mimo jiné zálohovat databáze.
Jak zálohujete databázi? Znáte phpMyBackupPro?
6. 3. 2008
25
nových názorů
-
-
Kvakor (neregistrovaný)Tar? Neni spis myslen gzip ci bzip2? mysqldump prece produkuje jen jeden dump do stdout.
Osobne bych jeste doporucil nice a ionice, pak si vetsinou ani nevsimnete, ze se nejaka zaloha dela (tedy, az na okazmik, kdy se zrovna trefite do okamziku, kdy je vami pouzivana tabulka zrovna zamncena). -
Tuxik (neregistrovaný)napriklad takto
for db in `echo 'show databases'|mysql -N`; do
echo "${0##*/}: backing up sql $db"
mkdir -p $DUMPDIR/$db
for tb in `echo 'show tables'|mysql $db -N`; do
echo "${0##*/}: backing up sql $db/$tb"
nice mysqldump -K -l -i $db $tb|nice gzip > $DUMPDIR/$db/$tb.sql.gz || \
echo "${0##*/}: warning: mysqldump $db/$tb failed"
sleep 5
done
done -
Neldor (neregistrovaný)Tak s tim bych ty moc nemachroval, z nekolika duvodu:
1. Flashcopy neni nic jinyho nez kombinace copy-on-write snapshotu s kopirovanim dat na pozadi. Takze za tech 30s se udela snapshot, bravo, ovsem dalsich X hodin pak srotuji disky na plne pecky kopirujici zbytek dat na pozadi, cili bych si dvakrat rozmyslel to provozovat v produkcni spicce.
2. Tezko rikat "zaloha" necemu, co je na ulozene na tom samem zarizeni. I sebedrazsi storage system muze prijit o nejaka data pri trose smuly, a pri trochu vetsi smule to budou data jak primarnich dat, tak i tech zaloznich.
3. Ten flashcopy snapshot vi kulove o konzistenci DB, takze to ze mate funkcni snapshot backup jeste neznamena, ze je ta "zazalohovana" DB v konzistentnim stavu. Uz jste z toho nekdu zkusili tu DB obnovit? ;-).
Takze ve vasem vlastnim zajmu doufam, ze nespolehate jen na flashcopy, ale mate i nejake (pokud mozno offsite) zalohy s pouzitim zalohovacich nastroju urcenych primo pro danou DB... -
LENIN POWER! (neregistrovaný)1. Default je to nastavene tak, ze si to vezme max 10% vykonu pokud je disk busy, takze bych se s tim vubec netrapil
2. pochopitelne mame i migraci jiz vytvorenych zaloh na jina zarizeni. Brigadnice to kuprikladu nechavame vypalovat na DVDcka.
3. DB v konzistentnim stavu byt nemusi pokud si zazalohujete i logy. Typicky klasicky online backup je zatarovat .db soubory zajizdy a pak k tomu pridat logy co se behem zalohovani vytvorily. Databaze po obnove bude vyzadovat rollforward recovery.
Databaze je konzistentni pouze kdyz je offline nebo kdyz ma shared locky na vsech TS. Coz neni prakticky nikdy.
4. Nase db podporuje primo flashcopy, takze se daji flashcopy zalohy dokonce spravovat s vyuzitim jejich administrativnich toolu. -
Trident (neregistrovaný)Njn. Tak u nas diky nizkym platum jeste neni pracovni sila tak draha, aby se vyplatilo kupovat paskovou mechaniku pripadne replikator s podavanim cdcek. Perfektni plytvani lidskym potencialem. Jen co je pravda. Manazerovi za usi. Je to tzv. cinske reseni. V cine i to co muzou delat stroje tak na to se poridi zamestnanec protoze je tak silene levny ze se to vyplati.
-
LENIN POWER! (neregistrovaný)Kopirovat databaze na DVD pro offsite backupy je typicka prace pro absolventky ekonomky, ktery potrebuji papir jako ze nekde pul roku delaly aby pak nesli nejakyho cvoka co si je zamestna. Ja zasadne zamestnavam lidi s aspon 5ti letou praxi.
Co ale s nima delat jinyho, kdyz jsou uplne k nicemu. Telefonovat poradne neumi, komunikovat se zakaznikem neumi, tak nam tu delaji nekvalifikovanou praci, vari kafe a zalevaji kytky, rozesilaji upominky a chodi vyzvedatat baliky na celnici. Browsowani webu s ruznyma online seznamkama atd to jim jde ale vyborne.
To neni plytvani lidskym potencialem, tyhle lidi jsou uplne k nicemu. Taky je dobry porizovat doklady tak, ze se daji cinskym holkam co maji net, posle se jim tam krabice dokladu a ta Sunovska javastation nebo jak se to ted jmenuje, tu staci jen zapnout a vlozit kartu a hned muze zacit delat. -
LENIN POWER! (neregistrovaný)2TB databaze je asi 35 DL DVDcek a je to udelany tak za 2 dny prace. Spolehlivost je vetsi nez u pasek. Neni duvod proc pouzivat jine reseni, kdyz to navic dela pracovni sila, ktera je zadarmo a stejne by misto toho cumela na youtube.
Vam pripada profesionalni platit pul mega za neco co muzete mit zadarmo? Tady se asi neshodneme. -
skor som reagoval na neprofesionalitu vo vztahu k zamestnancom. Zamestnavat niekoho len na to, aby varil kafe, napaloval dvdcka je zly byznis. Samozrejme, paskove kniznice su drahsia zalezitost, no dovolim si tvrdit, ze z dlhodobeho hladiska vyhodnejsia investicia ako zamestnavat napalovacov dvd (pokial nechcete zverit svoje firemne data cinskym sudruhom). -
LENIN POWER! (neregistrovaný)Ne to je naopak dobry byznis, protoze my toho cloveka neplatime.
Paskovou knihovnu jsme pred par lety meli a kdyz zastarala tak jsme se rozhodli ze uz dalsi nechceme, bylo to nespolehlivy a pomaly. Proc jeste dneska zalohovat na pasky, kdyz muzeme mirror/split zalohovat na disky, ty jsou tak levny a rychly ze to az neni hezky.
ted jsem zkusil backup 3gb db2 databaze a bylo to 1m50s. backup i db byla na stejnym 7500 rpm disku. Tedy ta nejhorsi kombinace, ktera muze v praxi nastat.
pro srovnani pg_dump 8.2.6 databaze na raid1 poli do /dev/null 7:07, pokud se dumpuje do souboru tak dump ma 2.5GB. Tady nazorne vidite, ze je pgsql dost pomalej. s dumpovanim na disk 10:28 -- to mame na lepsim hw 5x pomalejsi nez db2.
V praxi je ale rychlost obnovy mnohem dulezitejsi nez rychlost zalohy. Ta je u pgsql delala 57:04.37, tedy skoro hodinu na naloadovani 2.5GB. DB2 dela priblizne 1GB/minutu. Trochu dost rozdil.
Docela by mne zajimaly nejaky cisla pro mysql pro srovnani. -
edois (neregistrovaný)pokud mi staci jednou za den, tak: /usr/local/bin/mysql-backup.sh:
#!/bin/bash # base directory for mysql backups BASEDIR=/home/backup/mysql # today date in format YYYY-MM-DD DATE=`date +%Y-%m-%d` # database list (without `mysql` and `information_schema` databases) DATABASES=`echo "SHOW DATABASES" | mysql | sed 1d | grep -v ^mysql$ | grep -v ^information_schema$` # destination directory DSTDIR=$BASEDIR/$DATE # if not force if [ "$1" != "-f" ]; then # if DSTDIR already exists if [ -e $DSTDIR ]; then echo "Today backup already exists, use -f to override" exit 0 fi fi # create DSTDIR (if doesn't exist) mkdir -p $DSTDIR # dump all the databases for DATABASE in $DATABASES; do echo -n "Dumping database $DATABASE... " ( mysqldump --single-transaction -R $DATABASE > $DSTDIR/$DATABASE.sql ) && ( echo -n "dumped, gzipping... " ( gzip -f $DSTDIR/$DATABASE.sql ) && ( echo "ok" ) || ( echo "error gzipping file $DSTDIR/$DATABASE.sql" ) ) || ( echo "error dumping database $DATABASE" ) done # finished echo "All databases have been backed up" -
lol (neregistrovaný)ja normalne rsyncujem home adresar mysql s binarnymi datami a nikdy s tym nebol problem ... ked bolo treba vratit data dozadu, stoplo sa mysqld, nascpckovali, nachownovali a nachmodovali sa subory, spustilo sa mysqld a bolo. Pre istotu som vzdy potom este spustal mysqlcheck, ci nahodou v dobe rsyncovania nebolo nieco otvorene, ale nikdy sa nic podobne nestalo - databazy vzdy fungovali.
Rsync mysqldumpu by bol asi elegantnejsi, ale je to imho zbytocne duplikovanie dat, cize odnasaju to disky. Hlavne ak sa robi backup 2x denne tak ako u mna. Je tam sice raid, ale radsej mam data geograficky inde - tak ako tu uz bolo spomenute, zalohovat na samotny disk/pole je hlupost, kedze sebelepsie pole zo sebelepsich diskov raz zlyha. Moja skusenost je taka, ze na raid5ke odisli 2 disky z 3 (druhy odisel v dobre rekonstruksie na spare disk), takze totalna strata udajov.
