Discussion :

[Isabella]

Bonjour,

Hormis le fait d’optimiser le temps de l’opération de sauvegarde, j’aimerais savoir s’il n y a pas d’autres avantages à choisir de faire des sauvegardes incrémentales entre deux sauvegardes FULL (incrémentales niveau 0)
Ceci dit, je connais bien le principe, une sauvegarde incrémentale ne prend que les blocs modifiés depuis la précédente sauvegarde incrémentale de même niveau si on est en différentiel, ou bien depuis la dernière FULL si on est en cumulative, d’où l’optimisation de l’espace et du temps. Excepté ces deux avantages je n’arrive pas à imaginer un scénario qui met bien en évidence l’utilité (ou la nécessité, peut être) d’utiliser des incrémentales, notamment dans le RESTORE.

Quelqu’un n’a-t-il pas à un exemple pour éclairer ma lanterne ?

Merci

[Isabella]

Allez je vais poser ma question autrement, peut être qu'elle trouvera echo !

le fait de procéder à des sauvegardes quotidiennes incrémentales niveau 1, précédées par une sauvegarde hebdomadaire incrémentale niv 0 (complète donc)
en quoi avantage t-il l'opération de RESOTRE en cas d'incidents

par rapport à la méthode qui consiste à ne faire que des sauvegardes FULL de manière réguilière (2 fois par semaine, par exemple).

Sachant que la base est mode archivelog dans les deux cas.

Merci

[IndianaAngus]

L'avantage du backup incrémental est que le backup se fait plus vite et qu'il prend moins de place qu'un full tout les jours.
Si tu fait un full deux fois par semaine, si tu perd toute ta bases, tu ne pourras la restaurer qu'au dernier backup, donc potentiellement perdre des données sur plusieurs jour.
Maintenant par rapport a un backup full tout les jours et un backup incremental tout les jours, le seul gain que je vois est la place et la vitesse du backup.

[Isabella]

Merci beacoup IndianaAngus pour la réponse,


Pour ce qui est de gain de place et de vitesse de backup, c'est clair, l'incrémental et plus favorable , il n'y a aucun doute la dessus, moi, je voulais savoir s'il n'y a pas un autre
avantage, concernant le RESTORE peut être , ou n'import quel autre volet qui peut motiver le choix de faire des sauvegardes incrémentales

Par contre, lorsque tu me dis ,

"Si tu fait un full deux fois par semaine, si tu perd toute ta bases, tu ne pourras la restaurer qu'au dernier backup, donc potentiellement perdre des données sur plusieurs jour."

là, je ne suis pas tout à fait d'accord avec toi, parce la récupération d'une base dépend des archivelogs et non pas des sauvegardes incrémentales, je veux dire, je peux trés bien récupérer ma base jusqu'à l'instant de l'incident même avec une sauvegarde qui date de loin, pour peu que les archivelogs soient disponbibles, (et les redo logs, naturellement).


si j'ai bien compris ta réponse, sinon, éclaire moit, stp.

[Isabella]

Bonjour à tous,

Encore une fois, je constate que mon post à besoin d’être relooké

En termes plus clairs (j’espère) :
Quand on travaille dans un environnement caractérisé par :

1 / base peu volumineuse, quelques dizaines de gigas

2 / base qui ne suscite pas une très grande disponibilité (pratiquement oisive toute la nuit et les weekends aussi).

3 / espace de sauvegarde (disque et tape) largement suffisant pour contenir des jeux de sauvegardes avec redondance.

Bref, nous n’avons des contraintes ni de temps ni d’espace ni de haute disponibilité

a-t-on vraiment besoin de faire des SAUVEGARDES INCREMENTALES ?

Comme j’ai toujours espoir de trouver réponse à ma question, je suis prête à relooker encore une fois mon post si besoin est

[Pomalaix]

Bref, nous n’avons des contraintes ni de temps ni d’espace ni de haute disponibilité

a-t-on vraiment besoin de faire des SAUVEGARDES INCREMENTALES ?

Pour confirmer ce que vous avez déjà fort bien compris :
le mode incrémental permet de réduire le volume (et potentiellement la durée) des sauvegardes.
Il n'apporte aucun bénéfice au niveau de la restauration, qui risque même, au contraire, d'être plus longue.

Il est clair que vous n'avez aucune raison de faire des sauvegardes incrémentales.

