mécanisme de sauvegarde de données

Bonjour,

AG a écrit :

1°) Utilisation d'outils de synchronisation (des cadenas (locks) ) mais
j'ai comme l'impression que contre un reboot intempestif, même le
meilleurs des cadenas ne sera pas d'une grande utilité.

2°) Utilisation de deux fichiers de sauvegarde dans lesquels on vient
sauvegarder alternativement les données. Si le système plante lors de la
sauvegarde sur l'un des fichiers, l'utilisation de l'autre permet une
restauration du système.

Un truc comme ça, avec le fichier nommé en fonction du jour et de l'heure.

Et pour être sur que le fichier est valide, placer un flag en debut de
fichier une fois toutes les données ecrites:
En gros :
fopen
fwrite(0)
fflush
fwrite(data) ..
fseek 0, CUR_SET
fwrite(1)
fclose (flush implicite)


--
« Le travail est probablement ce qu'il y a sur cette terre de plus bas et
de plus ignoble. Il n'est pas possible de regarder un travailleur sans
maudire ce qui a fait que cet homme travaille, alors qu'il pourrait nager,
dormir dans l'herbe ou simplement lire ou faire l'amour avec sa femme. »
Boris VIAN

Mon blog RSS : http://yarglah.free.fr/monblog_rss.php <<

AG a écrit :

Bonjour,

j'ai une petite application de calcul en C, qui peut tourner plusieurs
jours de suite. Pour ne pas avoir à recalculer tout depuis le début
lorsque l'application plante (soit parce que je décide de l'arrêter,
soit parce que la machine sur laquelle elle tourne, plante, soit pour
n'importe quelle autre raison), je sauvegarde les résultats
intermédiaires dans un fichier texte. Mes sauvegardes sont périodique s.

Mais il peut arriver que le système plante au moment ou la sauvegarde
est en train d'être effectuée, et là, pour le coup, je perds toutes mes
données.

Quels sont les mécanismes classiques qui permettent un sauvegarde sûr e ?

J'ai pensé à :

1°) Utilisation d'outils de synchronisation (des cadenas (locks) ) mais
j'ai comme l'impression que contre un reboot intempestif, même le
meilleurs des cadenas ne sera pas d'une grande utilité.

2°) Utilisation de deux fichiers de sauvegarde dans lesquels on vient
sauvegarder alternativement les données. Si le système plante lors de la
sauvegarde sur l'un des fichiers, l'utilisation de l'autre permet une
restauration du système.

Quelles sont les mécanismes classiques pour résoudre ce problème ?

Un mécanisme de journalisation, avec des opérations transactionnelles
pour la sauvegarde (commit/rollback).

Est-il possible de s'en tirer avec seulement 1 fichier de sauvegarde ?

Le plus simple, c'est d'utiliser pour ton stockage une base de donnée
transactionnelle (MSDE par exemple), ou bien un système transactionnel
tout fait (écrire soi-même un moteuer transactionnel me semble
illusoire pour la plupart des genrs).

Arnaud

adebaene@club-internet.fr wrote:

Un mécanisme de journalisation, avec des opérations transactionnelles
pour la sauvegarde (commit/rollback).

Un mécanisme de journalisation, je crois que je vois :

On sauve l'état de départ, puis on ajoute un ligne pour chaque
différence depuis le dernier état sauvegardé. ça permet de remonter dans
le temps les états de sauvegarde (ça doit être le rollback ?)

Est-il possible de s'en tirer avec seulement 1 fichier de sauvegarde ?

Le plus simple, c'est d'utiliser pour ton stockage une base de donnée
transactionnelle (MSDE par exemple), ou bien un système transactionnel
tout fait (écrire soi-même un moteuer transactionnel me semble
illusoire pour la plupart des genrs).

