Synology [Tuto] Sauvegarder ses bases de données MariaDB de son NAS Synology

  • Auteur du sujet Auteur du sujet EVO
  • Date de début Date de début
  • Vague de SPAM

    Suite à une vague de spam sur le forum, les inscriptions sont temporairement limitées.

    Après votre inscription, un membre de l'équipe devra valider votre compte avant qu'il ne soit activé. Nous sommes désolés pour la gêne occasionnée et vous remercions de votre patience.

EVO

Administrateur
Membre du personnel
25 Novembre 2019
11 360
2 639
303
/var/run/docker.sock
Bonjour,
Aujourd'hui je vous propose une solution simple pour sauvegarder une base SQL d'un site hébergé sur le NAS.

Fonctionnel sur DSM 6.2.3 avec MariaDB10.

Pour mon exemple, j'ai créé un dossier Save_MariaDB sur mon DD Ext présent sur mon NAS :
87AJ9hQ.png

Un clique droit, propriété me donne le chemin absolu : /volumeUSB2/usbshare/Save_MariaDB

Ensuite dans Panneau de configuration > Tache planifié je créé une nouvelle tâche planifié, en sélectionnant "Script défini par l'utilisateur"
AZu9Hh5.png


Je vais nommer la tâche SaveDB_DDExt, elle doit s’exécuter en root.
AfxtbIL.png


Dans l'onglet suivant, je la programme tous les jours a 00h01 !
FUHM7pN.png


Puis dans Paramètres de la tâches, j'entre mon script :
Code:
#!/bin/bash
backup_path="/volumeUSB2/usbshare/Save_MariaDB/"
date=$(date +"%Y-%m-%d")

user="mon_user"
pass="mon_pass"
host="localhost"
dbname="nom_base_a_sauvegarder"

/usr/local/mariadb10/bin/mysqldump --user=$user --password=$pass --host=$host $dbname > $backup_path/$date-$dbname.sql

#find $backup_path/* -name '*.sql' -mtime +15 -exec rm {} \;

Ici, il faudra modifier, user, pass, et dbname. Votre base se trouvant sur le NAS, host reste égal a localhost.
On peut si on le souhaite, envoyé un mail pour informer du bon déroulement ( ou pas ) de notre sauvegarde.
Et on valide !

On exécute une première fois, en le sélectionnant et en appuyant sur Executer

Ici j'ai fait un essai avec ma base de donnée "nextcloud_", elle est maintenant dans le dossier Save_MariaDB
Sous le nom "2020-06-07-nexcloud_.sql"
F6UkiyM.png


