Ubuntu-fr

abecidofugy

[Résolu] Petit « bug » que je rencontre avec find

Salut,

J’ai installé un script déclenché par crontab en suivant cette page-là : https://www.kinamo.fr/fr/support/faq/my … de-donnees

Ici le détail :

root@machine:/usr/local/sbin# cat mysqlbackup.sh
#!/bin/bash

# https://www.kinamo.fr/fr/support/faq/mysql-backup-automatique-base-de-donnees

# Configuration de base: datestamp e.g. YYYYMMDD

DATE=$(date +"%Y%m%d")

# Dossier où sauvegarder les backups (créez le d'abord!)

BACKUP_DIR="/backup/mysql"

# Identifiants MySQL

MYSQL_USER="root"
MYSQL_PASSWORD="motdepasse"

# Commandes MySQL (aucune raison de modifier ceci)

MYSQL=/usr/bin/mysql
MYSQLDUMP=/usr/bin/mysqldump

# Bases de données MySQL à ignorer

SKIPDATABASES="Database|information_schema|performance_schema|mysql|phpmyadmin|roundcube"

# Nombre de jours à garder les dossiers (seront effacés après X jours)

RETENTION=14

# ---- NE RIEN MODIFIER SOUS CETTE LIGNE ------------------------------------------
#
# Create a new directory into backup directory location for this date

mkdir -p $BACKUP_DIR/$DATE

# Retrieve a list of all databases

databases=`$MYSQL -u$MYSQL_USER -p$MYSQL_PASSWORD -e "SHOW DATABASES;" | grep -Ev "($SKIPDATABASES)"`

# Dumb the databases in seperate names and gzip the .sql file

for db in $databases; do
echo $db
$MYSQLDUMP --force --opt --user=$MYSQL_USER -p$MYSQL_PASSWORD --skip-lock-tables --events --databases $db | gzip > "$BACKUP_DIR/$DATE/$db.sql.gz"
done

# Remove files older than X days