Une base de donnée, je vois bien, transactionnelle, je vois moins déjà.
mais j'imagine que c'est pour décrire la manière dont les échanges de
données sont faits (les transactions), et pour dire que c'est fait par
des opérations transactionnelles (?) dont on a parlé plus haut (genre,
le nouvel état du système est sauvegardé uniquement si la transaction
c'est bien passée, sinon on revient à l'état d'avant ?)

Bon, de toute façon, je ne m'en servirait pas, c'était pour ma culture.
Mon code n'est pas destiné à aller en production, c'est juste pour mes
besoins personnels. Un système de deux fichiers suffira je pense.

Merci.

Alexandre.

AG a écrit :

adebaene@club-internet.fr wrote:

> Un mécanisme de journalisation, avec des opérations transactionnell es
> pour la sauvegarde (commit/rollback).
Un mécanisme de journalisation, je crois que je vois :

On sauve l'état de départ, puis on ajoute un ligne pour chaque
différence depuis le dernier état sauvegardé. ça permet de remont er dans
le temps les états de sauvegarde (ça doit être le rollback ?)

Plus précisemment:
- lorsque l'opération est réalisée elle est écrite dans un journal
de transaction (et pas sur le support final).
- plus tard, lorsque la transaction est validée ("commit") ou même
après, l'opération est réalisée sur le support final.
- Seulement une fois que l'opération est effectivement effectuée sur
le support final, le journal de transaction est effacé (et encore, sur
de nombreux système, SQL Server par exemple, le journal de transaction
est effacé beaucoup plus tard, typiquement quand un backup du système
est effectué, de façon à pouvoir restaurer n'importe quel état
cohérent de la base avant la dernière sauvegarde).

>
>>Est-il possible de s'en tirer avec seulement 1 fichier de sauvegarde ?
>
> Le plus simple, c'est d'utiliser pour ton stockage une base de donnée
> transactionnelle (MSDE par exemple), ou bien un système transactionnel
> tout fait (écrire soi-même un moteuer transactionnel me semble
> illusoire pour la plupart des genrs).
Une base de donnée, je vois bien, transactionnelle, je vois moins déj à.

Les bases "sérieuses" (MSDE, Oracle, SQL Server, ...) offrent un
mécanisme transactionnel. Ce n'est pas le cas d'Access. Pour MySql, si
mes souvenirs sont bons, c'est un peu plus compliqué : ca dépend du
type de base utilisée.

mais j'imagine que c'est pour décrire la manière dont les échanges de
données sont faits (les transactions), et pour dire que c'est fait par
des opérations transactionnelles (?) dont on a parlé plus haut (genre,
le nouvel état du système est sauvegardé uniquement si la transacti on
c'est bien passée, sinon on revient à l'état d'avant ?)

Oui : un système journalisé et transactionnel garantit que, même en
cas de coupure de courant, l'état de la base sera cohérent (soit la
transaction complète sera enregistrée, soit aucune opération faisant
partie de la transaction ne sera enregistrée).

Pour info, NTFS utilise un mécanisme transactionnel pour ses
structures internes, pour garantir qu'une partition ne sera jamais
foutue en l'air par une panne de courant. Par contre, le contenu des
fichiers lui-même n'est pas journalisé (ce serait trop lourd en
espace disque pris par le journal et en temps de réponse).

Bon, de toute façon, je ne m'en servirait pas, c'était pour ma cultur e.
Mon code n'est pas destiné à aller en production, c'est juste pour mes
besoins personnels.

MSDE irait bien dans ce cas là.

Arnaud

adebaene@club-internet.fr wrote in
news:1123171717.390528.209360@g43g2000cwa.googlegroups.com:

- lorsque l'opération est réalisée elle est écrite dans un journal
de transaction (et pas sur le support final).
- plus tard, lorsque la transaction est validée ("commit") ou même
après, l'opération est réalisée sur le support final.
- Seulement une fois que l'opération est effectivement effectuée sur
le support final, le journal de transaction est effacé (et encore, sur
de nombreux système, SQL Server par exemple, le journal de transaction
est effacé beaucoup plus tard, typiquement quand un backup du système
est effectué, de façon à pouvoir restaurer n'importe quel état
cohérent de la base avant la dernière sauvegarde).

- La journalisation peut aussi être une optimisation :
1. il est possible de laisser le journal un moment en mémoire ce
qui évite les accès disque inutiles (par ex si une ligne est changée
deux fois au cours de la transaction) 2. lorsqu'on écrit sur le
disque, on le fait dans un ordre cohérent (moins d'allers-retours
des têtes d'écriture).

Bon, de toute façon, je ne m'en servirait pas, c'était pour ma
culture. Mon code n'est pas destiné à aller en production, c'est
juste pour mes besoins personnels.

MSDE irait bien dans ce cas là.

S'il peut se payer le luxe de créer des fichiers distincts, c'est aussi
beaucoup plus simple.

En fait, la méthode des deux fichiers est une forme de "journalisation
du pauvre", le journal étant le second fichier et l'opération de commit
est le renommage.

--
Cyrille Szymanski

Cyrille Szymanski wrote:

MSDE irait bien dans ce cas là.

J'ai regardé, ça à l'air pas mal. C'est surement bien plus propre et sûr
que ce que je fais à la main, mais d'un autre coté, si j'intègre ça dans
mon soft, ça va en devenir la plus grosse partie. Hors c'est pas le plus
important quand même.

Un inconvénient, c'est que c'est sous windows, et j'ai besoin d'un truc
qui fonctionne sous Windows et sous linux.

Je la garde sous la main, pour d'autres occasions.

S'il peut se payer le luxe de créer des fichiers distincts, c'est aussi
beaucoup plus simple.

En fait, la méthode des deux fichiers est une forme de "journalisation
du pauvre", le journal étant le second fichier et l'opération de commit
est le renommage.

Ok.

Bonjour.

Je réponds à AG <ag@tb.fr> qui a écrit :

Bonjour,

j'ai une petite application de calcul en C, qui peut tourner plusieurs
jours de suite. Pour ne pas avoir à recalculer tout depuis le début
lorsque l'application plante (soit parce que je décide de l'arrêter,
soit parce que la machine sur laquelle elle tourne, plante, soit pour
n'importe quelle autre raison), je sauvegarde les résultats
intermédiaires dans un fichier texte. Mes sauvegardes sont
périodiques.

Mais il peut arriver que le système plante au moment ou la sauvegarde
est en train d'être effectuée, et là, pour le coup, je perds toutes
mes données.

Quels sont les mécanismes classiques qui permettent un sauvegarde
sûre ?

J'ai pensé à :

1°) Utilisation d'outils de synchronisation (des cadenas (locks) )
mais j'ai comme l'impression que contre un reboot intempestif, même le
meilleurs des cadenas ne sera pas d'une grande utilité.

