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/ ?
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/ ?
merci d'avance Bruno euh ya un peu plus simple et efficace.
si tu tombes dans un répertoire avec plein de fichiers ca va lagger ton système.
regarde du cotes de rsync (ca sera un peu mieux) genre rsync -av --exclud e=... ou rsync --backup
mais tu as aussi les commandes comme dump/restore, tar et consorts
Bonjour à tous,
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/ ?
merci d'avance
Bruno
euh ya un peu plus simple et efficace.
si tu tombes dans un répertoire avec plein de fichiers ca va lagger ton système.
regarde du cotes de rsync (ca sera un peu mieux) genre rsync -av --exclud e=...
ou rsync --backup
mais tu as aussi les commandes comme dump/restore, tar et consorts
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/ ?
merci d'avance Bruno euh ya un peu plus simple et efficace.
si tu tombes dans un répertoire avec plein de fichiers ca va lagger ton système.
regarde du cotes de rsync (ca sera un peu mieux) genre rsync -av --exclud e=... ou rsync --backup
mais tu as aussi les commandes comme dump/restore, tar et consorts
Chris
Bruno-L wrote:
Bonjour à tous,
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/ ?
$TAR => /usr/local/bin/tar gnutar ou autre binaire tar ${device} => un fichier ou un péripherique ${LABEL} => Sauvegarde du DD/MM/YYY a HH:MM cela evite de se tromper ${FROM_FILE} => contient / ou la liste des repertoires a sauver ${EXCLUDE_FILE} => contient /proc /var/log
l'option --totals est tres bien et l'on peut meme generer des fichiers de taille defini avec un script perl a coté, si cela interresse je le publie sur ce ng
<troll> tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long ... avez vous du retour sur ce point </troll>
A+ chris
Bruno-L wrote:
Bonjour à tous,
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/ ?
$TAR => /usr/local/bin/tar gnutar ou autre binaire tar
${device} => un fichier ou un péripherique
${LABEL} => Sauvegarde du DD/MM/YYY a HH:MM cela evite de se tromper
${FROM_FILE} => contient / ou la liste des repertoires a sauver
${EXCLUDE_FILE} => contient /proc /var/log
l'option --totals est tres bien et l'on peut meme generer des fichiers
de taille defini avec un script perl a coté, si cela interresse je le
publie sur ce ng
<troll>
tar est tres pratique pour les sauvegardes car portables d'OS en OS
surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long ...
avez vous du retour sur ce point
</troll>
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/ ?
$TAR => /usr/local/bin/tar gnutar ou autre binaire tar ${device} => un fichier ou un péripherique ${LABEL} => Sauvegarde du DD/MM/YYY a HH:MM cela evite de se tromper ${FROM_FILE} => contient / ou la liste des repertoires a sauver ${EXCLUDE_FILE} => contient /proc /var/log
l'option --totals est tres bien et l'on peut meme generer des fichiers de taille defini avec un script perl a coté, si cela interresse je le publie sur ce ng
<troll> tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long ... avez vous du retour sur ce point </troll>
A+ chris
[SauronDeMordor]
Bruno-L wrote:
Bonjour à tous,
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/ ?
$TAR => /usr/local/bin/tar gnutar ou autre binaire tar ${device} => un fichier ou un péripherique ${LABEL} => Sauvegarde du DD/MM/YYY a HH:MM cela evite de se tromper ${FROM_FILE} => contient / ou la liste des repertoires a sauver ${EXCLUDE_FILE} => contient /proc /var/log
l'option --totals est tres bien et l'on peut meme generer des fichiers de taille defini avec un script perl a coté, si cela interresse je le publie sur ce ng
<troll> tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long ... avez vous du retour sur ce point </troll>
c est un petit troll,
oui tar est trop long quand tu a beaucoup de fichiers. de plus il ne fait pas une sauvegarde d un etat consistant du file system e, pour cela il faudrait faire des snapshots du filesysteme avant (mais ca implqi e des contraine au niveau de l os, comem l utilisation de LVM)
A+ chris
Bruno-L wrote:
Bonjour à tous,
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/ ?
$TAR => /usr/local/bin/tar gnutar ou autre binaire tar
${device} => un fichier ou un péripherique
${LABEL} => Sauvegarde du DD/MM/YYY a HH:MM cela evite de se tromper
${FROM_FILE} => contient / ou la liste des repertoires a sauver
${EXCLUDE_FILE} => contient /proc /var/log
l'option --totals est tres bien et l'on peut meme generer des fichiers
de taille defini avec un script perl a coté, si cela interresse je le
publie sur ce ng
<troll>
tar est tres pratique pour les sauvegardes car portables d'OS en OS
surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long ...
avez vous du retour sur ce point
</troll>
c est un petit troll,
oui tar est trop long quand tu a beaucoup de fichiers.
de plus il ne fait pas une sauvegarde d un etat consistant du file system e, pour
cela il faudrait faire des snapshots du filesysteme avant (mais ca implqi e des
contraine au niveau de l os, comem l utilisation de LVM)
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/ ?
$TAR => /usr/local/bin/tar gnutar ou autre binaire tar ${device} => un fichier ou un péripherique ${LABEL} => Sauvegarde du DD/MM/YYY a HH:MM cela evite de se tromper ${FROM_FILE} => contient / ou la liste des repertoires a sauver ${EXCLUDE_FILE} => contient /proc /var/log
l'option --totals est tres bien et l'on peut meme generer des fichiers de taille defini avec un script perl a coté, si cela interresse je le publie sur ce ng
<troll> tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long ... avez vous du retour sur ce point </troll>
c est un petit troll,
oui tar est trop long quand tu a beaucoup de fichiers. de plus il ne fait pas une sauvegarde d un etat consistant du file system e, pour cela il faudrait faire des snapshots du filesysteme avant (mais ca implqi e des contraine au niveau de l os, comem l utilisation de LVM)
A+ chris
Chris
[SauronDeMordor] wrote:
<troll> tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long ... avez vous du retour sur ce point </troll>
c est un petit troll,
oui tar est trop long quand tu a beaucoup de fichiers. de plus il ne fait pas une sauvegarde d un etat consistant du file systeme, pour cela il faudrait faire des snapshots du filesysteme avant (mais ca implqie des contraine au niveau de l os, comem l utilisation de LVM)
Dans mon cas de figure , la consistance du file systeme n'a pas enormement d'importance (ERP + BASE DE DONNEE) car je peux le reconstruire facilement je prefere m'appuyer sur la multiplication des cartouches de sauvegardes et pour la lenteur sur la puissance materielle (LTO/ULTRIUM) En revanche j'ai un seul logiciel pour la majorité de mes serveurs et une seul methode ce qui est apreciable Dans certain cas extreme on a prefere cette solution sous windows + cygwin pour eviter certain debordement de budget.
A+ chris
[SauronDeMordor] wrote:
<troll>
tar est tres pratique pour les sauvegardes car portables d'OS en OS
surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long ...
avez vous du retour sur ce point
</troll>
c est un petit troll,
oui tar est trop long quand tu a beaucoup de fichiers.
de plus il ne fait pas une sauvegarde d un etat consistant du file
systeme, pour cela il faudrait faire des snapshots du filesysteme avant
(mais ca implqie des contraine au niveau de l os, comem l utilisation de
LVM)
Dans mon cas de figure , la consistance du file systeme n'a pas
enormement d'importance (ERP + BASE DE DONNEE) car je peux le
reconstruire facilement je prefere m'appuyer sur la multiplication des
cartouches de sauvegardes
et pour la lenteur sur la puissance materielle (LTO/ULTRIUM)
En revanche j'ai un seul logiciel pour la majorité de mes serveurs
et une seul methode ce qui est apreciable
Dans certain cas extreme on a prefere cette solution sous windows +
cygwin pour eviter certain debordement de budget.
<troll> tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long ... avez vous du retour sur ce point </troll>
c est un petit troll,
oui tar est trop long quand tu a beaucoup de fichiers. de plus il ne fait pas une sauvegarde d un etat consistant du file systeme, pour cela il faudrait faire des snapshots du filesysteme avant (mais ca implqie des contraine au niveau de l os, comem l utilisation de LVM)
Dans mon cas de figure , la consistance du file systeme n'a pas enormement d'importance (ERP + BASE DE DONNEE) car je peux le reconstruire facilement je prefere m'appuyer sur la multiplication des cartouches de sauvegardes et pour la lenteur sur la puissance materielle (LTO/ULTRIUM) En revanche j'ai un seul logiciel pour la majorité de mes serveurs et une seul methode ce qui est apreciable Dans certain cas extreme on a prefere cette solution sous windows + cygwin pour eviter certain debordement de budget.
A+ chris
[SauronDeMordor]
[SauronDeMordor] wrote:
<troll> tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long . .. avez vous du retour sur ce point </troll>
c est un petit troll,
oui tar est trop long quand tu a beaucoup de fichiers. de plus il ne fait pas une sauvegarde d un etat consistant du file systeme, pour cela il faudrait faire des snapshots du filesysteme avant (mais ca implqie des contraine au niveau de l os, comem l utilisation de LVM)
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 do nnée n est pas consistante, alors ta restauration ne servira a rien, tu peux met tre les fichiers de la base a la poubelle.
as tu fais des tests de restaurations?
tu devrais faire un export de ta base (a chaud ou a froid) avant le backu p, et c est celui ci qui sera restaure en cas de crash
c est quoi comme type de base de données? sur quel os ?
reconstruire facilement je prefere m'appuyer sur la multiplication des cartouches de sauvegardes et pour la lenteur sur la puissance materielle (LTO/ULTRIUM) En revanche j'ai un seul logiciel pour la majorité de mes serveurs et une seul methode ce qui est apreciable Dans certain cas extreme on a prefere cette solution sous windows + cygwin pour eviter certain debordement de budget.
A+ chris
[SauronDeMordor] wrote:
<troll>
tar est tres pratique pour les sauvegardes car portables d'OS en OS
surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long . ..
avez vous du retour sur ce point
</troll>
c est un petit troll,
oui tar est trop long quand tu a beaucoup de fichiers.
de plus il ne fait pas une sauvegarde d un etat consistant du file
systeme, pour cela il faudrait faire des snapshots du filesysteme
avant (mais ca implqie des contraine au niveau de l os, comem l
utilisation de LVM)
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 do nnée n
est pas consistante, alors ta restauration ne servira a rien, tu peux met tre les
fichiers de la base a la poubelle.
as tu fais des tests de restaurations?
tu devrais faire un export de ta base (a chaud ou a froid) avant le backu p, et c
est celui ci qui sera restaure en cas de crash
c est quoi comme type de base de données? sur quel os ?
reconstruire facilement je prefere m'appuyer sur la multiplication des
cartouches de sauvegardes
et pour la lenteur sur la puissance materielle (LTO/ULTRIUM)
En revanche j'ai un seul logiciel pour la majorité de mes serveurs
et une seul methode ce qui est apreciable
Dans certain cas extreme on a prefere cette solution sous windows +
cygwin pour eviter certain debordement de budget.
<troll> tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
par contre plusieurs personnes m'ont certifies le trouver trop long . .. avez vous du retour sur ce point </troll>
c est un petit troll,
oui tar est trop long quand tu a beaucoup de fichiers. de plus il ne fait pas une sauvegarde d un etat consistant du file systeme, pour cela il faudrait faire des snapshots du filesysteme avant (mais ca implqie des contraine au niveau de l os, comem l utilisation de LVM)
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 do nnée n est pas consistante, alors ta restauration ne servira a rien, tu peux met tre les fichiers de la base a la poubelle.
as tu fais des tests de restaurations?
tu devrais faire un export de ta base (a chaud ou a froid) avant le backu p, et c est celui ci qui sera restaure en cas de crash
c est quoi comme type de base de données? sur quel os ?
reconstruire facilement je prefere m'appuyer sur la multiplication des cartouches de sauvegardes et pour la lenteur sur la puissance materielle (LTO/ULTRIUM) En revanche j'ai un seul logiciel pour la majorité de mes serveurs et une seul methode ce qui est apreciable Dans certain cas extreme on a prefere cette solution sous windows + cygwin pour eviter certain debordement de budget.
A+ chris
TiChou
Dans le message <news:43901136$0$28628$, *Chris* tapota sur f.c.o.unix :
tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
Oui, mais tar ne permet pas, entre autre, de sauvegarder les ACL et les attributs étendus, de conserver les fichiers à trou (GNU tar le permet) et des exclusions avec des motifs évolués.
C'est pourquoi on lui préfère star. En plus, star permet de faire des vraies sauvegardes incrémentielles, de mieux contrôler les erreurs et d'être compatible avec de nombreux formats d'archive (tar, cpio, pax, ...). Il apporte aussi un meilleur support des lecteurs à bande.
par contre plusieurs personnes m'ont certifies le trouver trop long ...
star est plus rapide que tar.
-- TiChou
Dans le message <news:43901136$0$28628$636a15ce@news.free.fr>,
*Chris* tapota sur f.c.o.unix :
tar est tres pratique pour les sauvegardes car portables d'OS en OS
surtout la version GNU
Oui, mais tar ne permet pas, entre autre, de sauvegarder les ACL et les
attributs étendus, de conserver les fichiers à trou (GNU tar le permet) et
des exclusions avec des motifs évolués.
C'est pourquoi on lui préfère star. En plus, star permet de faire des vraies
sauvegardes incrémentielles, de mieux contrôler les erreurs et d'être
compatible avec de nombreux formats d'archive (tar, cpio, pax, ...). Il
apporte aussi un meilleur support des lecteurs à bande.
par contre plusieurs personnes m'ont certifies le trouver trop long ...
Dans le message <news:43901136$0$28628$, *Chris* tapota sur f.c.o.unix :
tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
Oui, mais tar ne permet pas, entre autre, de sauvegarder les ACL et les attributs étendus, de conserver les fichiers à trou (GNU tar le permet) et des exclusions avec des motifs évolués.
C'est pourquoi on lui préfère star. En plus, star permet de faire des vraies sauvegardes incrémentielles, de mieux contrôler les erreurs et d'être compatible avec de nombreux formats d'archive (tar, cpio, pax, ...). Il apporte aussi un meilleur support des lecteurs à bande.
par contre plusieurs personnes m'ont certifies le trouver trop long ...
star est plus rapide que tar.
-- TiChou
[SauronDeMordor]
Dans le message <news:43901136$0$28628$, *Chris* tapota sur f.c.o.unix :
tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
Oui, mais tar ne permet pas, entre autre, de sauvegarder les ACL et les attributs étendus, de conserver les fichiers à trou (GNU tar le per met) et des exclusions avec des motifs évolués.
tout a fait et egalement le probleme des fichiers >32go de tar (meme sur les architectures 64bits) gnu tar aussi a le pb, pas star
C'est pourquoi on lui préfère star. En plus, star permet de faire d es vraies sauvegardes incrémentielles, de mieux contrôler les erreurs et d'être compatible avec de nombreux formats d'archive (tar, cpio, pax, ...). Il apporte aussi un meilleur support des lecteurs à bande.
par contre plusieurs personnes m'ont certifies le trouver trop long .. .
star est plus rapide que tar.
pas significatif, meme si c est vrai
Dans le message <news:43901136$0$28628$636a15ce@news.free.fr>,
*Chris* tapota sur f.c.o.unix :
tar est tres pratique pour les sauvegardes car portables d'OS en OS
surtout la version GNU
Oui, mais tar ne permet pas, entre autre, de sauvegarder les ACL et les
attributs étendus, de conserver les fichiers à trou (GNU tar le per met)
et des exclusions avec des motifs évolués.
tout a fait et egalement le probleme des fichiers >32go de tar (meme sur les
architectures 64bits) gnu tar aussi a le pb, pas star
C'est pourquoi on lui préfère star. En plus, star permet de faire d es
vraies sauvegardes incrémentielles, de mieux contrôler les erreurs et
d'être compatible avec de nombreux formats d'archive (tar, cpio, pax,
...). Il apporte aussi un meilleur support des lecteurs à bande.
par contre plusieurs personnes m'ont certifies le trouver trop long .. .
Dans le message <news:43901136$0$28628$, *Chris* tapota sur f.c.o.unix :
tar est tres pratique pour les sauvegardes car portables d'OS en OS surtout la version GNU
Oui, mais tar ne permet pas, entre autre, de sauvegarder les ACL et les attributs étendus, de conserver les fichiers à trou (GNU tar le per met) et des exclusions avec des motifs évolués.
tout a fait et egalement le probleme des fichiers >32go de tar (meme sur les architectures 64bits) gnu tar aussi a le pb, pas star
C'est pourquoi on lui préfère star. En plus, star permet de faire d es vraies sauvegardes incrémentielles, de mieux contrôler les erreurs et d'être compatible avec de nombreux formats d'archive (tar, cpio, pax, ...). Il apporte aussi un meilleur support des lecteurs à bande.
par contre plusieurs personnes m'ont certifies le trouver trop long .. .
star est plus rapide que tar.
pas significatif, meme si c est vrai
TiChou
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'est pas significative. Dans mon souvenir il me semblait que star était vraiment plus rapide.
-- TiChou
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'est pas
significative. Dans mon souvenir il me semblait que star était vraiment plus
rapide.
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'est pas significative. Dans mon souvenir il me semblait que star était vraiment plus rapide.
-- TiChou
Patrice Trognon
Bruno-L wrote:
Bonjour à tous,
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/ ?
merci d'avance Bruno
hi,
Perso pour un backup des fichiers pour lesquels je n'ai pas besoin de gérer des versions, j'utilise rsync.
Quand j'ai besoin de gérer des versions je sauve par svn (SubVersion).
Les services rsyn et svn sont sur la même machine, leur répertoires respectifs sont sauvegardée sur une bande par un bon vieux tar (enfin gtar).
ainsi si j'ai perte des données sur mes machines de travail je peux récupérer les infos a partir du serveur SVN ou du serveur rsync.
Si j'ai perte des données sur mes machines de travail ET sur le serveur de backup j'ai toujours une bande pour repartir de zero, au moins le boulot est sauvegardé.
rsync est incrémental, très simple à installer coté serveur et client. SVN est lui aussi très simple à installer coté serveur et client, j'y sauve bien sur mes projets de développement, mais aussi mes fichiers de type PDF, ou OpenOffice.
Voila.
--
Patrice Trognon http://www.javadevel.com
Bruno-L wrote:
Bonjour à tous,
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/ ?
merci d'avance
Bruno
hi,
Perso pour un backup des fichiers pour lesquels je n'ai pas besoin de
gérer des versions, j'utilise rsync.
Quand j'ai besoin de gérer des versions je sauve par svn (SubVersion).
Les services rsyn et svn sont sur la même machine, leur répertoires
respectifs sont sauvegardée sur une bande par un bon vieux tar (enfin
gtar).
ainsi si j'ai perte des données sur mes machines de travail je peux
récupérer les infos a partir du serveur SVN ou du serveur rsync.
Si j'ai perte des données sur mes machines de travail ET sur le
serveur de backup j'ai toujours une bande pour repartir
de zero, au moins le boulot est sauvegardé.
rsync est incrémental, très simple à installer coté serveur et client.
SVN est lui aussi très simple à installer coté serveur et client,
j'y sauve bien sur mes projets de développement, mais aussi mes fichiers
de type PDF, ou OpenOffice.
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/ ?
merci d'avance Bruno
hi,
Perso pour un backup des fichiers pour lesquels je n'ai pas besoin de gérer des versions, j'utilise rsync.
Quand j'ai besoin de gérer des versions je sauve par svn (SubVersion).
Les services rsyn et svn sont sur la même machine, leur répertoires respectifs sont sauvegardée sur une bande par un bon vieux tar (enfin gtar).
ainsi si j'ai perte des données sur mes machines de travail je peux récupérer les infos a partir du serveur SVN ou du serveur rsync.
Si j'ai perte des données sur mes machines de travail ET sur le serveur de backup j'ai toujours une bande pour repartir de zero, au moins le boulot est sauvegardé.
rsync est incrémental, très simple à installer coté serveur et client. SVN est lui aussi très simple à installer coté serveur et client, j'y sauve bien sur mes projets de développement, mais aussi mes fichiers de type PDF, ou OpenOffice.
Voila.
--
Patrice Trognon http://www.javadevel.com
Emmanuel Florac
Le Sat, 03 Dec 2005 21:45:52 +0100, Patrice Trognon a écrit :
Perso pour un backup des fichiers pour lesquels je n'ai pas besoin de gérer des versions, j'utilise rsync.
Quand j'ai besoin de gérer des versions je sauve par svn (SubVersion).
Et c'est une connerie. Subversion stocke les données dans un format inexploitable directement, en cas de pain sur le repository ton backup est foutu. En plus, subversion gère assez mal les gros transferts en particulier à travers le réseau, et c'est normal parce qu'après tout il jn'est pas du tout faitt pour faire des backups mais pour coder...
Il vaut bien mieux utiliser rdiff-backup, qui est fait pour ça, qui stocke les données dans un format exploitable en direct, et permet de gérer les versions très facilement.
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
Le Sat, 03 Dec 2005 21:45:52 +0100, Patrice Trognon a écrit :
Perso pour un backup des fichiers pour lesquels je n'ai pas besoin de
gérer des versions, j'utilise rsync.
Quand j'ai besoin de gérer des versions je sauve par svn (SubVersion).
Et c'est une connerie. Subversion stocke les données dans un format
inexploitable directement, en cas de pain sur le repository ton backup est
foutu. En plus, subversion gère assez mal les gros transferts en
particulier à travers le réseau, et c'est normal parce qu'après tout il
jn'est pas du tout faitt pour faire des backups mais pour coder...
Il vaut bien mieux utiliser rdiff-backup, qui est fait pour ça, qui
stocke les données dans un format exploitable en direct, et permet de
gérer les versions très facilement.
--
Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir
aristocratique de déplaire.
C. Baudelaire.
Le Sat, 03 Dec 2005 21:45:52 +0100, Patrice Trognon a écrit :
Perso pour un backup des fichiers pour lesquels je n'ai pas besoin de gérer des versions, j'utilise rsync.
Quand j'ai besoin de gérer des versions je sauve par svn (SubVersion).
Et c'est une connerie. Subversion stocke les données dans un format inexploitable directement, en cas de pain sur le repository ton backup est foutu. En plus, subversion gère assez mal les gros transferts en particulier à travers le réseau, et c'est normal parce qu'après tout il jn'est pas du tout faitt pour faire des backups mais pour coder...
Il vaut bien mieux utiliser rdiff-backup, qui est fait pour ça, qui stocke les données dans un format exploitable en direct, et permet de gérer les versions très facilement.
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