find $BACKUP_DIR/* -mtime +$RETENTION -delete

root@machine:/usr/local/sbin# ll
total 12
drwxr-xr-x  2 root root 4096 Jul  8 18:38 ./
drwxr-xr-x 11 root root 4096 Aug 15  2020 ../
-rwxr-xr-x  1 root root 1305 Jul  8 18:38 mysqlbackup.sh*

Depuis deux jours, dans le mail que je reçois automatiquement du serveur, il est notifié :

find: cannot delete ‘/backup/mysql/20210711’: Directory not empty

À priori, le find du fin de script ne marche pas, pour une raison que j’ignore.

Une idée de comment remettre tout ça d’aplomb ?

Merci.

Dernière modification par abecidofugy (Le 29/07/2021, à 17:05)

Vobul

Re : [Résolu] Petit « bug » que je rencontre avec find

Ajoute "-type f" à ton find pour qu'il ne s'occupe que des fichiers ? Même si je dois dire que là sur mon ordi find n'a aucun problème à supprimer des dossiers non vides donc je ne suis pas certain.... T'as quoi dans ton dossier de backup ?

---

Vobul
Utilisez le retour utilisable de commandes !!!
J'aime la langue française, mais je parle franglais, deal with it.
RTFM

bruno

Re : [Résolu] Petit « bug » que je rencontre avec find

Bonjour,

Cela ne m'étonne pas. Il me semble que l'option -delete ne supprime que des fichiers pas des dossiers non vides. Il manque des choses dans ce script (un -type f ?)
Et le mot de passe root dans le script c'est pas terrible…
Si tu veux tester un truc un peu plus élaboré : https://framagit.org/bruno666/simplemysqlbackup

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

Ajoute "-type f" à ton find pour qu'il ne s'occupe que des fichiers ? Même si je dois dire que là sur mon ordi find n'a aucun problème à supprimer des dossiers non vides donc je ne suis pas certain.... T'as quoi dans ton dossier de backup ?

Dans un répertoire : rien
Dans l’autre, juste une base sur les trois que j’ai sur ce serveur.

Étrange…

Bon je crois que j’avais déclenché le script par deux fois avant de l’inscrire dans le cron, donc il se peut que ces deux répertoires que je trimballe soit lié à ça. J’ai effacé les deux dossiers pour l’instant avec un rm -fr et je vais voir si ça retombe sur ses pattes.

Sinon je garde vos réponses, et cette autre solution de script.

Je vous tiens informé. Merci de votre aide et bonne journée.

Dernière modification par abecidofugy (Le 26/07/2021, à 13:15)

pingouinux

Re : [Résolu] Petit « bug » que je rencontre avec find

Bonjour,

find: cannot delete ‘/backup/mysql/20210711’: Directory not empty

Je pense que /backup/mysql/20210711 doit contenir des fichiers ou des répertoires non supprimés, à cause du test -mtime +$RETENTION non vérifié.

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

Par contre, sur le fichier script en question, j’ai un gros doute sur les droits. Eux, ils donnent :

chmod 755 kinamo_mysqlbackup.sh

Je pense qu’un chmod 700 serait mieux pour la sécurité, non ?
Car là, avec un utilisateur même pas dans les suddoers, je peux faire un cat, et donc voir le mot de passe…

Mais comme tu as dit, @bruno, ce n’est pas top une telle méthode…

bruno

Re : [Résolu] Petit « bug » que je rencontre avec find

Regarde le script que je te propose te tester tu verras qu'il est inutile d'utiliser le mot de passe de l'utilisateur root de mysql.

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

Regarde le script que je te propose te tester tu verras qu'il est inutile d'utiliser le mot de passe de l'utilisateur root de mysql.

Trop compliqué, et je n’arrive pas à le lire vraiment. Et aussi, je voudrais comprendre pourquoi j’ai ce bug.

Ajoute "-type f" à ton find pour qu'il ne s'occupe que des fichiers ? Même si je dois dire que là sur mon ordi find n'a aucun problème à supprimer des dossiers non vides donc je ne suis pas certain.... T'as quoi dans ton dossier de backup ?

# tree
.
├── 20210714
│   └── patricegr_publicitempro.sql.gz
├── 20210715
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210716
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210717
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210718
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210719
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210720
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210721
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210722
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210723
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210724
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210725
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210726
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210727
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
├── 20210728
│   ├── patricegr_autredatabase.sql.gz
│   ├── patricegr_publicitemd7.sql.gz
│   └── patricegr_publicitempro.sql.gz
└── 20210729
    ├── patricegr_autredatabase.sql.gz
    ├── patricegr_publicitemd7.sql.gz
    └── patricegr_publicitempro.sql.gz

Je ne comprends pas, dans 20210714 il reste effectivement un fichier. Pourquoi ne s’efface-t-il pas avec les autres ?

root@machine:/backup/mysql# cd 20210714/
root@machine:/backup/mysql/20210714# ll
total 4216
drwxr-xr-x  2 root root    4096 Jul 29 01:00 ./
drwxr-xr-x 18 root root    4096 Jul 29 01:00 ../
-rw-r--r--  1 root root 4305410 Jul 14 01:00 patricegr_publicitempro.sql.gz
root@machine:/backup/mysql/20210714# cd ../20210715/
root@machine:/backup/mysql/20210715# ll
total 10516
drwxr-xr-x  2 root root    4096 Jul 15 01:00 ./
drwxr-xr-x 18 root root    4096 Jul 29 01:00 ../
-rw-r--r--  1 root root 2131490 Jul 15 01:00 patricegr_autredatabase.sql.gz
-rw-r--r--  1 root root 4317824 Jul 15 01:00 patricegr_publicitemd7.sql.gz
-rw-r--r--  1 root root 4303908 Jul 15 01:00 patricegr_publicitempro.sql.gz

Dernière modification par abecidofugy (Le 29/07/2021, à 12:17)

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

Du fait du find delete, le dossier change de date :
drwxr-xr-x  2 root root    4096 Jul 29 01:00 ./

Au lieu du 14 juillet…

Dernière modification par abecidofugy (Le 29/07/2021, à 12:19)

bruno

Re : [Résolu] Petit « bug » que je rencontre avec find

Je ne pense vraiment pas que find change la date de modification d'un dossier. Il faudrait voir ces retours :

stat /backup/mysql/20210714
stat /backup/mysql/20210714/patricegr_publicitempro.sql.gz

Entre autres problèmes potentiels ton script va déconner si pour une raison ou une autre seulement certains fichiers sont supprimés dans un des dossiers. En effet la date de modification du dossier deviendra celle du jour d'exécution du script et ni lui, ni son contenu ne sera supprimé.

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

root@machine:/backup/mysql# stat /backup/mysql/20210714
  File: /backup/mysql/20210714
  Size: 4096            Blocks: 8          IO Block: 4096   directory
Device: 900h/2304d      Inode: 16252959    Links: 2
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-07-29 06:34:16.522365328 +0200
Modify: 2021-07-29 01:00:04.293207226 +0200
Change: 2021-07-29 01:00:04.293207226 +0200
 Birth: -
root@machine:/backup/mysql# stat /backup/mysql/20210714/patricegr_publicitempro.sql.gz
  File: /backup/mysql/20210714/patricegr_publicitempro.sql.gz
  Size: 4305410         Blocks: 8416       IO Block: 4096   regular file
Device: 900h/2304d      Inode: 16252962    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-07-14 01:00:03.283324467 +0200
Modify: 2021-07-14 01:00:04.311327749 +0200
Change: 2021-07-14 01:00:04.311327749 +0200
 Birth: -

Je suis en train de consulter ces pages :
https://stackoverflow.com/questions/255 … me-command
https://unix.stackexchange.com/question … swer-89929

Je cherche, je vais finir par trouver…

bruno

Re : [Résolu] Petit « bug » que je rencontre avec find

Cela confirme mon hypothèse : un fichier est resté dans le dossier pour une raison inconnue (arrêt brusque du script, plantage, etc.), comme d'autres fichiers y ont été supprimés la date de modification du dossier est devenue celle où le script avait été lancé. Tout ceci vient d'une mauvaise conception du script. Il aurait déjà été plus judicieux d'utiliser la date courante pour nommer les fichiers plutôt que pour créer des dossiers…

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

Je te remercie bruno, je vais me pencher sur ton script donné en lien. La prochaine fois, je gagnerai du temps à t’écouter. Merci pour ta patience.

Bonne journée à tous.

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

Ah, que je suis bête (vraiment ? !)

Mon dossier est « accédé » par un autre script, celui fourni avec mon CP :

root@machine:/backup# ll
total 1840888
drwxr-xr-x  3 root  root            4096 Jul 29 05:10 ./
drwxr-xr-x 19 root  root            4096 Jul 28 04:13 ../
-rw-r-----  1 autreuser autreuser      497725440 Jul 29 05:10 autreuser.2021-07-29_05-10-14.tar
-rw-r--r--  1 root  root            1556 Jul 29 05:10 autreuser.log
drwxr-xr-x 18 root  root            4096 Jul 29 01:00 mysql/
-rw-r-----  1 admin patricegr 1387315200 Jul 29 05:10 patricegr.2021-07-29_05-10-40.tar
-rw-r--r--  1 root  root            3985 Jul 29 05:10 patricegr.log

Je vais mettre mes backups dans mon dossier à l’extérieur de /backup et voir dans ce premier temps.

Si c’est la bonne analyse, je m’autoslappe !

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

C’est sûr que le script le plus efficace, serait celui qui garde uniquement les x entrées alphabétiques des dossiers classées dans l‘ordre décroissant.

//EDIT : je suis en train de voir si je veux compter le nombre d’éléments renvoyés par :

root@machine:/backup/mysql# ls -r
20210729  20210728  20210727  20210726  20210725  20210724  20210723  20210722  20210721  20210720  20210719  20210718  20210717  20210716  20210715  20210714

Dernière modification par abecidofugy (Le 29/07/2021, à 15:39)

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

# ls -r | wc -l
16

Reste à faire une boucle et garder les 14 premiers résultats, par exemple… lol, je vais y arriver !

MicP

Re : [Résolu] Petit « bug » que je rencontre avec find

Bonjour

michel@debbull:~/tests$ ls -l
total 72
drwxr-xr-x 2 michel michel 4096 29 juil. 16:33 20210712
drwxr-xr-x 2 michel michel 4096 29 juil. 16:33 20210713
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210714
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210715
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210716
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210717
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210718
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210719
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210720
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210721
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210722
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210723
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210724
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210725
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210726
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210727
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210728
drwxr-xr-x 2 michel michel 4096 29 juil. 16:10 20210729
michel@debbull:~/tests$ 
michel@debbull:~/tests$ dateLimite=$(date --date="13 days ago" +"%Y%m%d")    # Date il y a 13 jours passés
michel@debbull:~/tests$ 
michel@debbull:~/tests$ for dir in *; do [ $dir -lt $dateLimite ] && echo "je vais supprimer le répertoire $dir"; done
je vais supprimer le répertoire 20210712
je vais supprimer le répertoire 20210713
je vais supprimer le répertoire 20210714
je vais supprimer le répertoire 20210715
michel@debbull:~/tests$ 

et tu n'as plus qu'à remplacer :

echo "je vais supprimer le répertoire $dir";

par:

rm -rf "$dir";

Dernière modification par MicP (Le 29/07/2021, à 16:46)

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

Merci Michel !
Là je comprends ce qui se passe ^^

MicP

Re : [Résolu] Petit « bug » que je rencontre avec find

Ceci dit, tu n'auras pas besoin d'exécuter la boucle tous les jours, une seule fois suffira.

Ensuite, chaque fois que le script sera lancé par crontab et qu'il créera un nouveau répertoire (<=> chaque jour)
il supprimera le répertoire qui avait été créé 13 jours avant

Donc, dans ton script lancé tous les jours par crontab
pour supprimer le répertoire qui avait été créé il y a 13 jours
tu ajoutes les 2 lignes de commandes suivantes :

ilYa13jours=$(date --date="13 days ago" +"%Y%m%d")    # Date il y a 13 jours passés
[ -d $ilYa13jours ] && rm -rf $ilYa13jours            # Si le répertoire existe, le supprimer

Dernière modification par MicP (Le 29/07/2021, à 17:51)

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

root@machine:/backup/mysql# ll
total 72
drwxr-xr-x 18 root root 4096 Jul 29 01:00 ./
drwxr-xr-x  3 root root 4096 Jul 29 05:10 ../
drwxr-xr-x  2 root root 4096 Jul 29 01:00 20210714/
drwxr-xr-x  2 root root 4096 Jul 15 01:00 20210715/
drwxr-xr-x  2 root root 4096 Jul 16 01:00 20210716/
drwxr-xr-x  2 root root 4096 Jul 17 01:00 20210717/
drwxr-xr-x  2 root root 4096 Jul 18 01:00 20210718/
drwxr-xr-x  2 root root 4096 Jul 19 01:00 20210719/
drwxr-xr-x  2 root root 4096 Jul 20 01:00 20210720/
drwxr-xr-x  2 root root 4096 Jul 21 01:00 20210721/
drwxr-xr-x  2 root root 4096 Jul 22 01:00 20210722/
drwxr-xr-x  2 root root 4096 Jul 23 01:00 20210723/
drwxr-xr-x  2 root root 4096 Jul 24 01:00 20210724/
drwxr-xr-x  2 root root 4096 Jul 25 01:00 20210725/
drwxr-xr-x  2 root root 4096 Jul 26 01:00 20210726/
drwxr-xr-x  2 root root 4096 Jul 27 01:00 20210727/
drwxr-xr-x  2 root root 4096 Jul 28 01:00 20210728/
drwxr-xr-x  2 root root 4096 Jul 29 01:00 20210729/
root@machine:/backup/mysql# ilYa13jours=$(date --date="13 days ago" +"%Y%m%d")
root@machine:/backup/mysql# echo $ilYa13jours
20210716

En fait, ça tient encore compte des dates. Ce que je voudrais c’est que le script efface tous les dossiers par ordre alphabétique sauf ceux qui sont dans la période de rétention.

//EDIT : je préfère la boucle de ta solution-là : https://forum.ubuntu-fr.org/viewtopic.p … #p22475757
//EDIT 2 : oui cette solution me convient bien, mais je note l’autre solution aussi

Dernière modification par abecidofugy (Le 29/07/2021, à 18:26)

MicP

Re : [Résolu] Petit « bug » que je rencontre avec find

…En fait, ça tient encore compte des dates. …

Non, le script supprime les répertoires en fonction de leur nom et pas de leur attributs de date.

Dans ton script, le nom de chacun des répertoires est créé en utilisant la date à laquelle il a été créé :

…
# Configuration de base: datestamp e.g. YYYYMMDD

DATE=$(date +"%Y%m%d")

…

# Create a new directory into backup directory location for this date

mkdir -p $BACKUP_DIR/$DATE
…

et c'est ce nom de répertoire que j'utilise dans ma boucle for
pour le comparer à un nom de répertoire qui aurait été créé (et nommé en fonction de sa date de création) il y a 13 jours
et décider si il doit être ou ne pas être supprimé.

À aucun moment, dans les lignes de commandes que je t'ai proposées,
les attributs de date des répertoires ne sont utilisés dans cette méthode
ce sont seulement leur noms :

BACKUP_DIR="/backup/mysql"
dateLimite=$(date --date="13 days ago" +"%Y%m%d")                                       # Date il y a 13 jours passés
for dir in "$BACKUP_DIR"/*; do [ ${dir##*/} -lt $dateLimite ] && rm -rf "$dir"; done    # Supprimer tous les fichiers (ou répertoires) dont le nom (un nombre) est inférieur au nom (un nombre) construit avec la date qu'il était il y a 13 jours passé

