salut
 
vous conseilleriez quoi pour faire des backup incrementaux en local sur un deuxieme hdd avec gestion des intervalles inferieurs à une journée
backup-manager => au mieux j ai une sauvegarde/jour
alors que je voudrais en faire une par heure

rsynch + cron...

rdiff-backup j'aime bien aussi

backuppc si tu t'enfoue des perfs

je suis en train de bosser sur un script avec tar pour me former
mais j arrive pas à faire ce que je veux    
 
donc admettons j ai une arborescence de 500mo qui est tarée
avec 15mo de tar incrementaux en plus
 
je voudrais prendre le moins de place possible pendant ma procedure
donc => extraire les fichiers des tar un par un, mais des que chaque fichier est extrait
l'effacer immediatement du tar (pour ne pas avoir un redondance inutile)
parce que la j arrive à un truc qui passe de 500mo à 1000 avant de revenir à 500
donc c est pas interessant
 
ce que j ai fait:
tar -xvf mongrostar.tar | un coup de sed pour traiter que les fichiers | xargs tar --delete -vf mongrostar.tar
mais ca fait ce que j ai decris plus haut  
j ai essayé de donner une plus hautre priorité au membre droit du pipe , mais ca change rien  

et comment on gere ces foutus espace blancs dans les noms de fichier quand on utilise une boucle for en bash?????  
les espaces blancs ca me rend fou
 
edit:faut peut etre que je deplace dans la categorie script la non?

Avec des doubles quote.
 
commande_quelconque "mon fichier.ext"

Ou en remplaçant les " " par des "\ "

t'as essayé en modifiant la variable IFS ? (IFS=" " )

j avais essayé les double quote, le sed qui remplace l espace blanc par un  \  
je parle pour la boucle for hein
paske ca marche pas
exemple : for i in $(ls) do echo $i done
si on a dansle repertoire:
fichier1
fichier2
fichier avec des blancs
fichier3
 
le micro script ci dessus renvoie
fichier1
fichier2
fichier
avec
des
blancs
fichiers3
avec un sed -e 's/\ /\\\ /g' ca donne un truc dans le meme genre mais avec des '\' en plus
le probleme c'est vraiment au niveau du for en fait
 
donc ce que j ai trouvé pour remplacer : je stocke mes lignes a traiter dans un fichier
ls > fichier
cat fichier | while read sortie  do traitement "$sortie" done
et la ca marche
et c est equivalent à une boucle for
quand j aurais le temps je vous collerai mon petit script de backup avec tar
il est pas revolutionnaire mais il peut rendre service

 
nop
c est le field separator du bash?
 
edit: je m auto repond => oui
si je veux changer " " par un newline je met quoi?
"\n" marche pas deja

Vous en avez pas marre de réinventer la roue ?

Reinventer la roue c est etre la roue  

Et celui qui passera derrière toi? C'est une roue aussi?
En entreprise faut privilégier les solutions standards, tu débutes dans un nouveau taf, tu vois rsync, tu connais, tu trouves ça partout, c'est lisible alors que ton script home-made qui se foire et qui n'est pas portable, ça va être une monstruosité à relire et à comprendre.

Surtout si c'est pareil pour tous les logiciels du parc, tu mets combien de mois à comprendre l'existant alors qu'avec des solutions libres pérennes et éprouvées (et avec un peu de docs en interne, on peut rêver), tu maîtrises ton infrastructure en quelques semaines.

n'importe quoi. Une phrase creuse sans aucun sens. Dans un contexte professionnel le mec qui pose un script home made là où des solutions "standards" existent est soit :

