Pour faire mes backup, j'ai, de mes petits doigts, écrit ceci:
find ./ -type f -iregex ".*[^\.bak]" -ctime 2 -exec cp -vp --parents {}
../backup \;
1- ca semble bien marcher, mais n'existe-t-il pas plus simple ?
2- Comment, avec les regex, interdire les .bak *et* les ~.* *et* les
.*~; formet un /ou/ dans /non/ ?
Dans mon cas de figure , la consistance du file systeme n'a pas enormement d'importance (ERP + BASE DE DONNEE) car je peux le
justement c est dans ce type de cas que c est important, si ta base de donnée n est pas consistante, alors ta restauration ne servira a rien, tu peux mettre les fichiers de la base a la poubelle.
as tu fais des tests de restaurations?
et Même des restaurations réelles !!
tu devrais faire un export de ta base (a chaud ou a froid) avant le backup, et c est celui ci qui sera restaure en cas de crash
C'est le cas la procedure est la suivante : Arret des processus SERVEUR ERP Kill des processus clients qui trainent (le client est sous windows :) ) Export de la base Arret de la base Sauvegarde Redemarrage de la base Redemarrage des services ERP Et SURTOUT Lecture de la cartouche !!
La lecture est importante même si cela sollicite beaucoup le lecteur ( le LTO c'est solide on a pour son pognon ! ) Cela permet de detecter rapidement les cartouches "sensibles" cela peut paraitre superflu avec du LTO mais le script a ete mis au point avec des DAT et la c'etait important.
c est quoi comme type de base de données? sur quel os ?
Dans mon cas de figure , la consistance du file systeme n'a pas
enormement d'importance (ERP + BASE DE DONNEE) car je peux le
justement c est dans ce type de cas que c est important, si ta base de
donnée n est pas consistante, alors ta restauration ne servira a rien,
tu peux mettre les fichiers de la base a la poubelle.
as tu fais des tests de restaurations?
et Même des restaurations réelles !!
tu devrais faire un export de ta base (a chaud ou a froid) avant le
backup, et c est celui ci qui sera restaure en cas de crash
C'est le cas la procedure est la suivante :
Arret des processus SERVEUR ERP
Kill des processus clients qui trainent (le client est sous windows :) )
Export de la base
Arret de la base
Sauvegarde
Redemarrage de la base
Redemarrage des services ERP
Et SURTOUT
Lecture de la cartouche !!
La lecture est importante même si cela sollicite beaucoup le lecteur
( le LTO c'est solide on a pour son pognon ! )
Cela permet de detecter rapidement les cartouches "sensibles" cela peut
paraitre superflu avec du LTO mais le script a ete mis au point avec des
DAT et la c'etait important.
c est quoi comme type de base de données? sur quel os ?
Dans mon cas de figure , la consistance du file systeme n'a pas enormement d'importance (ERP + BASE DE DONNEE) car je peux le
justement c est dans ce type de cas que c est important, si ta base de donnée n est pas consistante, alors ta restauration ne servira a rien, tu peux mettre les fichiers de la base a la poubelle.
as tu fais des tests de restaurations?
et Même des restaurations réelles !!
tu devrais faire un export de ta base (a chaud ou a froid) avant le backup, et c est celui ci qui sera restaure en cas de crash
C'est le cas la procedure est la suivante : Arret des processus SERVEUR ERP Kill des processus clients qui trainent (le client est sous windows :) ) Export de la base Arret de la base Sauvegarde Redemarrage de la base Redemarrage des services ERP Et SURTOUT Lecture de la cartouche !!
La lecture est importante même si cela sollicite beaucoup le lecteur ( le LTO c'est solide on a pour son pognon ! ) Cela permet de detecter rapidement les cartouches "sensibles" cela peut paraitre superflu avec du LTO mais le script a ete mis au point avec des DAT et la c'etait important.
c est quoi comme type de base de données? sur quel os ?
Dans mon cas de figure , la consistance du file systeme n'a pas enormement d'importance (ERP + BASE DE DONNEE) car je peux le
justement c est dans ce type de cas que c est important, si ta base de donnée n est pas consistante, alors ta restauration ne servira a rie n, tu peux mettre les fichiers de la base a la poubelle.
as tu fais des tests de restaurations?
et Même des restaurations réelles !!
tu devrais faire un export de ta base (a chaud ou a froid) avant le backup, et c est celui ci qui sera restaure en cas de crash
C'est le cas la procedure est la suivante : Arret des processus SERVEUR ERP Kill des processus clients qui trainent (le client est sous windows :) ) Export de la base Arret de la base Sauvegarde Redemarrage de la base Redemarrage des services ERP Et SURTOUT Lecture de la cartouche !!
et bien dans ce cas no pb :)
La lecture est importante même si cela sollicite beaucoup le lecteur ( le LTO c'est solide on a pour son pognon ! ) Cela permet de detecter rapidement les cartouches "sensibles" cela peut paraitre superflu avec du LTO mais le script a ete mis au point avec de s DAT et la c'etait important.
c est quoi comme type de base de données? sur quel os ?
Dans mon cas de figure , la consistance du file systeme n'a pas
enormement d'importance (ERP + BASE DE DONNEE) car je peux le
justement c est dans ce type de cas que c est important, si ta base de
donnée n est pas consistante, alors ta restauration ne servira a rie n,
tu peux mettre les fichiers de la base a la poubelle.
as tu fais des tests de restaurations?
et Même des restaurations réelles !!
tu devrais faire un export de ta base (a chaud ou a froid) avant le
backup, et c est celui ci qui sera restaure en cas de crash
C'est le cas la procedure est la suivante :
Arret des processus SERVEUR ERP
Kill des processus clients qui trainent (le client est sous windows :) )
Export de la base
Arret de la base
Sauvegarde
Redemarrage de la base
Redemarrage des services ERP
Et SURTOUT
Lecture de la cartouche !!
et bien dans ce cas no pb :)
La lecture est importante même si cela sollicite beaucoup le lecteur
( le LTO c'est solide on a pour son pognon ! )
Cela permet de detecter rapidement les cartouches "sensibles" cela peut
paraitre superflu avec du LTO mais le script a ete mis au point avec de s
DAT et la c'etait important.
c est quoi comme type de base de données? sur quel os ?
Dans mon cas de figure , la consistance du file systeme n'a pas enormement d'importance (ERP + BASE DE DONNEE) car je peux le
justement c est dans ce type de cas que c est important, si ta base de donnée n est pas consistante, alors ta restauration ne servira a rie n, tu peux mettre les fichiers de la base a la poubelle.
as tu fais des tests de restaurations?
et Même des restaurations réelles !!
tu devrais faire un export de ta base (a chaud ou a froid) avant le backup, et c est celui ci qui sera restaure en cas de crash
C'est le cas la procedure est la suivante : Arret des processus SERVEUR ERP Kill des processus clients qui trainent (le client est sous windows :) ) Export de la base Arret de la base Sauvegarde Redemarrage de la base Redemarrage des services ERP Et SURTOUT Lecture de la cartouche !!
et bien dans ce cas no pb :)
La lecture est importante même si cela sollicite beaucoup le lecteur ( le LTO c'est solide on a pour son pognon ! ) Cela permet de detecter rapidement les cartouches "sensibles" cela peut paraitre superflu avec du LTO mais le script a ete mis au point avec de s DAT et la c'etait important.
c est quoi comme type de base de données? sur quel os ?
Dans le message <news:dmq61i$8e3t$, *[SauronDeMordor]* tapota sur f.c.o.unix :
star est plus rapide que tar.
pas significatif, meme si c est vrai
Je viens de faire quelques benchs et effectivement la différence n'es t pas significative. Dans mon souvenir il me semblait que star était vraiment plus rapide.
en fait j ai ete mechant, car effectivement les dernieres version de tar sont plus optimisee, mais si tu compare tar (pas la version gnu) et star, tu v erra une difference, cela dit dans le cas d une arborecences avec bcp de fichi ers, la limitation ne viens plus de tar ou star, mais bel est bien du file system e, pour cela que les commande de type dump sont plus performantes
Dans le message <news:dmq61i$8e3t$1@ng1.exabot.com>,
*[SauronDeMordor]* tapota sur f.c.o.unix :
star est plus rapide que tar.
pas significatif, meme si c est vrai
Je viens de faire quelques benchs et effectivement la différence n'es t
pas significative. Dans mon souvenir il me semblait que star était
vraiment plus rapide.
en fait j ai ete mechant, car effectivement les dernieres version de tar sont
plus optimisee, mais si tu compare tar (pas la version gnu) et star, tu v erra
une difference, cela dit dans le cas d une arborecences avec bcp de fichi ers, la
limitation ne viens plus de tar ou star, mais bel est bien du file system e, pour
cela que les commande de type dump sont plus performantes
Dans le message <news:dmq61i$8e3t$, *[SauronDeMordor]* tapota sur f.c.o.unix :
star est plus rapide que tar.
pas significatif, meme si c est vrai
Je viens de faire quelques benchs et effectivement la différence n'es t pas significative. Dans mon souvenir il me semblait que star était vraiment plus rapide.
en fait j ai ete mechant, car effectivement les dernieres version de tar sont plus optimisee, mais si tu compare tar (pas la version gnu) et star, tu v erra une difference, cela dit dans le cas d une arborecences avec bcp de fichi ers, la limitation ne viens plus de tar ou star, mais bel est bien du file system e, pour cela que les commande de type dump sont plus performantes