Note : La derniere ligne du code sert a supprimer automatiquement TOUS les fichiers .SQL de plus de 15 jours. Dans le dossier cité. ( attention donc ! )
Si vous souhaitez l'utiliser, vous devez dé-commenter la ligne en enlevant le # en début de ligne. Vous pouvez modifier le chiffre 15 afin de changer le temps de conservations de vos sauvegardes.
Code:
find $backup_path/* -name '*.sql' -mtime +15 -exec rm {} \;
 
Bonjour EVOTk,

Je te remercie pour ce Tuto que je viens de valider il y a peu ;)

Comme j'ai planifié deux sauvegardes par jour, j'ai remplacé : date=$(date +"%d-%b-%Y") par date=$(date +"%c") pour ne pas écraser la précédente du même jour

Bon dimanche

Bernard
 
Merci de ton retour ;)

Effectivement, je ne rajoute pas l'heure dans le nom du fichier, donc en cas de multiple sauvegarde la même journée, elle écrase la précédente ( ce qui est dommage pour une sauvegarde ! )

Edit : J'ai aussi modifier mon script par defaut la suppression auto est commenté afin d'etre inactive, je préfere dans se sans que active par defaut ! on ne sait jamais ! C'est méchant un - rm ^^ )
 
Bonjour Evotk,

Je te remercie également pour ce tuto.

Mais j'aurai deux questions dont une très importante :

  • 1
La moins importante comment sauvegarder dans un autre répertoire qui se trouve sur le réseau par exemple sur un autre Nas ?
J'ai bien essayé de mettre : backup_path="\\SERVEUR2\save_bdd" au lieu de backup_path="/volume1/save_bdd" mais non cela ne veut pas.

  • 2
question la plus importante, il y a une sauvegarde super, mais comment on la restaure ?

Car j'ai essayé depuis phpmyadmin puis l'onglet importer or il est écrit ceci :

"Le fichier peut être compressé (gzip, bzip2, zip) ou non.
Le nom du fichier compressé doit se terminer par .[format].[compression]. Exemple : .sql.zip
Parcourir les fichiers :Aucun fichier choisi(Taille maximale : 1 024Mio)"

J'ai fait un copier-coller de ce qui est écrit mais ce qui m'interpelle est la taille maximale, le dump de mon sql fait 17,1Mo
Cela va fonctionner ou y a-t-il une séquence pour réinjecter la sauvegarde ?

Merci d'avance de votre réponse.
 
Salut,
Pour la question 2, tu peu restaurer ta sauvegarde comme ceci :

Code:
/usr/local/mariadb10/bin/mysql --user=$user --password=$pass --host=$host $dbname < $backup_path/nom-du-fichier.sql

Pour la 1, je j'ai jamais fait de sauveg1rée de db que un chemin smb, je ne serais te répondre. Si j'ai un peu de temps en soirée, je regarderai ceci plus en détails.
 
Merci EVOTK pour ta réponse rapide.

N'étant pas très linux ou newbie si tu préfères ou exécute tu la commande ?
En refaisant une tache planifiée je suppose ? Car il n'y as pas de console sur un nas ou alors tu vas m'apprendre comment y accéder ;)

Ne te tracasse pas pour la question 1, j'ai fait depuis mon Nas qui sert de sauvegarde une réplication du contenu via le réseau 10 minutes après la sauvegarde et voilà.
 
Sur Syno, le plus simple reste d'utiliser les taches planifié, tu créer une tache sans programmation, que tu execute manuellement une fois, et ton backup sera restoré :

Exemple pour restauré un backup nommé : 2020-12_mon_backup.sql qui serait stocké dans /volumeUSB2/usbshare/Save_MariaDB/

Code:
#!/bin/bash
backup_path="/volumeUSB2/usbshare/Save_MariaDB/"

user="mon_user"
pass="mon_pass"
host="localhost"
dbname="nom_base_a_sauvegarder"

/usr/local/mariadb10/bin/mysql --user=$user --password=$pass --host=$host $dbname < $backup_path/2020-12_mon_backup.sql

L'autre solution , plus linuxienne, consisterai a enregistrer cette commande dans un fichier bash et l'executer en SSH.
 
Encore une fois merci pour ta réponse rapide.

Je ne sais pas si tu as vu dans d'autres parties du forum mais je vais avoir un Nas Asustor bien plus puissant que les Syno actuel que j'ai et je vais sûrement transférer la base de données.
Du coup, je pense qu'il va falloir que j'exécute manuellement cette commande en ssh on verra ça le jour J.
 
Je ne connais pas Asustor, mais oui, il te faudra surement le faire comme ceci ( mais il faudra s'assurer du chemin de mariadb10/mysql ) sinon, une autre solution serait de modifier PHP pour permettre l'upload de plus gros fichier dans phpmyadmin :

A modifier dans php.ini ( chemin "classique" pour php7.4 : /etc/php/7.4/apache2/php.ini ) avec par exemple ces valeurs :
Code:
post_max_size = 32MB
upload_max_filesize = 32MB
memory_limit = 128MB

puis redémarrer php pour que cela soit pris en compte.
Bien que pas testé pour ma part, ceci devrait fonctionner.
 
Je n'ai pas encore le Nas il est sur la route, mais merci beaucoup pour l'astuce pour gonfler phpmyadmin :)
 
Bonjour Evotk,

J'ai donc bien reçu mon nouveau NAS samedi, je l'ai mis en route dimanche soir pour faire la transition de données et cet après-midi, j'ai installer Mariadb et mysql sur le nas asustor.

J'ai tout d'abord lancé manuellement la tâche de sauvegarde sur le synology pour récupérer le dernier dump la de la base au jour J et temps T.

Je me suis connecté au nouveau nas (asustor) avec le logiciel Winscp car je ne connaissait pas le chemin de php pour trouver le php.ini.

Une fois trouvé, je l'ai éditer et changer les valeurs par ceux que tu m'as fournis.
Puis j'ai redémarrer le service PHP et phpmyadmin.
Enfin j'ai juste du créer une base vide du même nom et je l'ai importé via phpmyadmin.

Tout a fonctionné comme sur des roulettes. :D

Ensuite je suis passé sur les clients en changeant l'adresse ip pour la connexion et voilà.

Merci encore pour ton tuto et ton aide.
 
Bonjour,

Grand merci pour ce tuto très bien expliqué, par contre chez moi il ne marche pas ?
J'ai comme indiqué dans mon profil DSM 7.2.1 sur un Synology. De longue date j'avais vu qu(il fallait mieux désactiver le compte root et guest des dossiers partagés.
Je le précise car je ne suis vraiment pas sûr que cela soit indispensable, et les comptes utilisateurs ne m'ont jamais servis. Mais c'est peut-être cela qui met la grouille dans l'exécution du script bash.
Alors indication de ce que j'ai fait, les 3 répertoires que j'ai créé sont dans /volume2/\@appdata/save_mariadb/ normalement les bizarreries utilisées par Synology n'affectent pas le système Linux il suffit d'échapper ces caractères ("\"). Mais j'ai vu aussi sur le Syno un rab de liens beaucoup plus simple, à écrire et qui sait à interpréter dans les scripts ?
Les dossiers sont du groupe "users" et ma propriété "laurent", plus par sécurité et pour accès depuis l'interface graphique si besoin, root étant désactivé des dossiers partagés. Mais de ce que je me souvient seulement de ces dossiers partagés. Autrement le compte root existe, ce qui est logique.
Bref ce qui est sûr :
- Réactiver le compte root ne me pose aucun problème, mon NAS n'a jamais été relié à l'extérieur et aucune machine/port n'est ouvert ;
- Faire le tri entre le compte root en accès Unix et les joyeusetés de mettre un autre compte root sur MariaDB, avec un autre mdp tant qu'à faire... n'aident pas ;
- Je me reconnecte enfin depuis peu avec la console de Linux directement et non putty qui est beaucoup moins "friendly user", ( depuis qu'ils ont changé openssh-server cela a compliqué à loisir les choses pour virer les traces d'une clé existante, c'est plutôt usine à gaz) ;
- Enfin n'étant pas tous les jours sur le nas, je ne sais même pas où se trouvent ces tâches/scripts a exécuter. résultat je n'ai pas de debug en console puisque j'utilise la commande graphique du Syno et rien n'est retourné.
Le seul constat est que je ne reçois pas d'e-mail, c'est pas vraiment idéal comme info :LOL:
Bref si quelqu'un a une piste, ou peut m'indiquer le chemin d'accès à ces sripts bash du root Syno, ça me permettrais de les lancer en ligne de commande.
Ah précision je suis sous Linux et depuis un bail, donc la ligne de commande je sais m'en servir 😉
Par contre les données sont stockées non pas sur /volume1/\@appstore mais sur /volume1/\@appdata. C'est de l'ARM aussi et je ne pratique pas ces cpu habituellement, donc certaines différences viennent peut-être de là ou des choix Synology, mais c'est assez déroutant.
Donc pour résumer sur le Syno je suis nouveau et moins aguérri.

Merci d'avance de vos éventuelles réponses
Bonne journée à tous,
Laurent
 
Ah précision importante :
Ce matin mes test de màj de ma bdd justement avec 2 microcontrôleurs en micropython n'ont absolument pas planté de la nuit, tant mieux(y)

Donc j'ai pu me consacrer à des tests pour avancer.
Premier test et seul que j'ai exécuté, même si je n'ai toujours pas retrouvé trace d'un quelconque script SH correspondant ?
Alors qu'il est dans les tâches exécutées en mode graphique sur le Syno...
Mais j'ai fait un cat /etc/crontab, ça à l'air d'être très différent que de simples scripts qui sont utilisés...
Donc je ne sais pas si la finalité ne serait pas d'appeler un script bash stocké ailleurs ?

Bref, le test c'est d'avoir exécuté le script en ligne de commande, hors mdp que j'ai entré dans la ligne directe et que j'irai effacer de suite du log linux ;)
Bonne nouvelle ça fonctionne, donc le script n'est apparement pas en cause, si ce n'est que je n'ai pas forcément utilisé de double guillement pour certaines variables voir pas de guillemet du tout, les commande tapées :
Bash:
laurent@NASaLolo:/etc$ backup_path=/volume2/\@appdata/save_mariadb/energie/
laurent@NASaLolo:/etc$ echo $backup_path
retour : <= juste pour la compréhension je ne le remettrais pas à chaque fois
/volume2/@appdata/save_mariadb/energie/
laurent@NASaLolo:/etc$ date=$(date +"%Y-%m-%d")
laurent@NASaLolo:/etc$ echo $date
2026-02-10
laurent@NASaLolo:/etc$ user=root
laurent@NASaLolo:/etc$ echo $user
root
laurent@NASaLolo:/etc$ host="localhost"
laurent@NASaLolo:/etc$ echo $host
localhost
laurent@NASaLolo:/etc$ dname="energie"
laurent@NASaLolo:/etc$ echo $dname
energie
laurent@NASaLolo:/etc$ /usr/local/bin/mysqldump --user=$user --password='motdepasse' --host=$host $dname > $backup_path/$date-$dname.sql
laurent@NASaLolo:/etc$ ls /volume2/\@appdata/save_mariadb/energie/* -lha
-rw------- 1 laurent users 2.4M Feb 10 12:24 /volume2/@appdata/save_mariadb/energie/2026-02-10-energie.sql
laurent@NASaLolo:/etc$
Et voilà, par contre je n'ai pas reçu l'email, ça j'approfondirais plus tard. J'ai utilisé une variable dname en lieu et place de dbname, mais dans le script c'est ok.
Pour les guillmets double, simple, sans, c'est aléatoire en fonction du bash utilisé. Je sais que parfois selon le type de script utilisé cela peut changer.
Bref là guillement simple ou pas de guillemet ou double, la BDD energie a bien été copiée dans le répertoire du volume2 comme attendu.
Je ne sais donc vraiment pas pourquoi ça ne fonctionne pas en automatique ?

Précision importante donc cela ne devrait pas venir du script utilisé, enfin selon ce test.