dbbackupv1.1
MySQL · MariaDB · rsync · systemd

Vos bases,
sauvegardées chaque nuit.

dbbackup exporte vos bases MySQL/MariaDB, les compresse, les envoie sur un VPS distant par rsync/SSH, puis applique une rotation locale et distante — à la demande ou automatiquement à 02:30.

Installer maintenant Voir les commandes
2copies : locale + VPS
10archives conservées
0secret dans ps
Installation

Documentation d'installation

Trois commandes : ajouter la clé publique du dépôt, ajouter le dépôt APT signé, puis installer. apt install dbbackup installe l'outil, crée la configuration et active le timer quotidien — sans jamais déclencher de sauvegarde.

1 Ajouter la clé publique du dépôt

$ sudo mkdir -p /etc/apt/keyrings && curl -fsSL https://mawena.cloud/repo/public.key | sudo gpg --dearmor -o /etc/apt/keyrings/mawena.gpg

2 Ajouter le dépôt APT

$ echo "deb [signed-by=/etc/apt/keyrings/mawena.gpg] https://mawena.cloud/repo stable main" | sudo tee /etc/apt/sources.list.d/mawena.list

3 Installer le paquet

$ sudo apt update && sudo apt install dbbackup

Il ne reste qu'à renseigner /etc/dbbackup.conf (VPS, clé SSH, bases à planifier), puis à tout valider avec sudo dbbackup doctor. Les mises à jour suivent ensuite naturellement avec sudo apt upgrade : votre configuration n'est jamais remplacée.

Prérequis : Ubuntu 22.04+ (ou dérivé Debian) avec accès sudo, un serveur MySQL/MariaDB local, et un VPS joignable en SSH avec une clé sans passphrase (le timer tourne sans interaction possible).

Capacités

Une sauvegarde que l'on peut oublier

Parce qu'une sauvegarde qui échoue en silence est pire qu'une absence de sauvegarde.

⛁

Dump cohérent

mysqldump --single-transaction compressé en gzip à la volée : aucun fichier intermédiaire non compressé sur le disque.

↗

Transfert hors site

Envoi par rsync sur SSH vers votre VPS, port et clé configurables. Une panne disque locale ne perd plus vos données.

↻

Rotation des deux côtés

Les KEEP archives les plus récentes sont conservées en local et sur le VPS. Aucun ménage à faire.

⏰

Timer systemd

Sauvegarde quotidienne à 02:30, rattrapée au démarrage si la machine était éteinte (Persistent=true).

✚

Diagnostic intégré

dbbackup doctor valide configuration, permissions, accès MySQL, accès VPS et planification — sans écrire une archive.

🔒

Secrets protégés

Configuration en 600 root:root, mot de passe transmis par fichier temporaire : jamais visible dans ps.

Fonctionnement

Quatre étapes, pour chaque base

Chaque base est traitée indépendamment : si l'une échoue, les suivantes sont quand même sauvegardées et un bilan final récapitule les échecs.

Étape 1

Export & compression

Dump cohérent piped dans gzip vers <base>-<horodatage>.sql.gz.

Étape 2

Transfert VPS

rsync sur SSH vers $VPS_DIR, en BatchMode (aucune saisie attendue).

Étape 3

Rotation locale

Les KEEP archives les plus récentes restent, les plus anciennes sont supprimées.

Étape 4

Rotation distante

Même règle appliquée sur le VPS, base par base.

Deux garde-fous : une archive dont l'export échoue est supprimée (un fichier tronqué ne doit jamais prendre la place d'une sauvegarde saine dans la rotation) ; à l'inverse, l'archive locale est conservée si le transfert échoue — vous gardez une copie et pouvez relancer.

Configuration

Un seul fichier : /etc/dbbackup.conf

Créé à l'installation depuis un modèle commenté, verrouillé en 600 root:root, et jamais remplacé par une mise à jour du paquet.

# --- VPS distant ---
VPS_USER="backupbot"
VPS_HOST="mawena.cloud"
VPS_PORT="2244"
VPS_DIR="/home/backupbot/backups"
 
# --- Clé SSH (chemin ABSOLU obligatoire, jamais $HOME) ---
SSH_KEY="/root/.ssh/id_ed25519"
 
# --- Archives locales et rotation ---
BACKUP_ROOT="/home/support/mysql"
KEEP="10" # local ET distant
 
