Ma refer in principal la MySQL, PostgreSQL si MongoDB. Folositi un serviciu sau aveti script-uri proprii care, de exemplu, se folosesc de mysqldump, pgdump, etc pentru a face backup bazelor de date din productie?
1 Like
Personal script-uri propri
script propriu cu upload pe s3 a dump.sql.gz
Ceva de genul:
#!/bin/bash
BACKUPDIR=/home/backup/mysql/
TIMESTAMP=$(date +"%Y.%m.%d.%H")
mkdir -p "$BACKUPDIR" || exit 1
cd "$BACKUPDIR" || exit 1
for db in $(mysql -pXXXX -Bqse 'show databases') ; do
mysqldump -pXXXXX -aceFlq $db | bzip2 >"${db}_${TIMESTAMP}.sql.bz2"
done
Apoi de pe alt server, transfer fișierele astea și rețin cele mai recente 10 fișiere pt fiecare DB în parte
1 Like
mysqldump plus un script
Pentru masina locala nimic, nu vad nevoie. Cel mult un mysqldump la nevoie. Pentru remote script propriu. @Cornel cu parola in linia de comanda ramane in ~/.bash_history sau ~/.histfile 
. Nu-i perfect, n-am error checking, dar isi face treaba de fiecare data.
$ cat backup.sh
#!/usr/bin/env bash
backup_db() {
TIMESTAMP=$(date '+%F_%H%M%S')
DBPASS="foobarbaz"
for DB in first second third
do
(ssh user@host "mysqldump -p $DB" <<< "$DBPASS") | gzip --best > "./backups/${DB}_${TIMESTAMP}.sql.gz"
done
}
if [ -z "$1" ]
then
echo "Usage: $0 [ database ]"
exit -1
fi
case "$1" in
db|database) backup_db ;;
esac
Mysqldump e cea mai proasta idee de a face backup. By default face lock la tabele, deci daca faci asta in prod cu o baza de date care chiar are trafic risti sa crape ceva grav. Zic din experienta asta.
Daca ai mysql, ori dai bani pe solutia enterprise care are un client de streaming backup. Ori folosesti uneltele de la Percona pentru streaming backups. E mai complicat, dar streaming backupul vine cu foarte multe beneficii. E rapid, safe si mai ales nu risti sa iti crape nimic in prod 
3 Likes
Sau faci backup-ul de pe un Slave, unde locking-ul nu e o problema.
Altfel Percona Xtrabackup e misto, dar spre rusinea mea recunosc ca tot scripturile bash + mysqldump sunt baza. Cu prima ocazie o sa fac un v2 al scripturilor de backup si atunci sper sa adresez si asta.
Pentru rotatia backup-urilor tot custom scripts folositi?
E o soluție foarte practică. Nu toată lumea are trafic greu la ora 4 dimineața cînd rulează scriptul.
Daca toate tabelele sunt InnoDB se poate face hot backup direct din mysqldump, fara lock.
4 Likes
Daca folosesti AWS/GCP/Azure iti faci backup la 30 minute la instanta sau daca folosesti serviciul lor de Mysql/PostgreSQL/SQL totul e automat (la Google e inclus in pret pana la 100Gb), platesti doar stocarea.
Altcumva iti utilizezi resursele serverului pentru a face backup, iar la o baza de date de 10Gb conteaza.
Daca toate tabelele sunt InnoDB se poate face hot backup direct din mysqldump, fara lock.
Si asta garanteaza consistenta datelor si finalizarea tranzactiilor?
The
--single-transactionflag will start a transaction before running. Rather than lock the entire database, this will let mysqldump read the database in the current state at the time of the transaction, making for a consistent data dump.
Pana acum n-am avut probleme cu inconsistenta datelor folosind --single-transaction.
2 Likes
Nici eu, fac astfel backup unei baze de date de cativa zeci de GB si verific fiecare dump.
Cum îl verifici?
Import baza de date pe un alt server si o utilizeaza developerii zilnic pentru development si debugging.
1 Like
--single-transaction e o optiune buna dar asa cum spune si @patkoscsaba pot exista situatii de inconsistenta. Sa zicem ca tranzactiile sunt totul sau nimic dar pot exista o serie de comenzi sql in cascada cu intarziere intre ele si la un moment dat unele dau fail in timpul backup-ului.
Cred ca pentru aplicatii cu trafic serios pe baza de date nu e o tragedie daca dai stop la aplicatie pentru mentenanta in anumite momente planificate cu un mesaj corespunzator. O fac si platformele mari, am dat si eu de cateva ori peste mentenanta de la Github sau Sourceforge (de regula in weekend) cand nu mai mergea aproape nimic din ce ma interesa…
1 Like