2°) Utilisation de deux fichiers de sauvegarde dans lesquels on vient
sauvegarder alternativement les données. Si le système plante lors de
la sauvegarde sur l'un des fichiers, l'utilisation de l'autre permet
une restauration du système.

Quelles sont les mécanismes classiques pour résoudre ce problème ?
Est-il possible de s'en tirer avec seulement 1 fichier de sauvegarde ?


Merci d'avance pour vos conseils.

Si on ne tient pas compte des éventualités du style crash disque, le
problème se limite à conserver un fichier dans un état valide en permanence,
même en supposant que le logiciel qui le manipule plante en cours
d'opération.

J'ai une expérience positive en ce sens, utilisant les fichiers mappés en
mémoire et des opérations dessus qui sont conçues pour ne pas provoquer de
réallocation du fichier, ainsi que des règles particulières de gestion des
buffers.
Bref c'est pas simple, et sans doute pas sûr à 100%.

Sans aller jusqu'à gérer deux fichiers alternatifs, vous pouvez très bien
(sauf coût parasite en cours de calcul) faire une sauvegarde temporaire du
fichier précédent, puis la mise à jour, puis la suppression du fichier de
sauvegarde.
Une logique simple, en cas de reprise après crash, peut permettre de
restaurer le fichier principal à partir de la sauvegarde s'il est corrompu.

Si les volumes de données ou la vitesse de calcul ne permettent pas de faire
ça, vous aurez sans doute intérêt à découper votre fichier en plusieurs
segments, et à utiliser cette procédure segment par segment.

Ca a de bonnes chances de rester simple et fiable.

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/

Bonjour,

si Windows XP ou Windows 2003 utiliser ntbackup avec clichés
instantanés pour la sauvegarde et rien ne plantera et rien ne sera
perdu.
Autrement l'utilisation d'un utilitaire de backup ce n'est pas de
la programmation mais bon .. :-)

--
Cordialement.
GG.

Patrick 'Zener' Brunet wrote:

Bonjour.
Sans aller jusqu'à gérer deux fichiers alternatifs, vous pouvez très bien
(sauf coût parasite en cours de calcul) faire une sauvegarde temporaire du
fichier précédent, puis la mise à jour, puis la suppression du fichier de
sauvegarde.

Cela ne revient il pas à gérer deux fichiers ? (de manière différente,
certes, mais deux fichiers quand même).

Bonjour.

Je réponds à AG <ag@tb.fr> qui a écrit :

Patrick 'Zener' Brunet wrote:

Bonjour.
Sans aller jusqu'à gérer deux fichiers alternatifs, vous pouvez très
bien (sauf coût parasite en cours de calcul) faire une sauvegarde
temporaire du fichier précédent, puis la mise à jour, puis la
suppression du fichier de sauvegarde.

Cela ne revient il pas à gérer deux fichiers ? (de manière différente,
certes, mais deux fichiers quand même).

En fonctionnement niominal, non, parce que le fichier de sauvegarde n'est
que temporaire, et donc détenu par la fonction d'écriture, puis "oublié".
Seule la fonction de reprise après crash doit être capable de régénérer son
nom pour le retrouver et restaurer le fichier nominal, ensuite idem.

C'est très différent du principe consistant à gérer deux fichiers en
alternance; et il faudrait encore gérer en parallèle l'information
spécifiant où on en est dans cette alternance : un simple booléen, mais
faites en la clé de votre reprise après crash et vous allez voir comme il
devient lourd à gérer !

Cordialement,

--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/