# --- Bases sauvegardées par le timer ---
DATABASES="mawena factury xpress"
 
# --- Identifiants MySQL (vides = socket local) ---
DB_USER=""
DB_PASS=""

Chemin absolu pour la clé SSH

Le timer tourne en root sans environnement utilisateur : ~/.ssh/… ne sera pas résolu comme vous l'attendez. La clé doit être lisible par root et sans passphrase.

Le mot de passe ne fuite pas

Quand DB_PASS est renseigné, il est écrit dans un fichier temporaire en 600 passé à --defaults-extra-file, puis supprimé — jamais sur la ligne de commande.

DATABASES vide = planification inactive

C'est l'état par défaut après l'installation : le timer s'exécute, ne trouve aucune base et sort sans erreur. Rien ne part avant que vous ne l'ayez décidé.

Droits MySQL minimaux

Un utilisateur dédié suffit : SELECT, LOCK TABLES, SHOW VIEW, EVENT, TRIGGER, PROCESS. Ou rien du tout, en socket local.

Utilisation

De l'installation à la première nuit

Quatre commandes suffisent pour être opérationnel — et une seule pour tout vérifier.

1

Renseigner la configuration

sudo nano /etc/dbbackup.conf

VPS, clé SSH, BACKUP_ROOT, KEEP et la liste DATABASES.

2

Tout valider, sans rien écrire

sudo dbbackup doctor

Permissions, dépendances, clé SSH, espace disque, connexion MySQL, accès SSH au VPS, état du timer. Code de sortie 1 s'il reste un problème bloquant.

3

Sauvegarder à la demande

sudo dbbackup mawena factury

Une ou plusieurs bases, dans l'ordre indiqué. Le bilan final annonce 2/2 base(s) sauvegardée(s).

4

Vérifier ce qui est conservé

sudo dbbackup list

Nombre d'archives, taille cumulée et les cinq plus récentes, base par base.

Restaurer une archive

Les archives sont de simples dumps SQL compressés : aucun outil propriétaire n'est nécessaire.

$gunzip -c mawena-2026-07-30_02-30-04.sql.gz | mysql mawena

Vérifier une archive sans restaurer

Contrôlez l'intégrité gzip, puis la fin du dump (un export complet se termine par Dump completed).

$gzip -t archive.sql.gz && gunzip -c archive.sql.gz | tail -5
Planification

Le timer fait le travail

Le paquet installe et active dbbackup.timer, qui exécute chaque nuit dbbackup --scheduled sur les bases de DATABASES.

02:30 Chaque jour, avec un décalage aléatoire de 0 à 5 minutes (RandomizedDelaySec) pour ne pas saturer le VPS. Une exécution manquée — machine éteinte — est rattrapée au démarrage suivant.

↳ Suivre la planification

$ systemctl list-timers dbbackup.timer && journalctl -u dbbackup.service -n 50

↳ Lancer la sauvegarde planifiée maintenant

$ sudo systemctl start dbbackup.service

Aucune sauvegarde n'est lancée par apt. Le service est un oneshot déclenché uniquement par le timer (ou à la main) : ni apt install ni apt upgrade ne déclenchent de dump. Pour changer l'heure, utilisez un drop-in (sudo systemctl edit dbbackup.timer) plutôt que d'éditer le fichier du paquet.

Référence

Toutes les commandes

Toutes lisent /etc/dbbackup.conf et demandent donc sudo — sauf version et help.

Commande Description
Sauvegarde
dbbackup <base> [base…] Sauvegarder immédiatement les bases indiquées (export, transfert, rotation locale et distante).
dbbackup --scheduled Sauvegarder les bases listées dans DATABASES — commande exécutée par le timer.
Inspection
dbbackup list [base…] Lister les archives locales : nombre, taille cumulée et les cinq plus récentes.
dbbackup doctor Diagnostiquer configuration, permissions, dépendances, accès MySQL, accès VPS et planification.
Global
dbbackup version Afficher la version installée (injectée depuis le changelog au build).
dbbackup help Afficher l'aide.
man dbbackup Page de manuel complète (variables, unités systemd, codes de sortie).
systemd
systemctl status dbbackup.timer État du déclencheur quotidien.
systemctl start dbbackup.service Lancer la sauvegarde planifiée immédiatement.
journalctl -u dbbackup.service Journal des sauvegardes (chercher la ligne « Bilan »).