Andmebaasi varukoopiad: mysqldump, pg_dump, cron

curl -sSL https://cp.lv/scripts/bekapy-bazy-dannyh.sh | sudo bash

wget -qO- https://cp.lv/scripts/bekapy-bazy-dannyh.sh | sudo bash

#!/usr/bin/env bash
# Creates a MySQL backup script, the first dump and a cron job
set -e

SCRIPT=/opt/scripts/mysql-backup.sh
BACKUP_DIR=/var/backups/mysql

# 1. Directories for the script and the dumps
sudo mkdir -p /opt/scripts "$BACKUP_DIR"

# 2. Create the backup script itself (quoted 'EOF': variables expand at run time)
sudo tee "$SCRIPT" > /dev/null << 'EOF'
#!/bin/bash
set -euo pipefail
DB_NAME="app_db"
DB_USER="backup_user"
BACKUP_DIR="/var/backups/mysql"
KEEP_DAYS=7
DATE=$(date +%F_%H-%M)
mkdir -p "$BACKUP_DIR"
mysqldump --single-transaction --quick --user="$DB_USER" \
  "$DB_NAME" | gzip > "$BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz"
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +$KEEP_DAYS -delete
EOF
sudo chmod +x "$SCRIPT"

# 3. Take the first backup right away
sudo "$SCRIPT"

# 4. Cron job: every day at 03:30
echo "30 3 * * * root $SCRIPT >> /var/log/db-backup.log 2>&1" | sudo tee /etc/cron.d/db-backup > /dev/null

echo "Done: script $SCRIPT created, first dump in $BACKUP_DIR, cron configured."

Andmebaasi varukoopia on see, mis päästab projekti ketta rikke, eksliku DROP TABLE või ebaõnnestunud migratsiooni korral. Ükski majutus ei võta sinult ära vastutust varukoopiate eest: hoia koopiaid ja kontrolli nende taastamist. Allpool on töötavad skriptid MySQL-i/MariaDB ja PostgreSQL-i jaoks koos automaatse käivitusega cronist.

Usaldusväärse varukoopia põhimõte

• Regulaarsus — ajakava järgi, ilma käsitsi sekkumiseta.
• Rotatsioon — hoida N viimast koopiat, vanad kustutada.
• Väline hoidla — kopeerida dumbid teise serverisse või objektihoidlasse, mitte ainult samale kettale.
• Taastamise kontroll — aeg-ajalt taastada dump testandmebaasi.

MySQL-i/MariaDB varundamine

Utiliit mysqldump loob loogilise dumbi — SQL-faili kõigi andmetega. Loo fail /opt/scripts/mysql-backup.sh redaktoris (nano, vim või mcedit):

sudo mkdir -p /opt/scripts
sudo nano /opt/scripts/mysql-backup.sh

Skripti sisu:

#!/bin/bash
set -euo pipefail

DB_NAME="app_db"
DB_USER="backup_user"
BACKUP_DIR="/var/backups/mysql"
KEEP_DAYS=7
DATE=$(date +%F_%H-%M)

mkdir -p "$BACKUP_DIR"

mysqldump --single-transaction --quick --user="$DB_USER" \
  "$DB_NAME" | gzip > "$BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz"

# kustuta koopiad, mis on vanemad kui KEEP_DAYS päeva
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +$KEEP_DAYS -delete

Või loo skript tervikuna ühe käsuga — kopeeri ja kleebi konsooli (jutumärgid 'EOF' on olulised: $-muutujad peavad jääma skripti, mitte praegu avanema):

sudo tee /opt/scripts/mysql-backup.sh > /dev/null << 'EOF'
#!/bin/bash
set -euo pipefail

DB_NAME="app_db"
DB_USER="backup_user"
BACKUP_DIR="/var/backups/mysql"
KEEP_DAYS=7
DATE=$(date +%F_%H-%M)

mkdir -p "$BACKUP_DIR"

mysqldump --single-transaction --quick --user="$DB_USER" \
  "$DB_NAME" | gzip > "$BACKUP_DIR/${DB_NAME}_${DATE}.sql.gz"

find "$BACKUP_DIR" -name "*.sql.gz" -mtime +$KEEP_DAYS -delete
EOF
sudo chmod +x /opt/scripts/mysql-backup.sh

Lipp --single-transaction teeb järjepideva hetktõmmise tabeleid lukustamata (InnoDB puhul). Et parooli skriptis mitte hoida, loo fail ~/.my.cnf õigustega 600. Ava see redaktoris:

