Je cherche à coder un petit script de backup qui me permette de sauvegarder des données dans un dossier nommé à la date du jour et de supprimer les dossiers de sauvegarde antérieurs à n jours.
J'arrive à faire la sauvegarde dans les dossiers horodatés sans soucis, mon problème, c'est pour la suppression des dossiers antérieurs, il faudrait que je puisse comparer la date du jour avec la date constituée à partir du nom du fichier (au format aaaammjj) pour pouvoir supprimer les dossier vieux de disons 4 jours par exemple.
Voici mon script, si une bonne âme peut m'aider pour le reste, paske moi et les script shell bin c'est pas encore ça :(
#!/bin/sh
#creation du dossier nomme a la date du jour (aaaammjj)
cd /backups
mkdir `date +%Y%m%d`
cd `date +%Y%m%d`
#sauvegarde de mes fichiers dans le dossier
pg_dump ma-base | bzip2 > ma-base.bz2
tar -cj /etc -f etc.tar.bz2
#modification des droits
chmod -R 777 /backups
Merci par avance
# rdiff-backup
Posté par zephred . Évalué à 2.
[^] # Re: rdiff-backup
Posté par hybrid256 . Évalué à 1.
De plus, l'idée c'est aussi d'apprendre à faire des trucs un peu plus complexes en script shell, je sais qu'il y'a des tonnes de bouquins sur le sujet mais se taper tout ça est trop long, là, j'avais un exemple pratique et qui me parle en guise de sujet.
Merci quand même, en attendant, s'il y'a d'autres idées, je suis toujours preneur.
[^] # Re: rdiff-backup
Posté par Amand Tihon (site web personnel) . Évalué à 1.
# find | xargs ?
Posté par Steve Azriel . Évalué à 2.
Pourquoi ne pas utiliser la commande find avec comme conditions:
¤ catégorie: répertoire
¤ date: ancienne de 4 jours (pour l'exemple)
A cela, un pipe ("|") xargs pour une suppression (rm --recursive --force).
Petite illustration:
===
find /backups -type d -mtime +4 | xargs rm --recursive --force
===
supprime tous les répertoires de /backups vieux de +4 jours.
Attention, s'il y a des sous-répertoires, il faut affiner la recherche du find avec des conditions sur la profondeur de recherche (min/max depth)
=> Voir alors la doc de la commande find pour leur utilisation.
Bon courage !
Cdlt,
PS: Ne pas hésiter à tester la première partie de la commande (find) pour voir les résultats et confirmer que cela correspond à ce qui doit être supprimé ^__^
[^] # Re: find | xargs ?
Posté par hybrid256 . Évalué à 1.
C'est exactement ce que je voulais, et le tout en une seule ligne de commande, c'est top !
Merci ! Merci ! Merci !
[^] # ou alors date +%s
Posté par daggett . Évalué à 1.
Cependant sache que find se base sur la date du fichier, pas la date codée dans le nom du répertoire: si tu fais une copie de ton backup sans l'option "-a" de cp, elle se retrouvera à la date d'aujourd'hui.
On peut faire des comparaisons de dates au format texte en bidouillant, par exemple avec la sortie +%s de date qui donne l'équivalent en nombre de secondes depuis 1970.
Si ton repertoire est deja de la forme YYYYMMDD ou YYYY-MM-DD (c'est ton cas) tu peux donner son nom directement à date, par exemple:
Ceci va convertir les dates en secondes, et faire la conversion en nombre de jours. C'est un peu tordu, mais ça peut servir...
[^] # Re: ou alors date +%s
Posté par Steve Azriel . Évalué à 1.
Effectivement, la méthode find se base sur les dates systèmes (creation: ctime, modification:mtime, acces:atime & leur version en *min), donc le nom de fichier n'est pas pris en compte.
Pour contourner ce problème, on pourrait (mais dans le cas présent ce n'est pas nécessaire) compléter le script de backup par la commande "touch" sur chaque fichier/répertoire sauvegardé.
Cela permet de forcer la mse à jour des dates d'accès et de modification à celle du lancement de la commande :-)
C'est sioux, mais je l'utilise pour les snapshots via rsync (merci à ceux qui ont documenté cette fonctionnalité ^__^). Dans ce cas, je limite l'action au seul répertoire au format AAAAMMJJ et je limite donc le find à une profondeur de 1 par rapport au répertoire de snapshots... (ca devient hors-sujet, désolé).
Voili voilà !
Cdlt,
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.