• un précurseur qui n'en est pas à premier script
• un in(conscient|compétent) qui s'en fout de qui prendra la suite.  

 
En remplacant :
for i in $(ls)
(la commande ls renvoie une chaine au shell qui l'interprete en separant les arguments par des espaces)
par:
for i in *; ...
(le shell expande le * directement)
 
Ton fichier est doublement inutile, puisque tu peux faire directement :
ls | for ...

mais non mais on ne remplace rien
 
comme l'a dit black_lord, vouloir à tout prix faire son petit script perso à moitié foireux alors qu'il existe des outils conçus pour ça et qu'il suffit de les assembler pour que ça fonctionne ...

Certes mais il a dit que c'etait pour se former en shell

1. Oui, il est préférable d'utiliser des solutions existantes, bien documentées, répondant aux besoins et ne compromettant pas les évolutions futures (changement d'équipe d'admin, changement de stratégie...).
 
2. Oui, apprendre et expérimenter c'est une bonne chose.
 
 
Tout le monde> S'il le gars a envie de réinventer la roue pour apprendre le scripting, je ne vois pas de quel droit vous pouvez le lui interdire.
J'ai peut etre mal lu le thread, mais je ne vois nul part qu'il est dans un contexte de mise en prod. Je lis qu'il désire se former.
Il est de loin préférable de lui donner les bonnes pratiques professionnelles (ce que vous avez fait) sans le basher. S'il veut apprendre le scripting, mieux vaut lui montrer comment écrire correctement des scripts au lieu de partir dans le bashing made in HFR...
 
el roti> Comme tout le monde l'a déjà dit, si ton script est pour une mise en production dans un contexte pro, relis le thread en entier.
- Apprendre à écrire des scripts/programmes/autres de manière intelligente, bien documentée et maintenable rapidement par une tierce personne c'est le bien.
- Apprendre à utiliser de très bon outils répondant à ton besoin, c'est le bien.

ah bah oui, il a pas écrit que c'était pour faire de la prod
d'un autre côté, faire un backup incrémental toute les heures sur un pc perso ...

Ouai... genre pour apprendre à programmer en script il faut forcément avoir un projet qui rentre dans le contexte ?

Personnellement, je n'aurais pas eu mon parcours si je ne m'étais jamais poser la question de comment on mettais en place un réseau d'entreprise (du filer, au serveur mail en passant le DNS et LDAP sans oublier les switches et les routeurs,les firewalls, IPsec, L2TP, IPv6, j'en passe et des meilleurs...) alors que j'étais dans une chambre de cité U de 9m² avec 3 malheureux PC...

Maintenant, si vous ne voulez pas participer à ce topic, rien ne vous y contraint !

La question qu'il pose n'est pas stupide. Pour ce cas là oui, maintenant dans d'autres, ca peut devenir un vrai problème.

La solution typique: la boucle for avec * (comme indiqué plus haut), ou la while pipée, avec read (quand l'expansion shell atteint ses limites, ou qu'on travaille avec des données tabulées et qu'on aime pas awk)

Edit: mega burn

 
   
On a pas le droit de rigoler ici ?    
Si j ai envie d inventer des proverbes chinois foireux c est mon droit    
 
 

 
Apparement ici ca part vite en vrille ici , il suffit qu un gars lache le mot "prod" et c'est l emeute    
Et donc oui je confirme, il s'agit uniquement d'une utilisation personnelle et pas de mise en "biiiip"
Et de toutes facons , je prevois d utiliser les deux solutions simultanement pour coller à mes besoins/ressources
script bash + backup-manager
 
 
 

 
bah pourquoi pas?
tu taffes sur un document ou bien un programme, ton hdd crash => tu perds 1h de ton taff maxi
(backup sur un deuxieme hdd evidement)

 
C'est pas ca le problème. C'est que le risque de réinventer la roue, c'est s'exposer à son manque d'expérience (on en a toujours) et au fait que ceux qui ont fait des programmes pour ont un minimum réfléchi à la chose. Un shell script de sauvegarde peut avoir des effets de bords imperceptibles, et pour des sauvegardes, ca peut devenir grave.
 
 

 
En considérant que le script n'a pas merdé entre temps, que le fichier n'a pas été corrompu passivement (encore bien pire qu'une sauvegarde perdue, de la corruption passive), etc. Non, tar/cpio/pax ne l'empêche pas, malheureusement.

ouais, voilà, c'est exactement ce que je cherche sur mon topic backup à moi ! Pas avoir à ré-inventer la roue et à tomber dans les 10000 pièges que ça comporte moi-même.
 
Et puis dégager du temps pour surfer, puisque y'en a que ça amuse de passer du temps devant leur écran, autant répartir les tâches.