nano ~/.my.cnf

Faili sisu:

[client]
user=backup_user
password=StrongPassword123!

Või loo fail ühe käsuga — kopeeri ja kleebi konsooli:

tee ~/.my.cnf > /dev/null << 'EOF'
[client]
user=backup_user
password=StrongPassword123!
EOF
chmod 600 ~/.my.cnf

Tee skript käivitatavaks:

chmod +x /opt/scripts/mysql-backup.sh

PostgreSQL-i varundamine

Analoogne skript pg_dump-i peal (custom-formaat on osaliseks taastamiseks mugavam). Loo fail /opt/scripts/postgres-backup.sh redaktoris:

sudo nano /opt/scripts/postgres-backup.sh

Skripti sisu:

#!/bin/bash
set -euo pipefail

DB_NAME="app_db"
BACKUP_DIR="/var/backups/postgres"
KEEP_DAYS=7
DATE=$(date +%F_%H-%M)

mkdir -p "$BACKUP_DIR"

pg_dump -Fc "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}_${DATE}.dump"
find "$BACKUP_DIR" -name "*.dump" -mtime +$KEEP_DAYS -delete

Või loo skript tervikuna ühe käsuga (jutumärgid 'EOF' hoiavad $-muutujad skripti sees alles):

sudo tee /opt/scripts/postgres-backup.sh > /dev/null << 'EOF'
#!/bin/bash
set -euo pipefail

DB_NAME="app_db"
BACKUP_DIR="/var/backups/postgres"
KEEP_DAYS=7
DATE=$(date +%F_%H-%M)

mkdir -p "$BACKUP_DIR"

pg_dump -Fc "$DB_NAME" > "$BACKUP_DIR/${DB_NAME}_${DATE}.dump"
find "$BACKUP_DIR" -name "*.dump" -mtime +$KEEP_DAYS -delete
EOF
sudo chmod +x /opt/scripts/postgres-backup.sh

PostgreSQL-i parooli hoitakse failis ~/.pgpass (õigused 600). Ava see redaktoris:

nano ~/.pgpass

Faili sisu (formaat host:port:db:user:password):

localhost:5432:app_db:backup_user:StrongPassword123!

Või loo fail ühe käsuga:

tee ~/.pgpass > /dev/null << 'EOF'
localhost:5432:app_db:backup_user:StrongPassword123!
EOF
chmod 600 ~/.pgpass

Ajakava cronis

Ava selle kasutaja crontab, kelle all skriptid töötavad:

crontab -e

Lisa tööd — igapäevane varukoopia kell 3:30 öösel:

30 3 * * * /opt/scripts/mysql-backup.sh >> /var/log/db-backup.log 2>&1
30 3 * * * /opt/scripts/postgres-backup.sh >> /var/log/db-backup.log 2>&1

Kontrolli, kas töö salvestus: crontab -l.

Kopeerimine teise serverisse

Lisa skripti lõppu dumbi saatmine kaugserverisse SSH kaudu:

rsync -az "$BACKUP_DIR"/ [email protected]:/remote/db-backups/

Dumbist taastamine

MySQL:

gunzip < app_db_2026-04-17_03-30.sql.gz | mysql -u root -p app_db

PostgreSQL (custom-formaat):

pg_restore -d app_db --clean app_db_2026-04-17_03-30.dump

Korduma kippuvad küsimused

Kui tihti varukoopiaid teha? Sõltub sellest, kui palju andmeid oled valmis kaotama. Aktiivsele saidile iga päev, kriitiliste andmete puhul mitu korda päevas või WAL-i pideva arhiveerimisega (PostgreSQL).

Kas mysqldump lukustab andmebaasi töö ajaks? Lipuga --single-transaction InnoDB tabelite puhul lukustust ei ole — tehakse järjepidev hetktõmmis. MyISAM-i puhul on lukustus võimalik.

Kus dumpe hoida? Mitte ainult samal kettal. Kopeeri need eraldi serverisse või objektihoidlasse: ketta rike ei tohi viia korraga nii andmebaasi kui ka selle varukoopiaid.

Kuidas veenduda, et varukoopia töötab? Taasta dump aeg-ajalt eraldi testandmebaasi ja kontrolli andmeid. Kontrollimata varukoopiat ei saa varukoopiaks pidada.

Varukoopiad on sinu vastutusala ja me soovitame neid alati hoida. Automaatsete koopiatega andmebaasi saab paigutada pakettidele lehel VPS-i rent või eriotstarbelisele andmebaasi VPS-ile.