BACKUP_DIR="/backup/mysql"
ilYa13jours=$(date --date="13 days ago" +"%Y%m%d")                       # Date il y a 13 jours passés
[ -d "$BACKUP_DIR"/$ilYa13jours ] && rm -rf "$BACKUP_DIR"/$ilYa13jours   # Si le répertoire existe, le supprimer

=======

…sauf ceux qui sont dans la période de rétention. …

Pour éviter toute confusion,
donne la liste des noms de répertoire que tu veux garder.

EDIT : Un caractère échappé pour rien => ${dir##*\/} remplacé par ${dir##*/}

Dernière modification par MicP (Le 31/07/2021, à 16:05)

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

@MicP : ah super, merci pour les explications en sus.

J’ai adapté à mon script, j’ai commenté la ligne avec find, et j’ai bien rajouté le : cd $BACKUP_DIR
Je switche sur la ligne avec le rm dès demain, suivant le message que je vais recevoir de l’exe du script.

Ça devrait rouler.

Merci encore.

//EDIT : ah je vois que tu m’as donné les lignes à mettre. Merci !
//EDIT 2 : ah oui, pas besoin du "cd" avec cette syntaxe

Dernière modification par abecidofugy (Le 29/07/2021, à 19:44)

MicP

Re : [Résolu] Petit « bug » que je rencontre avec find

//EDIT : ah je vois que tu m’as donné les lignes à mettre. Merci !
//EDIT 2 : ah oui, pas besoin du "cd" avec cette syntaxe

Oui, désolé, j'ai ré-édité mon message pour l'adapter au contexte de ton script alors que tu venais de poster le tien,
mais je vois que tu as bien compris, donc tout va bien

FrancisFDZ

Re : [Résolu] Petit « bug » que je rencontre avec find

Bonjour,
Je pense qu'il peut être important de rappeler que les informations sur un fichier contiennent 3 dates :
- la date de création
- la date de la dernière modification
- la date du dernier accès
La date la plus intéressante est la date de dernière modification, c'est d'ailleurs celle qui apparait dans le gestionnaire de fichier.

---

-- On peut avoir des raisons de se plaindre et n'avoir pas raison de se plaindre --
[Victor Hugo]

abecidofugy

Re : [Résolu] Petit « bug » que je rencontre avec find

@MicP : Par contre, cette variable-là ${dir##*\/} appelée de cette façon, c’est space pour moi ^^

J’ai juste compris le \/ : l’antislash sert à échapper le slash.

@FrancisFDZ : ah oui, en effet. Peut-être que le script donné par bruno tient compte de ces critères-là.

Dernière modification par abecidofugy (Le 29/07/2021, à 20:25)