Scripts problème BACKUP

[Onitsha]

Bonjour,
J'ai un soucis avec mon script de backup sur lequel je me prend la tête depuis un moment.
Il m'effectue correctement le dump de mes bases, mais certain jours les bases ne pèse qu'une centaine de Ko.

root@qstweb:/home/AIMS-PGSQL_dump# ls -l
total 1227232
-rwxrwxrwx 1 1001 vsftpd 314830540 26 oct. 15:44 2011-10-26-15h-Backup-PGSQLQST.tar.gz
-rwxrwxrwx 1 1001 vsftpd 314832497 26 oct. 16:19 2011-10-26-16h-Backup-PGSQLQST.tar.gz
-rwxrwxrwx 1 1001 vsftpd 314415436 27 oct. 13:01 2011-10-27-12h-Backup-PGSQLQST.tar.gz
-rwxrwxrwx 1 1001 vsftpd 311322605 28 oct. 00:16 2011-10-28-00h-Backup-PGSQLQST.tar.gz
-rwxrwxrwx 1 1001 vsftpd 320 29 oct. 00:15 2011-10-29-00h-Backup-PGSQLQST.tar.gz
-rwxrwxrwx 1 1001 vsftpd 320 30 oct. 00:15 2011-10-30-00h-Backup-PGSQLQST.tar.gz
-rwxrwxrwx 1 1001 vsftpd 313 6 nov. 00:15 2011-11-06-00h-Backup-PGSQLQST.tar.gz
-rwxrwxrwx 1 1001 vsftpd 314 7 nov. 00:15 2011-11-07-00h-Backup-PGSQLQST.tar.gz
-rwxrwxrwx 1 1001 vsftpd 322 8 nov. 00:15 2011-11-08-00h-Backup-PGSQLQST.tar.gz

Je ne comprends pas trop pourquoi, mais peut-être que vous verrez un soucis dans mon scripts, ou que le soucis viens d’ailleurs .

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
PGSQL_CONF_FILES='/home/pgsql/backup/temp/';
DATE=`date '+%F-%H'`h
DATE_OLD=`date '+%F-%H' --date '3 days ago'`h
 
 #### FTP ####
FTP_HOST='XXXXXXXXXXXXXX'
FTP_PORT='21'
FTP_USER='public'
FTP_PASSWD='XXXXXXXX'
FTP_REP='AIMS-PGSQL_dump'
 
