On Mon, 6 Aug 2012 21:54:47 +0200
Alain Vaugham wrote:
>
> Non, il ne manque pas le user.
> Avec cette syntaxe dans la crontab, pg_dump déverse bien dans un
> fichier.
Pas trop normal ça, chez moi en dehors de postgres personne ne peut
se connecter sans mot de passe.
> C'est seulement le nom de ce fichier qui n'est pas celui
> escompté.
Tu fais un script genre:
#!/bin/sh
TS=$(date +"%Y-%m-%d_%Hh%M")
pg_dump -a db_XYZ > /home/userx/backup/db_XYZ_${TS}.sql
que tu rends exécutable et que tu colles dans
/usr/local/bin/pgbackup_XYZ.sh
et un crontab:
* * * * * postgres if [ -x /usr/local/bin/pgbackup_XYZ.sh ]; then /usr/ local/bin/pgbackup_XYZ.sh; fi
On Mon, 6 Aug 2012 21:54:47 +0200
Alain Vaugham <alain@vaugham.com> wrote:
>
> Non, il ne manque pas le user.
> Avec cette syntaxe dans la crontab, pg_dump déverse bien dans un
> fichier.
Pas trop normal ça, chez moi en dehors de postgres personne ne peut
se connecter sans mot de passe.
> C'est seulement le nom de ce fichier qui n'est pas celui
> escompté.
Tu fais un script genre:
#!/bin/sh
TS=$(date +"%Y-%m-%d_%Hh%M")
pg_dump -a db_XYZ > /home/userx/backup/db_XYZ_${TS}.sql
que tu rends exécutable et que tu colles dans
/usr/local/bin/pgbackup_XYZ.sh
et un crontab:
* * * * * postgres if [ -x /usr/local/bin/pgbackup_XYZ.sh ]; then /usr/ local/bin/pgbackup_XYZ.sh; fi
On Mon, 6 Aug 2012 21:54:47 +0200
Alain Vaugham wrote:
>
> Non, il ne manque pas le user.
> Avec cette syntaxe dans la crontab, pg_dump déverse bien dans un
> fichier.
Pas trop normal ça, chez moi en dehors de postgres personne ne peut
se connecter sans mot de passe.
> C'est seulement le nom de ce fichier qui n'est pas celui
> escompté.
Tu fais un script genre:
#!/bin/sh
TS=$(date +"%Y-%m-%d_%Hh%M")
pg_dump -a db_XYZ > /home/userx/backup/db_XYZ_${TS}.sql
que tu rends exécutable et que tu colles dans
/usr/local/bin/pgbackup_XYZ.sh
et un crontab:
* * * * * postgres if [ -x /usr/local/bin/pgbackup_XYZ.sh ]; then /usr/ local/bin/pgbackup_XYZ.sh; fi
Tu fais un script genre:
#!/bin/sh
TS=$(date +"%Y-%m-%d_%Hh%M")
pg_dump -a db_XYZ > /home/userx/backup/db_XYZ_${TS}.sql
que tu rends exécutable et que tu colles dans
/usr/local/bin/pgbackup_XYZ.sh
Tu fais un script genre:
#!/bin/sh
TS=$(date +"%Y-%m-%d_%Hh%M")
pg_dump -a db_XYZ > /home/userx/backup/db_XYZ_${TS}.sql
que tu rends exécutable et que tu colles dans
/usr/local/bin/pgbackup_XYZ.sh
Tu fais un script genre:
#!/bin/sh
TS=$(date +"%Y-%m-%d_%Hh%M")
pg_dump -a db_XYZ > /home/userx/backup/db_XYZ_${TS}.sql
que tu rends exécutable et que tu colles dans
/usr/local/bin/pgbackup_XYZ.sh
Par contre, dans la crontab, cette même syntaxe ne génère pas le
fichier escompté :
* * * * * pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y)$(date +%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Par contre, dans la crontab, cette même syntaxe ne génère pas le
fichier escompté :
* * * * * pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y)$(date +%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Par contre, dans la crontab, cette même syntaxe ne génère pas le
fichier escompté :
* * * * * pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y)$(date +%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Je pensais que remplir le /usr/ était réservé pour l'installateur Debian.
Quelle est la raison pour laquelle on met ses propres scripts dans les
/usr/share/...
/usr/local/...
Je pensais que remplir le /usr/ était réservé pour l'installateur Debian.
Quelle est la raison pour laquelle on met ses propres scripts dans les
/usr/share/...
/usr/local/...
Je pensais que remplir le /usr/ était réservé pour l'installateur Debian.
Quelle est la raison pour laquelle on met ses propres scripts dans les
/usr/share/...
/usr/local/...
Le lundi 06 août 2012 à 12:09, d'après
Alain Vaugham :
> Par contre, dans la crontab, cette même syntaxe ne génèr e pas le
> fichier escompté :
> * * * * * pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y)$(date + %m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Comme l'a indiqué un autre contributeur, un seul appel à date s uffit :
pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y%m%d-%H%M%S).sql
Mais ton problème est surtout que le caractère '%' a une signif ication
particulière dans une crontab, il faut l'échapper pour lui enle ver cette
signification :
* * * * * pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y%m%d-%H %M%S).sql
Le lundi 06 août 2012 à 12:09, d'après
Alain Vaugham <alain@vaugham.com> :
> Par contre, dans la crontab, cette même syntaxe ne génèr e pas le
> fichier escompté :
> * * * * * pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y)$(date + %m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Comme l'a indiqué un autre contributeur, un seul appel à date s uffit :
pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y%m%d-%H%M%S).sql
Mais ton problème est surtout que le caractère '%' a une signif ication
particulière dans une crontab, il faut l'échapper pour lui enle ver cette
signification :
* * * * * pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y%m%d-%H %M%S).sql
Le lundi 06 août 2012 à 12:09, d'après
Alain Vaugham :
> Par contre, dans la crontab, cette même syntaxe ne génèr e pas le
> fichier escompté :
> * * * * * pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y)$(date + %m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Comme l'a indiqué un autre contributeur, un seul appel à date s uffit :
pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y%m%d-%H%M%S).sql
Mais ton problème est surtout que le caractère '%' a une signif ication
particulière dans une crontab, il faut l'échapper pour lui enle ver cette
signification :
* * * * * pg_dump -a db_mabase > ~/backup/db_mabase_$(date +%Y%m%d-%H %M%S).sql
Le Mon, Aug 06, 2012 at 11:10:10PM +0200, Alain Vaugham a écrit :
>
> Je pensais que remplir le /usr/ était réservé pour l'ins tallateur Debian.
> Quelle est la raison pour laquelle on met ses propres scripts dans les
> /usr/share/...
> /usr/local/...
Bonjour,
Debian respecte en général la norme FHS (Filesystem Hierarchy S tandard,
http://www.pathname.com/fhs/), et celle-ci garantit que les fichiers dans
/usr/local ne soient jamais changés par une mise à jour du syst ème.
C'est retranscrit dans la section 9.1.2 de la charte Debian.
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs
/usr/local est donc un bon endroit pour installer de manière globale
des programmes.
Le Mon, Aug 06, 2012 at 11:10:10PM +0200, Alain Vaugham a écrit :
>
> Je pensais que remplir le /usr/ était réservé pour l'ins tallateur Debian.
> Quelle est la raison pour laquelle on met ses propres scripts dans les
> /usr/share/...
> /usr/local/...
Bonjour,
Debian respecte en général la norme FHS (Filesystem Hierarchy S tandard,
http://www.pathname.com/fhs/), et celle-ci garantit que les fichiers dans
/usr/local ne soient jamais changés par une mise à jour du syst ème.
C'est retranscrit dans la section 9.1.2 de la charte Debian.
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs
/usr/local est donc un bon endroit pour installer de manière globale
des programmes.
Le Mon, Aug 06, 2012 at 11:10:10PM +0200, Alain Vaugham a écrit :
>
> Je pensais que remplir le /usr/ était réservé pour l'ins tallateur Debian.
> Quelle est la raison pour laquelle on met ses propres scripts dans les
> /usr/share/...
> /usr/local/...
Bonjour,
Debian respecte en général la norme FHS (Filesystem Hierarchy S tandard,
http://www.pathname.com/fhs/), et celle-ci garantit que les fichiers dans
/usr/local ne soient jamais changés par une mise à jour du syst ème.
C'est retranscrit dans la section 9.1.2 de la charte Debian.
http://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs
/usr/local est donc un bon endroit pour installer de manière globale
des programmes.
Pourquoi aller mettre le script dans /usr/local/bin/?
Moi je les mettais dans le home du user et ne touchais jamais
au /usr/ Cela me semblait pratique pour sauvegarder/réinstaller.
Est-ce une mauvaise habitude que j'ai prise?
(à une époque je montait mes partitions dans le /home/user/.
Comme sur cette liste on m'a fait remarquer que le /mnt/ était
fait pour ça, j'ai changé mon habitude.)
Je pensais que remplir le /usr/ était réservé pour l'insta llateur
Debian.
Quelle est la raison pour laquelle on met ses propres
scripts dans les /usr/share/...
/usr/local/...
Pourquoi aller mettre le script dans /usr/local/bin/?
Moi je les mettais dans le home du user et ne touchais jamais
au /usr/ Cela me semblait pratique pour sauvegarder/réinstaller.
Est-ce une mauvaise habitude que j'ai prise?
(à une époque je montait mes partitions dans le /home/user/.
Comme sur cette liste on m'a fait remarquer que le /mnt/ était
fait pour ça, j'ai changé mon habitude.)
Je pensais que remplir le /usr/ était réservé pour l'insta llateur
Debian.
Quelle est la raison pour laquelle on met ses propres
scripts dans les /usr/share/...
/usr/local/...
Pourquoi aller mettre le script dans /usr/local/bin/?
Moi je les mettais dans le home du user et ne touchais jamais
au /usr/ Cela me semblait pratique pour sauvegarder/réinstaller.
Est-ce une mauvaise habitude que j'ai prise?
(à une époque je montait mes partitions dans le /home/user/.
Comme sur cette liste on m'a fait remarquer que le /mnt/ était
fait pour ça, j'ai changé mon habitude.)
Je pensais que remplir le /usr/ était réservé pour l'insta llateur
Debian.
Quelle est la raison pour laquelle on met ses propres
scripts dans les /usr/share/...
/usr/local/...
Bonjour la liste,
La crontab ne fait pas ce que je veux...
Pourtant en ligne de commande j'ai bien ce que je veux :
$ pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date +%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Par contre, dans la crontab, cette même syntaxe ne génère pas le
fichier escompté :
* * * * * pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date +%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Je me suis douté qu'il fallait ajouter des séparateurs de champs.
Comme le man de crontab n'aborde pas le sujet j'avance à tâtons avec ce lien :
http://fr.wikipedia.org/wiki/Crontab
J'ai donc testé différentes combinaisons de caractères "'/[ ]{}
en m'inspirant également de la syntaxe employée par le fichier .procmail
mais sans succès.
Il me semble qu'en dehors de la ligne de commande les syntaxes varient
au sein d'une même distribution.
Est-ce que quelqu'un pourrait m'indiquer le bon tuto pour une Squeeze?
Merci beaucoup par avance.
Bonjour la liste,
La crontab ne fait pas ce que je veux...
Pourtant en ligne de commande j'ai bien ce que je veux :
$ pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date +%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Par contre, dans la crontab, cette même syntaxe ne génère pas le
fichier escompté :
* * * * * pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date +%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Je me suis douté qu'il fallait ajouter des séparateurs de champs.
Comme le man de crontab n'aborde pas le sujet j'avance à tâtons avec ce lien :
http://fr.wikipedia.org/wiki/Crontab
J'ai donc testé différentes combinaisons de caractères "'/[ ]{}
en m'inspirant également de la syntaxe employée par le fichier .procmail
mais sans succès.
Il me semble qu'en dehors de la ligne de commande les syntaxes varient
au sein d'une même distribution.
Est-ce que quelqu'un pourrait m'indiquer le bon tuto pour une Squeeze?
Merci beaucoup par avance.
Bonjour la liste,
La crontab ne fait pas ce que je veux...
Pourtant en ligne de commande j'ai bien ce que je veux :
$ pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date +%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Par contre, dans la crontab, cette même syntaxe ne génère pas le
fichier escompté :
* * * * * pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date +%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Je me suis douté qu'il fallait ajouter des séparateurs de champs.
Comme le man de crontab n'aborde pas le sujet j'avance à tâtons avec ce lien :
http://fr.wikipedia.org/wiki/Crontab
J'ai donc testé différentes combinaisons de caractères "'/[ ]{}
en m'inspirant également de la syntaxe employée par le fichier .procmail
mais sans succès.
Il me semble qu'en dehors de la ligne de commande les syntaxes varient
au sein d'une même distribution.
Est-ce que quelqu'un pourrait m'indiquer le bon tuto pour une Squeeze?
Merci beaucoup par avance.
Bonjour,
il me semble bien qu'il faille échapper les caractères % dans la table cron
par exemple:
* * * * * echo $(date +%s) > ~/test_cron
en espérant avoir été utile.
cordialement
seb
Le 06/08/2012 12:09, Alain Vaugham a écrit :Bonjour la liste,
La crontab ne fait pas ce que je veux...
Pourtant en ligne de commande j'ai bien ce que je veux :
$ pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date
+%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Par contre, dans la crontab, cette même syntaxe ne génère pas le
fichier escompté :
* * * * * pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date
+%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Je me suis douté qu'il fallait ajouter des séparateurs de champs.
Comme le man de crontab n'aborde pas le sujet j'avance à tâtons avec
ce lien :
http://fr.wikipedia.org/wiki/Crontab
J'ai donc testé différentes combinaisons de caractères "'/[ ]{}
en m'inspirant également de la syntaxe employée par le fichier .procmail
mais sans succès.
Il me semble qu'en dehors de la ligne de commande les syntaxes varient
au sein d'une même distribution.
Est-ce que quelqu'un pourrait m'indiquer le bon tuto pour une Squeeze?
Merci beaucoup par avance.
Bonjour,
il me semble bien qu'il faille échapper les caractères % dans la table cron
par exemple:
* * * * * echo $(date +%s) > ~/test_cron
en espérant avoir été utile.
cordialement
seb
Le 06/08/2012 12:09, Alain Vaugham a écrit :
Bonjour la liste,
La crontab ne fait pas ce que je veux...
Pourtant en ligne de commande j'ai bien ce que je veux :
$ pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date
+%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Par contre, dans la crontab, cette même syntaxe ne génère pas le
fichier escompté :
* * * * * pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date
+%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Je me suis douté qu'il fallait ajouter des séparateurs de champs.
Comme le man de crontab n'aborde pas le sujet j'avance à tâtons avec
ce lien :
http://fr.wikipedia.org/wiki/Crontab
J'ai donc testé différentes combinaisons de caractères "'/[ ]{}
en m'inspirant également de la syntaxe employée par le fichier .procmail
mais sans succès.
Il me semble qu'en dehors de la ligne de commande les syntaxes varient
au sein d'une même distribution.
Est-ce que quelqu'un pourrait m'indiquer le bon tuto pour une Squeeze?
Merci beaucoup par avance.
Bonjour,
il me semble bien qu'il faille échapper les caractères % dans la table cron
par exemple:
* * * * * echo $(date +%s) > ~/test_cron
en espérant avoir été utile.
cordialement
seb
Le 06/08/2012 12:09, Alain Vaugham a écrit :Bonjour la liste,
La crontab ne fait pas ce que je veux...
Pourtant en ligne de commande j'ai bien ce que je veux :
$ pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date
+%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Par contre, dans la crontab, cette même syntaxe ne génère pas le
fichier escompté :
* * * * * pg_dump -a db_mabase> ~/backup/db_mabase_$(date +%Y)$(date
+%m)$(date +%d)-$(date +%H)$(date +%M)$(date +%S).sql
Je me suis douté qu'il fallait ajouter des séparateurs de champs.
Comme le man de crontab n'aborde pas le sujet j'avance à tâtons avec
ce lien :
http://fr.wikipedia.org/wiki/Crontab
J'ai donc testé différentes combinaisons de caractères "'/[ ]{}
en m'inspirant également de la syntaxe employée par le fichier .procmail
mais sans succès.
Il me semble qu'en dehors de la ligne de commande les syntaxes varient
au sein d'une même distribution.
Est-ce que quelqu'un pourrait m'indiquer le bon tuto pour une Squeeze?
Merci beaucoup par avance.