Discussion :

[exyacc]

bonjour,

voici mon problème:

j'ai plusieurs sites ou j'ai un soft qui fait des backup de leurs bases de données et les upload sur un serveur FTP pour que je puisse les rapatriées sur mon poste.

j'étais en train de regarder les sauvegardes différentielle, et je me disais que ce serait bien que je fasse un backup complet que je rapatrie et après je rapatrie juste les sauvegardes différentielles tant que celles ci ne sont pas plus grosse que le backup 'entier'...
mais y'a un problème... sur les sites, ils font leur sauvegarde(complete) le soir sur clé usb , donc du coup le prochain backup différentiel qui sera envoyé sur le ftp par mon programme repartira de zéro et ne sera pas bon (puisque j'ai pas eu connaissance du nouveau backup complet)... je sais pas si je suis clair
y'a un moyen de palier a ce problème ?

[aieeeuuuuu]

Bonjour,

Il faut que les sauvegardes sur clef soit faite avec l'option COPY_ONLY afin de ne pas "réinitialiser" la chaine des sauvegardes différentielles.

Cela dit, dites nous en plus sur le contexte, les contraintes,... car d'autres possibilités seront sans doute plus efficaces globalement, je pense par exemple au log shipping.

[exyacc]

merci pour ta réponse.

plus précis..

disons par exemple qu'il y a 100 clients qui ont une base de données DATA.
cette base fait entre 50-500 megas.
Mon programme backup la base, la zip et l'upload sur ftp. donc sur le ftp j'ai 100 zip de backup.
le soir ils font leur "propre" sauvegarde
il utilise régulièrement un programme pour 'vider' le log, car il peut atteindre plusieurs giga... et ils voient pas l'utilité de garder le log car en cas de problème, ils restaurent le backup de la veille
donc moi, je rapatrie sur mon micro les 100 backup que je telecharge du FTP et que je restaure en changeant leur nom(pour pas avoir 100 bases DATA ) .

COPY_ONLY, ça peut être pas mal, le problème est qu'ils passent généralement par l'outil "sauvegarder" de leur programme...

[SQLpro]

merci pour ta réponse.

plus précis..

disons par exemple qu'il y a 100 clients qui ont une base de données DATA.
cette base fait entre 50-500 megas.

Avec moins de 1 go c'est stupide de faire du différentiel. Cela va complexifier la restauration le jour ou... Personnellement je ne fais jamais de DIFF pour des bases en dessous de 100 GO !

Mon programme backup la base, la zip et l'upload sur ftp. donc sur le ftp j'ai 100 zip de backup.

AU liue de faire du ZIP, activez la compression des sauvegarde (option WITH COMPRESSION)

le soir ils font leur "propre" sauvegarde
il utilise régulièrement un programme pour 'vider' le log, car il peut atteindre plusieurs giga... et ils voient pas l'utilité de garder le log car en cas de problème, ils restaurent le backup de la veille

Dans ce cas mettez les bases en mode de récupération SIMPLE !!!!

donc moi, je rapatrie sur mon micro les 100 backup que je telecharge du FTP et que je restaure en changeant leur nom(pour pas avoir 100 bases DATA ) .

COPY_ONLY, ça peut être pas mal, le problème est qu'ils passent généralement par l'outil "sauvegarder" de leur programme...

A +

[exyacc]

quand tu passes tout par upload, je prefere transferer 100 fois 10 megas que 100 fois 100 megas...

"WITH COMPRESSION", je peux pas, c'est un sql server express (sinon ça marche bien ? plus efficace que zip ?)

[SQLpro]

Plus efficace que ZIP, oui :
1) taux de compression proche
2) durée des sauvegarde diminuée sensiblement jusqu'à 6 fois moins long
3) durée des restaurations diminuée aussi d'au moins 2 fois.

A +

[SQLpro]

Bonjour,

Il faut que les sauvegardes sur clef soit faite avec l'option COPY_ONLY afin de ne pas "réinitialiser" la chaine des sauvegardes différentielles.

Cela dit, dites nous en plus sur le contexte, les contraintes,... car d'autres possibilités seront sans doute plus efficaces globalement, je pense par exemple au log shipping.

Les différentielles sont cumulative et contiennent toutes les données depuis la dernière FULL. COPY_ONLY ne sert que pour les transactionnelles.

A +