######################################################################################################
############################### LANCEMENT DU JOB #####################################################
 
		### Backup des bases ###
		mkdir $PGSQL_CONF_FILES
		pg_dump intranet__meta > $PGSQL_CONF_FILES/save_intranet_meta.sql
		pg_dump intranetOPTIC_qst > $PGSQL_CONF_FILES/save_intranet_qst.sql
		pg_dump mironet_10 > $PGSQL_CONF_FILES/save_mironet_10.sql
		pg_dump intranetSFR_mozaicom > $PGSQL_CONF_FILES/save_intranet_mozaicom.sql
		pg_dump intranetSFR_lct > $PGSQL_CONF_FILES/save_intranet_lct.sql
		pg_dump intranetSFR_mmobile > $PGSQL_CONF_FILES/save_intranet_mmobile.sql
		pg_dump intranetSFR_dsm > $PGSQL_CONF_FILES/save_intranet_dsm.sql
		pg_dump intranetSFR_model > $PGSQL_CONF_FILES/save_intranet_SFRmodel.sql
		pg_dump intranetGED_inprint > $PGSQL_CONF_FILES/save_intranet_inprint.sql
		pg_dump intranetGED_stms > $PGSQL_CONF_FILES/save_intranet_stms.sql
		pg_dump intranetGED_model > $PGSQL_CONF_FILES/save_intranet_GEDmodel.sql
		pg_dumpall > $PGSQL_CONF_FILES/save_pg_all.sql
 
		#### Compression FINAL ##################################
		echo "Compression pour fichier SQL QST"
		tar -czf $PGSQL_CONF_FILES/$DATE-Backup-PGSQLQST.tar.gz $PGSQL_CONF_FILES/*
 
		###Definition du fichier à uploader
		FIC=$DATE-Backup-PGSQLQST.tar.gz
		###Definition du fichier à supprimer
		FIC_OLD=$DATE_OLD-Backup-PGSQLQST.tar.gz
 
		#### Export par FTP #####################################
		echo "Export FTP "
		cd $PGSQL_CONF_FILES
		echo "Sauvegarde Quotidienne"	
		lftp -u $FTP_USER,$FTP_PASSWD $FTP_HOST << END_SCRIPT
mkdir $FTP_REP
cd $FTP_REP
mput $FIC
rm -rf $FIC_OLD
quit
END_SCRIPT
 
		#### Supression des fichier temporaire de compression #################
		echo "Supression des fichiers temporaire de compression"
		mv $FIC /home/pgsql/backup
		rm -rf /home/pgsql/backup/$FIC_OLD
		rm -rf $PGSQL_CONF_FILES
 
		echo -e "\033[0;32mBackup terminée \033[0m"
 
################# FIN DU SCRIPT #######################################################################

Merci =)

[estofilo]

Ce qui ne va pas dans le script c'est que les erreurs ne sont pas traitées.
Si un pg_dump sort avec une erreur, il continue comme si de rien n'était.

[Onitsha]

Comment rentrer alors dans une condition if, que si la commande ne se termine pas correctement il doit la relancé ?

[estofilo]

Le plus souvent relancer une commande qui vient d'échouer sans traiter le problème ne sert à rien, elle va échouer à nouveau.
Personnellement j'ajouterais plutôt au début du script

Code :

SET -e

pour que toute erreur arrête de suite l'exécution.
Mais surtout il est indispensable de récupérer quelque part les messages d'erreur.
Soit le script est lancé avec une redirection du style

Code :

 sh backup.sh 2>> /chemin/vers/log_erreur

et comme ça on peut consulter le fichier log_erreur , soit le script gère ça lui-même avec une structure du style:

Code :

1
2
3
4
 
 (
  ... série de commandes
 ) 2 >> /chemin/vers/log_erreur

Enfin quand un script est lancé en cron, cron envoie automatiquement en mail tout éventuel affichage du script. En principe même en ne faisant aucune redirection on peut aussi avoir les messages d'erreur comme ça.

[Onitsha]

Suite a ton message j'ai commencé a regarde comment je pouvais pallier mon soucis.
C'est sur que tu n'as pas tord.
Si il en s’exécute pas cela ne sert a rien de recommencer.

Mais je regardé quelque chose du genre, une fonction qui retourne une erreur en cas d’arrêt de la procédure.

Code :

1
2
3
4
5
6
7
8
9
10
gestion_retour() {
        IF [ $1 -eq 0 ]; then
                echo " ... OK"
 
        else
                echo " ... ERREUR"
				mail -s TestErreurPourDUMPsql support@entic.fr < $?
                exit 1
        fi
}

Je vais simplement faire un enchaînement de commande que si le fichier de log est crée le script m'envoie un mail.

Je pense que cela sera plus simple.
Merci encore

[Onitsha]

Juste pour avoir une idées, vous effectuer comment vos backup postgres pour avoir des dump sur et propre ?


Pour ma part je fais :
- dump de chaque bases
- dumpall
- upload ftp

Cependant, j'ai lu des articles a propos de vacums etc.
Est-ce que vous saurez m'en dire plus ?

[estofilo]

Envoyé par Onitsha

Pour ma part je fais :
- dump de chaque bases
- dumpall
- upload ftp

Le pg_dumpall sans argument fait double emploi avec le dump de chaque base.
Normalement on ferait soit pg_dumpall tout seul et sans argument qui est le plus simple, soit un dump de chaque base plus un pg_dumpall --globals-only ou -g pour avoir les données communes à toute l'instance.