Jak zálohujete databázi? Znáte phpMyBackupPro?

cron, mysqldump, tar -> datum v názvu, poslat to někam po síti a jsem v pohodě :-)))

presne tak, taky nechapu proc zalohovat v nejake PHP sracce, kdyz to de pres command linu

zeby nemali vsetci pristup k takymto nastrojom? ;-)

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).

u velkych db je fakt dobry pouzivat file per table :). zkus si nekdy obnovit nekolikagigovou JEDNOSOUBOROVOU DB ve ktery je chyba :).

mohl by jste nastinit jak to delate? jen nakopnot...

Usage: mysqldump [OPTIONS] database [tables]
OR mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]
OR mysqldump [OPTIONS] --all-databases [OPTIONS]

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

my si zalohujeme databazi pomoci funkce flashcopy diskoveho pole made by ibm. Nase nejvetsi db ma neco pres 2 TB a flashcopy trva mene nez 30 sekund.

Mam rad tuhle technologii.

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...

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.

profi riesenie - vypalovat na dvdcka... :-) databaza moze byt konzistentna aj v pripade replikacie (zalohujem repliku namiesto original db).

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.

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.

Hovori to dost vela o neprofesionalnom/amaterskom pristupe vasej spolocnosti. Moj kolega by povedal, ze "su to amateri". Nechcel by som byt vasim zakaznikom.

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).

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.

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"

Vynikajici skript. Diky.

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.

Backup zivej databazy o velkosti 1gb je pomoci mysqldump trochu problem, kedze sa dostanete do situacii, kedy je nejaka cast uzamknuta a backup jednoducho nedokoncite. Rozumnejsie je mat urobenu replikaciu a zalohovat repliku. Po zalohovani sa replika zosynchronizuje a vy zijete v pohode.

Používáme standardně InnoDB a mysqldump s parametrem --single-transaction. DB má okolo 20GB a backup v pohodě. Zazálohovaný dump hned následně naléváme na testovací stroj a vždy OK.

Ale jak píšete, to je řešení pouze pro InnoDB a to musíte mít jistotu, že všechny tabulky jsou InnoDB případně BDB, jinak to nefunguje. IMHO správnější je replikace, ale není to sranda, to nastavit.

preco? mne prisla replikacia databaz ako celkom jednoduche riesenie.