[IndianaAngus]

Oui bien sur le restore dépend aussi des archivelog mais je parle dans le cas ou tu as tout perdu (archivelog, onlinelog, controlfile etc) sauf ton backup et les archivelogs sont dans le backup (enfin si tu l'as spécifié ainsi). Donc faire un backup tout les jours, même un full, on ne sais jamais.

Concernant la réponse à ta question, ben je te dirai fait comme tu veux ou fait en fonction de tes contraintes.
Par exemple, chez nous, nous avons des petites bases (max 25G) et nous faisons uniquement des backups full compressé tout les jours avec rétention d'un seul jour.
En fait tout dépend de comment tu gère tes DB et ton espace de stockage (par exemple si tu paye au giga de backup, dans ce cas le backup incrémental peut être une bonne solution!).

Il faut prendre aussi le temps de restore en compte car tu devras restaurer tout les backups incrémentaux depuis le dernier backup full, ce qui peut potentiellement prendre un peut plus de temps.

Donc pour conclure, je ne vois aucun autre avantage à faire des backup incrémentaux à part ceux déjà cité.

J'espère avoir répondu à ta question

[Pomalaix]

Oui bien sur le restore dépend aussi des archivelog mais je parle dans le cas ou tu as tout perdu (archivelog, onlinelog, controlfile etc) sauf ton backup et les archivelogs sont dans le backup (enfin si tu l'as spécifié ainsi). Donc faire un backup tout les jours, même un full, on ne sais jamais....

J'avoue ne pas comprendre cette argumentation...

Une précaution basique est déjà de définir une destination d'archivage secondaire, qui ne soit pas locale. Ainsi, si le serveur flambe avec tout son contenu, on dispose ailleurs des sauvegardes et des archivelogs.

De plus, on peut (et on doit parfois) sauvegarder les archivelogs plusieurs fois dans la journée, par exemple toutes les 2 heures selon les objectifs de restauration fixés. Que la base elle-même soit sauvegardée tous les jours, ou même une fois par semaine, les archivelogs ont leur propre fréquence de sauvegarde.

Ce qui est décisif, ce sont vraiment les archivelogs.
A l'extrême, si ma dernière sauvegarde date d'un mois, mais que je dispose de tous les archivelogs sans la moindre exception sur cette période, je pourrai mener à bien ma restauration.

[IndianaAngus]

Même si les risques sont faibles, il est tout à fait possible de tout perdre et qu'il ne nous reste que le backup.
Une destination d'archivage secondaire c'est bien, mais l'espace de stockage n'est pas gratuit et il n'est donc pas toujours possible de mettre les archivelogs en deux endroit différent.
C'est bien pour ca que de notre côté par exemple nous faisons des backups full tout les jours avec les archivelogs (qui eux sont en plus backupé toutes les 2 ou 4h en fonction de la base) puis supprimé du disque car cela prend de la place! Les bases sont de toute façon protégé par dataguard.
De toute manière, la stratégie de sauvegarde doit être défini en fonction de l'environnement et des contraintes de chacun.

[Rams7s]

?
Et si on appercoit la semaine d'apres qu'une table importante a ete modifie par erreur?

[Isabella]

Merci les gars pour toutes ces réponses


donc le verdict est :

Lorque l'on a largement le temps de faire des sauvegardes sans ralentir la production ( la nuit par exemple),
Lorsque l'on dispose de suffisamment d'espace pour faire des sauvegardes redondantes,

il est inutile de faire des sauvegardes incrémentales,

maintenant je peux tranquillement mettre la balise RESOLU.

Quant à la question de Rams7s, je crois qu'elle nous envoie vers un autre débat, à mon humble avis il faut explorer les possibilité de la technologie FLASHBACK.

[IndianaAngus]

?
Et si on appercoit la semaine d'apres qu'une table importante a ete modifie par erreur?

Et bien on ressort le backup du moment si on l'as encore. Dans mon cas par exemple, la rétention est de 1 jour dans le controlfile et ensuite les backup sont mis sur tape et sont gardé le temps de la rétention définie avec nos clients.
Et là également, tout dépend du rôle de la base de données et des applications qui l'utilisent.
Pour dire, j'ai travaillé dans une entreprise ou les backups étaient fait avec des exports datapump. Ils étaient conscient du risque mais à cause du prix du stockage, ils étaient d'accord de prendre ce risque.